mysql慢查询分析中索引的作用_mysql执行计划读懂与优化

张开发
• 2026/4/12 18:54:17 • 15 分钟阅读

最新文章

推荐文章

相关文章

分享文章

mysql慢查询分析中索引的作用_mysql执行计划读懂与优化
key 是实际使用的索引possible_keys 是候选索引key 为 NULL 表示未走索引possible_keys 为空可能因类型不匹配导致隐式转换typerange 不一定快需结合 rows 和 filtered 判断ORDER BY 走索引需满足顺序一致且覆盖最左前缀Using index condition 是 ICP 优化减少回表但不改变扫描范围。怎么看 EXPLAIN 里 key 和 possible_keys 的区别key 是 MySQL 实际用上的索引possible_keys 是它“觉得能用”的候选索引——但选不选、怎么选得看统计信息、数据分布和 WHERE 条件的写法。常见错误现象possible_keys 有多个key 却是 NULL说明没走索引或者 key 是个低效索引比如只用上了联合索引的前缀但 possible_keys 里明明有更匹配的。WHERE 中用了函数或表达式如 WHERE YEAR(created_at) 2023会直接让所有索引失效key 变成 NULL联合索引 (a, b, c)查询条件是 WHERE b 1 AND c 2key 仍为 NULL —— 因为没覆盖最左列 apossible_keys 为空不一定代表没建索引可能是字段类型不一致比如 id 是 BIGINT但 WHERE 里写了字符串 123触发隐式转换typeALL 和 typerange 之间差的不只是扫描行数typeALL 是全表扫描typerange 是索引范围扫描——但别光看 type还得看 rows 和 filtered。使用场景当 rows 显示 50 万哪怕 type 是 range实际也比一个 typeref 扫 5000 行更慢而 filtered10.00 意味着 MySQL 预估只有 10% 的行满足条件剩下 90% 白扫了。typerange 不等于“快”如果索引区分度极低比如 status 只有 0/1 两个值MySQL 可能宁愿全表扫也不走索引typeref 通常比 range 更优但它要求等值匹配且索引列在 WHERE 中独立出现不能包裹在函数里注意 Extra 字段出现 Using filesort 或 Using temporary 时即使 type 是 ref性能也可能断崖下跌ORDER BY 为什么有时不走索引MySQL 只有在满足“索引顺序与 ORDER BY 完全一致 WHERE 条件覆盖索引最左前缀”时才可能避免排序操作。 OpenPerplex OpenPerplex是一个开源的AI搜索引擎致力于整合多种信息源为用户提供智能精准的搜索体验。

更多文章