真实面经题目 · 原创解析
回答这类问题不能只说加索引或看执行计划。高质量拆解应先把查询要回答的业务问题讲清楚：指标是什么、统计哪段数据、以什么粒度统计、哪些记录应被纳入或排除；再把 SQL 的逻辑链路拆成数据源、JOIN 关系、过滤条件、聚合口径、排序分页；最后进入性能定位，从慢查询日志、执行计划、索引命中、扫描行数、临时表、排序、锁等待和数据倾斜等角度判断慢在哪里。核心思路是先证明结果口径正确，再证明执行路径高效。
可以按“口径确认、逻辑拆解、执行定位、优化验证”四步分析。第一步明确这条 SQL 的业务目标，确认指标定义、时间范围、统计对象、去重规则、粒度以及异常数据处理方式，避免查询变快但结果错误。第二步拆 SQL 逻辑，逐层确认主表选择、JOIN 类型和关联键、过滤条件的位置、聚合维度、HAVING 与 WHERE 的差异、排序分页是否必要。第三步定位慢点，通过慢查询日志确认执行时间、扫描行数和频率，再用 EXPLAIN 或 EXPLAIN ANALYZE 查看访问类型、索引使用、rows、filtered、Extra 中是否出现全表扫描、临时表、文件排序、回表过多等问题。第四步做针对性优化，例如补充联合索引、调整索引字段顺序、改写不可索引条件、先过滤再关联、减少不必要字段、拆分复杂聚合、优化分页或预聚合，并通过执行计划、耗时、返回行数和结果一致性验证优化是否真正生效。
慢 SQL 分析不能从语句本身直接跳到索引，首先要确认它到底在回答什么问题。需要问清楚指标名称、分子分母、统计对象、时间口径、状态口径、去重口径和异常数据处理规则。例如“成交用户数”可能是按订单创建时间、支付时间或完成时间统计，也可能要排除退款、测试账号和取消订单。口径不清时，优化 SQL 只是在加速一个不可信的结果。性能优化服务于准确查询，先对齐业务定义，再分析查询路径。
第二层要拆数据范围，包括时间窗口、业务线、地区、渠道、用户状态、订单状态等过滤边界，同时明确结果粒度是按天、按月、按用户、按店铺还是按商品。粒度决定 GROUP BY 字段，也决定是否会发生重复计数。很多慢查询来自粒度混乱：明明只要店铺级指标，却先把明细订单、商品明细、用户行为全量关联后再聚合，导致中间结果爆炸。正确做法是尽早过滤、尽早收敛粒度，并确认每个维度字段是否会改变最终指标含义。
SQL 涉及多表时，要明确每张表在查询中的角色：哪张是事实表，哪些是维表，哪张表决定结果行数。然后检查 JOIN 类型、关联键唯一性和关联方向。一个常见问题是把一对多关系当作一对一关联，导致金额、订单数或用户数被放大。还要区分过滤条件放在 ON 还是 WHERE 中的语义差异，尤其是 LEFT JOIN 场景，WHERE 过滤右表字段可能把外连接变成内连接。性能层面还要看驱动表是否合理、关联字段类型是否一致、关联键是否有索引。
过滤条件要从业务正确性和索引可用性两方面检查。业务上要确认是否遗漏状态、是否把时间边界写成包含或不包含、是否需要排除脏数据；性能上要检查字段是否被函数包裹、是否发生隐式类型转换、LIKE 前缀是否可用、OR 条件是否导致索引失效。聚合逻辑则要确认 COUNT、COUNT DISTINCT、SUM、AVG 的口径是否正确，是否需要先按明细去重再汇总，HAVING 是否能改成 WHERE 前置过滤。聚合字段越晚收敛，排序、临时表和磁盘开销越容易放大。
进入性能分析时，应先用慢查询日志或监控确认这条 SQL 的执行耗时、调用频率、扫描行数、返回行数和峰值时段，避免只凭一次执行感受判断。随后用执行计划查看 type、possible_keys、key、key_len、rows、filtered、Extra 等信息，判断是否全表扫描、索引选择错误、回表次数过多、Using temporary、Using filesort 或关联顺序异常。如果有条件使用实际执行分析，还要比较估算行数和真实行数，估算偏差大可能说明统计信息过旧或数据分布倾斜。
优化不是改完 SQL 就结束，而是要验证两件事：结果是否一致，性能是否稳定。结果验证可以抽样对比优化前后的总量、分组明细、边界日期和异常状态；性能验证要对比执行计划、扫描行数、执行耗时、临时表和排序情况。如果新增索引，需要评估写入成本和索引维护成本，避免为了低频查询影响高频写入。对于复杂报表，还可以考虑预聚合表、宽表、物化中间层或定时任务，但前提是口径稳定、延迟可接受，并且有回溯修正方案。
用了索引不代表代价低。可能索引选择性差，扫描了大量记录；也可能查询字段不在索引中，导致大量回表；还可能因为排序、分组、临时表或 JOIN 后中间结果过大而慢。需要结合 rows、filtered、Extra、实际返回行数和执行耗时判断，而不是只看 key 字段是否有值。
可以先分别统计主表关联前后的行数，再检查关联键在右表是否唯一。如果订单表关联订单明细、优惠券、行为日志等一对多表后直接 SUM 金额，就很容易重复累计。稳妥方式是先把一对多表按关联键聚合成一行，再回到主粒度关联。
WHERE 作用在聚合前，能减少进入 JOIN、GROUP BY 和排序的数据量；HAVING 作用在聚合后，通常用于过滤聚合结果。能放到 WHERE 的条件应尽量前置，因为它既更符合明细过滤语义，也更利于索引和执行效率。
优先看慢查询日志中的执行时间、扫描行数、返回行数、锁等待和调用频率，再看执行计划中的访问类型、索引命中、估算行数、过滤比例、临时表和文件排序。这样可以区分是读太多、关联太大、排序太重，还是被锁或资源争用拖慢。
如果查询频率低、数据量可控，优先优化原 SQL 和索引即可。如果查询频率高、口径稳定、明细量巨大，并且允许一定数据延迟，可以考虑预聚合或中间表。选择中间表前要明确刷新周期、补数机制、口径版本和异常回溯，否则会把性能问题变成数据一致性问题。
