01
60 秒回答模板
可以这样回答:判断索引是否失效,核心看 EXPLAIN 或 EXPLAIN ANALYZE:possible_keys 有候选但 key 为空、type 退化为 ALL/index、rows 明显变大、filtered 很低、Extra 出现 Using filesort/Using temporary,通常说明没有按预期用上索引或扫描代价过高。 常见原因包括不满足最左前缀、对索引列使用函数或表达式、隐式类型转换、like 前置百分号、OR 条件拆分不当、范围条件截断后续列、低选择性、统计信息过期和排序列不匹配。 优化不只是强制使用索引。要评估选择性、回表成本、覆盖索引、联合索引列顺序和写入维护成本,必要时改 SQL、加索引或更新统计信息。 不要把这题答成泛泛 SQL 优化。先判断有没有用索引,再分析为什么没用和如何验证优化前后差异。 验证时重点看:看 possible_keys、key、key_len、type、rows、filtered、Extra、actual rows/time、慢查询耗时和扫描行数变化。
考点 考点边界
主线 核心机制
易错点 直接讲加索引、读写分离、分库分表,没先用 EXPLAI…
02
深入解析
01 考点边界
这题必须围绕“SQL 索引失效判断”本身回答,不能套相邻大类模板。先给定义或目标,再展开机制、边界、取舍和验证抓手。回答时要主动点出题面关键词对应的对象、输入输出和约束条件,避免把具体问题讲成宽泛复习提纲。 本题对应“SQL 索引失效判断”,核心前提是:判断索引是否失效,核心看 EXPLAIN 或 EXPLAIN ANALYZE:possible_keys 有候选但 key 为空、type 退化为 ALL/index、rows 明显变大、filtered 很低、Extra 出现 Using filesort/Using temporary,通常说明没有按预期用上索引或扫描代价过高。
02 核心机制
常见原因包括不满足最左前缀、对索引列使用函数或表达式、隐式类型转换、like 前置百分号、OR 条件拆分不当、范围条件截断后续列、低选择性、统计信息过期和排序列不匹配。 关键证据要落到读写路径、索引访问、锁/MVCC、执行计划,这样才能说明机制为什么能支撑题目结论。如果继续展开,要把访问路径、索引选择、锁范围、MVCC、回表成本或存储引擎差异放到同一条读写链路里解释。
03 关键取舍
优化不只是强制使用索引。要评估选择性、回表成本、覆盖索引、联合索引列顺序和写入维护成本,必要时改 SQL、加索引或更新统计信息。 因此要同时看读写比例、执行计划、锁等待、回表成本和事务边界,避免局部优化放大写入或并发成本。 这些取舍决定了方案在不同输入规模、延迟、内存、并发、泛化或一致性要求下是否仍然成立。
04 边界风险
不要把这题答成泛泛 SQL 优化。先判断有没有用索引,再分析为什么没用和如何验证优化前后差异。 排查时优先看 EXPLAIN、慢查询、扫描行数、锁等待、事务隔离、回表次数和异常数据分布。 需要特别关注极端输入、数据分布变化、资源不足、并发竞争或观测口径错误带来的退化。修复时要先复现实执行计划和数据分布,再决定改 SQL、建索引、缩事务、调整隔离级别还是做冷热拆分。
05 验证抓手
验证时看 EXPLAIN/EXPLAIN ANALYZE、慢查询、扫描行数、回表、Using index/filesort/temporary、锁等待、事务隔离级别、Buffer Pool 命中率和实际耗时。索引或事务结论都要能用这些证据闭环。 针对本题,最有价值的验证信号是:看 possible_keys、key、key_len、type、rows、filtered、Extra、actual rows/time、慢查询耗时和扫描行数变化。把验证抓手说出来,可以让答案从知识点延伸到数据库访问路径、性能和一致性验证。
03
易错点
- 直接讲加索引、读写分离、分库分表,没先用 EXPLAIN 判断失效信号。
- 只背索引失效原因,不看 possible_keys/key/type/rows/Extra。
- 把相邻概念混用,没有明确说明这道题真正考察的边界。
- 没有给出验证方式,导致答案听起来完整但无法判断是否真的生效。
04
面试官追问
possible_keys 有值但 key 为空说明什么?
说明优化器认为有候选索引,但最终成本估算没有选择它,可能因为选择性低、函数/转换、统计信息或回表成本。 回答时还要补充适用前提、失败场景和验证信号,避免只给一个孤立结论。
如何验证修复真的让索引生效?
对比 EXPLAIN/EXPLAIN ANALYZE 的 key、type、rows、actual time,以及慢查询实际耗时和扫描行数。
“如何判断 SQL 查询是否发生索引失效”继续追问时最该补哪条边界?
应该围绕“SQL 索引失效判断”补适用前提、失败场景和验证证据。先说明哪些条件下这个机制成立,再说明哪些输入规模、并发状态、数据分布或资源限制会让答案需要调整。
“如何判断 SQL 查询是否发生索引失效”怎样回答才不是只背概念?
看它能否把“SQL 索引失效判断”的机制链路、关键取舍和可观测信号连起来。回答时应落到具体状态变化、数据路径、复杂度、指标或排查工具,而不是只复述定义。
MySQL 题为什么要先看执行计划?
执行计划能确认访问类型、候选索引、实际使用索引、扫描行数、回表、排序和临时表。没有它,索引优化和性能判断很容易停在猜测。