慢查询治理：先看执行计划再谈优化

系统变慢时，最常见的反应是加索引，其次是加缓存。这两种做法有时有效，有时只是把问题往后推了三个月。我们的习惯是先拿到执行计划，再决定动哪里。

排查顺序

第一步打开慢查询日志，按总耗时排序而不是按单次耗时。一条 200 毫秒但每秒执行 50 次的查询，比一条 5 秒偶尔执行的查询更值得处理。

第二步用 EXPLAIN 看访问类型、扫描行数和是否用上索引。type 为 ALL 且 rows 很大，基本可以确认问题。

第三步确认是否发生了隐式类型转换，比如字符串字段用数字比较，索引会直接失效。

常见误区

给每个字段都加索引。写入变慢、索引膨胀，收益却很小。

只优化 SQL 不看业务。很多时候是因为查询了根本不需要的全量数据。

把缓存当成修复手段。缓存命中率下降时，数据库会承受更大的瞬时压力。

慢查询治理是长期工作。我们给每个项目留了一份查询清单，上线后每月复查一次最慢的十条。