TDSQL Boundless 慢查询数过高

一、现象描述

·实例监控面板中慢查询数指标持续升高。

·CPU 利用率同步飙升，查询响应时间变长。

·业务侧出现请求超时或响应延迟。

·SQL 失败数增加，部分查询无法正常执行。

你可在 TDSQL Boundless 控制台的实例详情 > 监控告警 > 指标监控页面查看慢查询数、CPU 利用率、SQL 执行时间等指标。

二、可能原因

慢查询数过高通常由 SQL 执行效率低或实例负载超出承载能力导致。可能原因如下：

序号	可能原因
1	SQL 语句未使用索引或未使用较佳的索引，导致全表扫描或低效执行计划。
2	QPS 压力超过当前实例规格的承载上限，大量请求排队堆积。
3	并行度设置不当，并行查询资源争抢导致单条 SQL 执行时间过长。
4	数据量增长后统计信息过期，优化器选择了次优执行计划。

三、解决思路

针对不同原因，解决思路如下：

可能原因	解决思路
SQL 未使用索引或执行计划不佳	通过 DBbrain 智能诊断分析慢 SQL，添加合适的索引，优化 SQL 语句。
QPS 超出实例承载能力	优化业务请求模式，降低无效查询；必要时升级实例规格。
并行度设置不当	通过控制台调整 max_parallel_degree 参数，合理控制并行查询并发度。
统计信息过期	对相关表执行 ANALYZE TABLE 更新统计信息，使优化器选择更优执行计划。

四、步骤1：查看慢查询监控

1. 登录 TDSQL Boundless 控制台，在实例列表中单击目标实例 ID，进入实例详情页。

2. 选择监控告警 > 指标监控页签，查看以下指标的变化趋势：

监控指标	说明	关注点
慢查询数	每秒慢查询数量	是否持续升高或突增
CPU 利用率	实例 CPU 使用率	是否与慢查询数同步飙升
SQL 平均执行时间	SQL 平均耗时	是否明显变长
P95 SQL 执行时间	95% 分位执行时间	长尾查询耗时情况
P99 SQL 执行时间	99% 分位执行时间	极端慢查询耗时情况
总 QPS	每秒 SQL 总数	是否超出实例承载能力
SQL 失败数	每秒失败 SQL 数	是否出现大量失败

·重点关注慢查询数突增的时间点，与业务变更（如发版、大促）时间是否吻合。

·查看 SQL 耗时分布指标，判断慢查询主要集中在哪个耗时区间，为后续优化提供参考。

五、步骤2：通过 DBbrain 分析慢 SQL

六、步骤3：通过系统视图分析慢 SQL

如需更细粒度的 SQL 性能分析，可通过系统视图查询 SQL 执行统计信息。

1. 连接数据库实例，执行以下 SQL 查看 SQL 摘要统计信息。

SELECT SCHEMA_NAME, DIGEST_TEXT, COUNT_STAR AS EXEC_COUNT, ROUND(AVG_TIMER_WAIT / 1000000000, 2) AS AVG_MS, ROUND(MAX_TIMER_WAIT / 1000000000, 2) AS MAX_MS, SUM_ROWS_EXAMINED AS TOTAL_ROWS_EXAMINED, SUM_ROWS_SENT AS TOTAL_ROWS_SENTFROM performance_schema.events_statements_summary_by_digestWHERE SCHEMA_NAME IS NOT NULLORDER BY AVG_TIMER_WAIT DESCLIMIT 20;

该查询列出平均执行时间最长的20条 SQL 模板，重点关注以下信息：

·AVG_MS：平均执行时间（毫秒），数值越大说明 SQL 越慢。

·TOTAL_ROWS_EXAMINED：总扫描行数，若扫描行数远大于返回行数，说明存在低效扫描。

·DIGEST_TEXT：规范化后的 SQL 文本，用于定位具体 SQL。

2. 对识别出的慢 SQL，执行 EXPLAIN 查看执行计划。

EXPLAIN SELECT …;

重点关注以下信息：

·type 列为 ALL 表示全表扫描，需要添加索引。

·rows 列值过大说明扫描行数过多。

·key 列为 NULL 表示未使用索引。

七、步骤4：优化 SQL 语句

根据步骤2 和步骤3 的分析结果，对慢 SQL 进行优化。

1. 添加索引：对 WHERE、JOIN、ORDER BY、GROUP BY 涉及的列添加合适的索引。

2. 改写 SQL：

·避免 SELECT *，只查询需要的列。

·避免在 WHERE 条件中对索引列使用函数或运算。

·将大查询拆分为多个小查询，利用分页减少单次返回数据量。

·避免在 OR 条件中混合使用索引列和非索引列。

3. 更新统计信息：若数据量增长后慢查询增多，执行以下 SQL 更新统计信息。

ANALYZE TABLE table_name;

更新统计信息后，优化器可以基于最新的数据分布选择更优的执行计划。

八、步骤5：调整并行度参数

若慢查询与 HTAP 并行查询有关，可通过控制台调整并行度参数，详细请参见设置实例参数。

·若并行查询资源争抢导致整体性能下降，适当调小 max_parallel_degree。

·若单条大查询执行过慢且资源充足，适当调大 max_parallel_degree 以提升并行度。

九、步骤6：调整慢查询阈值

若需要调整慢查询的判定标准，可通过控制台修改 long_query_time 参数，详细操作请参见设置实例参数。

·调小 long_query_time 可以捕获更多慢查询，便于全面排查问题，但可能增加日志量。

·调大 long_query_time 可以只关注极慢查询，减少干扰。

十、步骤7：设置 SQL 执行超时

若需要限制单条 SQL 的最大执行时间，避免慢查询长时间占用资源，可通过控制台修改 max_execution_time 参数。例如设置为 5000，表示 SELECT 语句执行超过5秒将自动终止。详细操作请参见设置实例参数。

注意：警告：

注意：max_execution_time 仅对 SELECT 语句生效。设置过小的超时时间可能导致正常的长查询被意外终止，请根据业务实际最长查询时间合理设置。

十一、步骤8：升级实例规格

若经过以上优化后，慢查询数仍持续偏高且 QPS 已超出当前实例规格的承载能力，建议升级实例规格，详细操作请参见调整实例配置。

十二、预防措施

为避免慢查询数过高问题反复发生，建议采取以下预防措施：

·配置告警策略：在控制台为慢查询数和 CPU 利用率配置告警，建议慢查询数阈值根据业务基线设置，CPU 利用率阈值设为80%。

·定期巡检慢 SQL：通过 DBbrain 智能诊断定期检查慢 SQL，及时优化低效查询。

·定期更新统计信息：对数据变化频繁的表定期执行 ANALYZE TABLE，确保优化器选择最优执行计划。

·规范 SQL 开发：新上线 SQL 需经过 EXPLAIN 验证执行计划，确保使用索引且扫描行数合理。

·监控 QPS 趋势：关注 QPS 增长趋势，提前规划实例扩容。