慢查询优化不能只看一句 SQL。真正有效的复盘要把业务场景、数据分布、执行计划、索引设计和上线验证放在一起，否则很容易出现“加了索引，当时快了，过几天又慢”的循环。
先描述业务场景
复盘第一段先写清这条查询服务哪个页面、接口或任务，触发频率是多少，用户是否直接感知。后台定时报表和首页核心查询的优化优先级完全不同，不能只按耗时排序。
还要写清查询条件来自哪里：用户筛选、系统默认、权限范围，还是历史兼容字段。业务语义决定了哪些条件必须保留，哪些可以通过产品规则调整。
再记录数据分布
慢查询往往和数据分布有关。总行数、过滤字段基数、冷热数据比例、时间范围跨度、是否存在倾斜值，都应该记录。只看表有多少行不够，关键是 WHERE 条件能过滤掉多少。
如果某个状态占比特别高，单列索引可能效果很差；如果时间范围总是很大，就要考虑归档、分区或改查询入口。
EXPLAIN 要结合索引解释
执行计划里重点看 type、key、rows、filtered、Extra。不要机械追求 type=ref 或 Using index，要结合返回行数和排序方式判断。Using filesort 不一定坏，坏的是在大结果集上排序又无法限制范围。
索引设计要贴合查询：等值字段、范围字段、排序字段的顺序要说明理由。新增联合索引前，也要检查是否和现有索引重复。
优化后要做回归观察
优化完成后记录改动、执行计划变化、耗时变化和业务验证结果。上线后继续观察慢查询日志、连接池、CPU、IO 和主从延迟。
一份慢查询复盘模板的价值，是把“这条 SQL 慢”变成“这个业务场景为什么慢、我们为什么这样改、改完是否真的稳定”。这才方便以后继续维护。
正文完
