帮你快速理解、总结文档立即下载
文档中心>TDSQL Boundless>故障处理>性能相关>慢查询数过高

慢查询数过高

最近更新时间：2026-07-10 10:54:30
我的收藏

本页目录：

现象描述

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

登录 DBbrain 控制台，在左侧导航选择诊断优化，选择慢 SQL 分析页签。选择查看是否存在慢 SQL 诊断建议。详细请参见 慢 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_SENT
FROM performance_schema.events_statements_summary_by_digest
WHERE SCHEMA_NAME IS NOT NULL
ORDER BY AVG_TIMER_WAIT DESC
LIMIT 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 增长趋势，提前规划实例扩容。
中国站