一条 SQL 慢查询的排查路线

把“慢”描述成可观察的事实

先记录执行耗时、数据量、调用频率和对应接口。没有基线，“优化”只靠感觉。

先看执行计划，再谈索引

用 EXPLAIN 查看访问方式、扫描行数、是否排序和临时表。索引不是越多越好，而是要匹配查询条件、连接字段和排序字段。

EXPLAIN SELECT id, title
FROM posts
WHERE owner = ? AND status = ?
ORDER BY publish_time DESC
LIMIT 20;

确认索引与查询一致

函数包装字段、隐式类型转换、前导通配符，都可能让索引失效。把条件写成能够利用最左前缀的形式。

减少不必要的返回和往返

先检查是否取回了所有字段，再检查是否在循环里发起了重复查询。批处理和延迟加载的边界，往往比数据库参数更影响体验。

用真实数据验证

在测试环境填充接近生产的数据量后再压测。空表上的执行计划通常很漂亮，但数据规模会改变优化器的选择。

慢查询优化是数据驱动的过程：先测量，再定位，最后小步修改并重新验证。