--- title: "SQL 性能诊断相关参数配置 - 云平台 OCP V4.2.1 | OceanBase 文档中心" description: SQL 性能诊断相关参数配置 本节描述 OCP 系统参数中与 SQL 性能诊断相关的参数配置。 SQL 性能模块 表中介绍 SQL 性能诊断参数的配置，表中所属"诊断对象"都是针对 SQL。 参数名 默认值 参数说明 ocp.perf.sql-diag.awful-performance-index-used-con… --- 切换语言 - 中文站 - 简体中文 - International - English - 日本站 - 日本語 文档反馈![](https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*lJTmRZ61jSUAAAAAAAAAAAAADiGDAQ/original) 云平台 OCPV 4.2.1 # SQL 性能诊断相关参数配置 更新时间：2024-12-04 14:15:50 [编辑](https://github.com/oceanbase/ocp-doc/edit/V4.2.1/zh-CN/1000.diagnosis-and-tuning-fuctions/100.manage-sql-diagnosis/1400.sql-performance-diagnosis-related-parameter-configuration.md) 本节描述 OCP 系统参数中与 SQL 性能诊断相关的参数配置。 ## SQL 性能模块 表中介绍 SQL 性能诊断参数的配置，表中所属"诊断对象"都是针对 SQL。 | 参数名 | 默认值 | 参数说明 | | --- | --- | --- | | ocp.perf.sql-diag.awful-performance-index-used-config | {"enabled":true, "cpuTimeLimitUs":100000, "execPsLimit":5.0, "fullLogicalReadsLimit":10000} | 走索引性能依然差的诊断配置。 - enabled：是否打开该检测项。 - execPsLimit：每秒执行次数。 - cpuTimeLimitUs：平均 CPU 时间（μs）。 - fullLogicalReadsLimit：逻辑读次数。 诊断对象：平均 CPU 时间 > cpuTimeLimitUs && 实际逻辑读 > fullLogicalReadsLimit && 未进行全表扫描 && 执行频率 > $execPsLimit | | ocp.perf.sql-diag.cpu-time-proportion-high-config | {"enabled":true, "cpuTimeLimitUs":10000, "execPsLimit":10.0, "maxCpuTimeLimitUs":30000, "affectedRowsLimit":100, "execLimit":30, "sqlCountLimit":20, "cpuTimePercentLimit":20} | 执行占比较高诊断的配置。 - enabled：是否打开该检测项。 - execPsLimit：执行频率（每秒执行次数）。 - cpuTimeLimitUs：平均 CPU 时间（μs）。 - maxCpuTimeLimitUs：最大 CPU 时间。 - affectedRowsLimit：影响行数。 - execLimit：执行次数。 - sqlCountLimit：SQL 数。 - cpuTimePercentLimit：CPU 占比。 诊断对象：平均 CPU 时间 > $cpuTimeLimitUs \|\| 影响行数 > $affectedRowsLimit \|\| 最大 CPU 时间 > $maxCpuTimeLimitUs && 执行频率 >= $execPsLimit 判断标准：诊断时间内，被诊断的 SQL 的 CPU 时间占租户 CPU 时间超过 $cpuTimePercentLimit，且租户的 SQL 执行总次数大于 $execLimit，且租户执行的不同 SQL 数大于 $sqlCountLimit，则视为占比过高。 | | ocp.perf.sql-diag.database-white-list | oceanbase,information_schema,mysql,__recyclebin,sys,__public | SQL 诊断时过滤掉的数据库名。 | | ocp.perf.sql-diag.execution-spike-config | {"enabled":true, "cpuTimeLimitUs":3000, "execPsLimit":5.0, "pointsLimit":5, "compareMin":20, "avgExecutionMultiply":{"0":6, "1":5, "5":4, "10":3, "50": 2.5, "100": 2, "500": 1.6}, "stdExecutionMultiply":{"0":80, "1":60 , "3": 30,"5":20, "10":15, "20":8, "30":6, "50":5, "80":4}} | 执行次数突刺诊断的配置。- enabled：是否打开该检测项 - execPsLimit：执行频率（每秒执行次数）。 - cpuTimeLimitUs：平均 CPU 时间（μs）。 - pointsLimit：点数。 - compareMin：比较时间（min）。 - avgExecutionMultiply：执行频率均值倍率。 - stdExecutionMultiply：执行频率标准差的倍率。 诊断对象：平均 CPU 时间 >= $cpuTimeLimitUs && 平均每秒执行次数 >= $execPsLimit 。 判断标准： 1. 取前 $compareMin 时间内满足诊断对象条件的 SQL，统计这些 SQL 前 compareMin 时间内每分钟执行频率的均值 avg_exec_ps，以及前 $compareMin 时间内执行频率的标准差 std_exec_ps 和标准差与均值的百分比 range_percent，即统计如下信息：历史平均执行频率（avg_exec_ps），标准差（std_exec_ps）* range_percent（std_exec_ps / avg_exec_ps * 100）。 2. 然后计算该 SQL 的平均每秒执行次数（exec_ps）。当 exec_ps 同时满足以下条件时则该 SQL 被认为是执行次数突刺。 exec_ps>=avg_exec_ps*$multiple_value_1* exec_ps >= avg_exec_ps + std_exec_ps * $multiple_value_2 #### 说明 multiple_value_1，随 avg_exec_ps 变化情况，依赖配置项 avgExecutionMultiply。 - 当 avg_exec_ps>500，multiple_value_1=1.6，以此类推：100->2, 50->2.5, 10->3, 5->4, 1->5。 - multiple_value_2，range_percent变化情况，依赖配置项stdExecutionMultiply。当 range_percent>80，multiple_value_2=4，以此类推：50->5, 30->6, 20->8, 10->15, 5->20, 3->30, 1->60, 0->80。 | | ocp.perf.sql-diag.index-diagnoser-config | {"enabled":true,"schedulePeriodMin":5, "coreThreadSize":10, "maxThreadSize":50,"maxQueueSize":10000,"diagPeriodSec":300,"diagOffsetSec":60,"maxDiagPeriodSec":1800} | SQL 索引诊断配置参数，重启生效。 不建议用户自行配置。 | | ocp.perf.sql-diag.ineffective-hint-config | {"enabled":true, "execPsLimit":5.0, "cpuTimeLimitUs":20000} | Hint 未生效诊断的配置。 - enabled：是否打开该检测项。 - execPsLimit：执行频率（每秒执行次数）。 - cpuTimeLimitUs：平均 CPU 时间（μs）。 诊断对象：CPU 时间 >= $cpuTimeLimitUs && 执行频率 >= $execPsLimit 判断标准：解析诊断对象，满足 "Hint 中指定的索引的与执行计划里的不一致。" 则认为是 Hint 未生效。 | | ocp.perf.sql-diag.perf-diagnoser-config | {"enabled":true,"schedulePeriodMin":5, "coreThreadSize":10, "maxThreadSize":50,"maxQueueSize":10000,"diagPeriodSec":300,"diagOffsetSec":60,"maxDiagPeriodSec":1800} | SQL 性能诊断配置参数，重启生效。 不建议用户自行配置。 | | ocp.perf.sql-diag.performance-degradation-after-plan-changed-config | {"enabled":true, "compareMin":5, "cpuTimeLimitMs":1.0, "cpuTimeMultiply":{"0":50, "1":30, "10":10, "100":8, "1000":6}} | 执行计划变化且性能下降诊断的配置。 - enabled：是否打开该检测项。 - compareMin：性能比较时间（min）。 - cpuTimeLimitMs：触发该规则的最小 CPU 时间（ms）。 - cpuTimeMultiply：CPU 倍率，若当前平均 CPU 时间大于 0 ms，则执行计划变化后的 CPU 时间应该下降 50 倍才算性能下降，若大于 1ms 则为 30 倍，依此类推。 判断条件：该 SQL 在 $compareMin 时间内平均 CPU 时间，在计划变化后增加的倍数大于此处设置的 CPU 倍率，则视为性能下降。 | | ocp.perf.sql-diag.performance-degradation-config | {"enabled":true, "cpuTimeLimitUs":10000, "execPsLimit":5.0, "maxCpuTimeLimitUs":30000, "affectedRowsLimit":100, "execLimit":5, "compareMin":20, "cpuTimeMultiply":{"0":50, "1":30, "10":10, "100":8, "1000":6}} | 性能下降诊断的配置。 - enabled：是否打开该检测项。 - execPsLimit：执行频率（每秒执行次数）。 - cpuTimeLimitUs：平均 CPU 时间（μs）。 - maxCpuTimeLimitUs：最大 CPU 时间。 - affectedRowsLimit：影响行数。 - execLimit：执行次数。 - compareMin：基线数据的来源时间（min），为检测时间的前 $compareMin 时间。 - cpuTimeMultiply：CPU 倍率，若当前 CPU 时间大于 0 ms, 则执行计划变化后的 CPU 时间应该下降 50 倍才算性能下降，若大于 1ms 则为 30 倍，依此类推。 诊断对象：诊断时间内满足下述条件的 SQL，平均 CPU 时间 > $cpuTimeLimitUs \|\| 影响行数 > $affectedRowsLimit \|\| 最大CPU 时间 > $maxCpuTimeLimitUs && 执行频率 > $execPsLimit。 判断标准： 基线作为比较对象，需满足"基线执行次数 > $execLimit"，否则不可作为比较对象。有了比较对象后，当检测的 SQL 同时满足下述条件则认为是性能比以前下降。 - 当前平均 CPU 时间 >= 基线 CPU 时间 * $cpuTimeMultiply，cpuTimeMultiply 默认值为 6。 - 当前执行频率 >= 基线执行频率 * 0.5 | | ocp.perf.sql-diag.query-timeout | 30000000 | SQL 诊断查询时的超时时间（μs）。 | | ocp.perf.sql-diag.row-lock-contention-high-config | {"enabled":true, "execPsLimit":0, "cpuTimeLimitUs":1000, "elapsedTimeLimitUs":0} | 热点行锁诊断的配置。 - enabled：是否打开该检测项。 - execPsLimit：执行频率（每秒执行次数）。 - cpuTimeLimitUs：平均 CPU 时间（μs）。 - elapsedTimeLimitUs：平均响应时间（μs）。 检测对象：检测时间段内满足下述条件的 SQL 。 执行频率 > $execPsLimit && 平均 CPU 时间 > $cpuTimeLimitUs && 平均响应时间 > $elapsedTimeLimitUs 。 #### 说明 elapsedTimeLimitUs 不配置的话，则不作为过滤检测对象的条件。 判断标准： 检测对象中类型为"%select%for%update%"的即为造成热点行锁诊断的 SQL。 | | ocp.perf.sql-diag.table-scan-index-not-exists-config | {"enabled":true, "execPsLimit":1.0, "cpuTimeLimitUs":20000} | 全表扫描且无可用索引的诊断配置。 - enabled：是否打开该检测项。 - execPsLimit：执行频率（每秒执行次数）。 - cpuTimeLimitUs：平均 CPU 时间（μs）。 诊断对象：v$sql_audit 中 table_scan >0 的 SQL，即进行了全表扫描的 SQL。 判断标准：满足下述条件则认为是无索引。- 单表，该表无索引 。 - 多表，有的表没有索引。 | | ocp.perf.sql-diag.table-scan-index-not-used-config | {"enabled":true, "execPsLimit":1.0, "cpuTimeLimitUs":2000} | 全表扫描有索引未走的诊断配置。 - enabled：是否打开该检测项。 - execPsLimit：执行频率（每秒执行次数）。 - cpuTimeLimitUs：平均 CPU 时间（μs）。 检测对象：检测时间段内满足下述条件的 SQL 。 执行频率 > $execPsLimit && 平均 CPU 时间 > $cpuTimeLimitUs && 进行了全变扫描。 判断标准：有索引未走。 | | ocp.perf.sql.diag-plan-change-config | {"enabled":true,"schedulePeriodMin":5, "coreThreadSize":10, "maxThreadSize":50,"maxQueueSize":10000,"diagPeriodSec":300,"diagOffsetSec":300,"maxDiagPeriodSec":1800} | 诊断任务调度参数配置。 不建议用户自行配置。 | | ocp.perf.sql.max-query-range | 24h | SQL 性能数据查询时的最大时间区间长度。默认值"24h"。 若 **TopSQL** 和 **SlowSQL** 界面配置的查询时间超过该值，则提交查询时会报错。 | | ocp.perf.sql.plan-hist-level0-granularity | 30s | OCP 聚合第 0 级 SQL 的 Plan 性能数据的时间粒度。 OCP 默认 30s 采集并聚合一次 SQL 的 Plan 性能数据并存于固定表中，供 TopSQL 查询时使用。 通过调大该值可以降低 OCP 监控元数据存储空间的压力。 | | ocp.perf.sql.plan-hist-level0-query-interval | 2h | 第 0 级 Plan 性能数据的最大查询时间区间。 超过该值，OCP 会去查看聚合时间粒度更大的数据表。 | | ocp.perf.sql.plan-hist-level0-retention | 5d | 第 0 级 Plan 性能数据的分区保留时间。 性能数据的分区按天创建，系统默认只保留 5 天内的数据，超过 5 天的分区将会被删除。 | | ocp.perf.sql.prepare-partition-ahead | 8 | 指定提前创建多少天的性能数据分区。要求传入以天为单位的时间。 | | ocp.perf.sql.query-timeout | 30000000 | SQL 性能数据查询时的超时时间（μs）。 | | ocp.perf.sql.sql-hist-level0-granularity | 30s | OCP 聚合第 0 级 SQL 性能数据的时间粒度。 #### 说明 为提高 OCP 监控采集性能，OCP 将按不同的时间粒度采集并聚合 SQL 的性能数据以供 TopSQL 的诊断时查询。共分三级，不同级别的数据被采集来后会按天存储到对应级别表的分区中。分区的保留时间由固定参数配置。 同样的性能数据，时间粒度越大则消耗的存储空间越小。 | | ocp.perf.sql.sql-hist-level0-query-interval | 2h | 第 0 级 SQL 性能数据的最大查询时间区间。 当用户在 **TopSQL** 界面中配置的查询时间区间超过该值时，系统将会从第 1 级 SQL 性能数据表中查询。 | | ocp.perf.sql.sql-hist-level0-retention | 2d | 第 0 级 SQL 性能数据的分区保留时间。 对于按天创建用来存储第 0 级 SQL 性能数据的分区表，监控元数据库默认仅保留两天内创建的。 | | ocp.perf.sql.sql-hist-level1-granularity | 2m | OCP 聚合第 1 级 SQL 性能数据的时间粒度。OCP 默认每 2 分钟聚合一次 SQL 性能数据并写入第 2 级 SQL 性能数据表中。 | | ocp.perf.sql.sql-hist-level1-query-interval | 12h | 第1级SQL性能数据的最大查询时间区间。 当用户在 **TOPSQL** 界面中配置的查询时间区间超过该值时，系统将会从第 2 级 SQL 性能数据表中查询。 | | ocp.perf.sql.sql-hist-level1-retention | 8d | 第 1 级 SQL 性能数据的分区保留时间。 | | ocp.perf.sql.sql-hist-level2-granularity | 10m | OCP 聚合第 2 级 SQL 性能数据的时间粒度。OCP 默认每 10 分钟聚合一次 SQL 性能数据并写入第 2 级 SQL 性能数据表中。 | | ocp.perf.sql.sql-hist-level2-query-interval | 48h | 第 2 级 SQL 性能数据的最大查询时间区间。 因无更高级别的的采集粒度，即使超过该值，OCP 仍会从第 2 级 SQL 性能数据表中查询。 | | ocp.perf.sql.sql-hist-level2-retention | 15d | 第 2 级 SQL 性能数据的分区保留时间。 | 上一篇 下一篇 ![有帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*y6ocSqN8cqsAAAAAAAAAAAAAARQnAQ)![无帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*BG9IQJyLHF8AAAAAAAAAAAAAARQnAQ)![反馈](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*eTWdQKCRKHwAAAAAAAAAAAAAARQnAQ)[AI](https://www.oceanbase.com/obi) 咨询热线