智能慢查询根因分析别把所有问题都归咎于没索引一、慢查询不是单一病因慢 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 报告最好给置信度。证据充分时给明确结论证据不足时列出下一步采集项。数据库排障最怕自信但没证据的判断。五、总结智能慢查询根因分析要结合执行计划、等待事件、参数分布、资源水位和验证方法。别把所有问题都归咎于没索引。数据库慢通常有证据链。