智能慢查询根因分析：别把所有问题都归咎于没索引

智能慢查询根因分析：别把所有问题都归咎于没索引

一、慢查询不是单一病因

慢 SQL 出现后，最常见的建议是“加索引”。但真实生产里，慢查询可能来自统计信息漂移、参数倾斜、锁等待、临时表、排序溢出、网络抖动、缓存失效、并发放大或执行计划退化。AI 做慢查询分析时，如果只会推荐索引，会把复杂问题压成一个答案。

智能慢查询根因分析，首先要分类，而不是直接给药。

二、建立诊断路径

flowchart TD A[慢查询] --> B[执行计划] A --> C[等待事件] A --> D[数据分布] A --> E[资源水位] A --> F[并发上下文]

不同根因需要不同证据。执行计划变了，要看统计信息和索引选择；锁等待高，要看事务和热点行；排序慢，要看内存和临时表；只有证据匹配，建议才可信。

slow_query_evidence: explain_plan: required wait_event: required rows_examined: required temp_table: optional lock_wait: optional

缺证据时，AI 应该输出“不足以判断”，而不是硬给结论。

三、参数倾斜要单独看

同一条 SQL，不同参数可能走出完全不同的成本。高频用户、超大租户、特殊状态值，会把平均值掩盖的问题暴露出来。

SELECT tenant_id, COUNT(*) FROM events GROUP BY tenant_id ORDER BY COUNT(*) DESC LIMIT 20;

慢查询分析要把参数分布和执行时间关联起来。否则一个看似合理的索引，在长尾参数上仍然可能失效。

四、建议要能验证

每个根因建议都应该附验证方法。建议更新统计信息，就要说明更新后执行计划如何变化；建议增加复合索引，就要说明写入成本、索引选择率和回滚方式；建议拆分 SQL，就要说明语义是否保持一致。

recommendation: root_cause: stale_statistics action: analyze_table verify_by: - explain_plan_changed - rows_examined_reduced - p95_latency_lower

还要避免把系统问题推给单条 SQL。磁盘 IO 打满、连接池耗尽、缓存击穿时，任何 SQL 都可能变慢。AI 分析必须把实例级指标纳入上下文。

最后，根因标签要沉淀。一个月内慢查询主要来自什么类型，哪些建议真正有效，能帮助团队决定是补索引规范、改查询模板，还是治理数据分布。

慢查询还要区分“单次慢”和“持续慢”。单次慢可能来自瞬时 IO、备份任务或锁冲突；持续慢更可能是执行计划、数据分布或索引设计问题。两者混在一起分析，建议会失焦。

slow_query_classification: one_time_spike: check_system_event recurring_pattern: check_plan_and_index parameter_related: check_distribution

对高频 SQL，还应该看总体资源消耗。一条 SQL 单次只慢 50ms，但每秒执行几千次，可能比偶发 3 秒的查询更值得优化。根因分析要同时关注延迟和调用量。

最后，AI 报告最好给置信度。证据充分时给明确结论，证据不足时列出下一步采集项。数据库排障最怕自信但没证据的判断。

五、总结

智能慢查询根因分析要结合执行计划、等待事件、参数分布、资源水位和验证方法。

别把所有问题都归咎于没索引。数据库慢，通常有证据链。