MySQL索引失效导致慢查询_使用SHOW INDEX分析与重新优化

索引存在不等于被使用需用EXPLAIN验证复合索引需按最左前缀匹配低基数或函数操作会导致索引失效。为什么 SHOW INDEX FROM table_name 看起来有索引但查询还是慢因为索引存在 ≠ 索引被用上。MySQL 优化器会根据统计信息、条件写法、数据分布等决定是否走索引。SHOW INDEX 只告诉你“建了什么”不反映“用了没有”。常见假象是索引列在 WHERE 子句里出现了但实际执行时走了全表扫描。实操建议先用 EXPLAIN SELECT ... 确认 key 和 rows 字段 —— 如果 key 是 NULL说明没走索引rows 接近表总行数大概率失效了SHOW INDEX 中的 Seq_in_index 值很重要复合索引 (a,b,c)只有查询带 a 才可能命中只查 b 或 c基本失效注意 Cardinality基数值过低比如远小于表行数说明该列区分度差优化器可能主动放弃使用哪些 WHERE 条件会让索引直接失效不是所有带索引列的条件都能触发索引查找MySQL 对表达式敏感稍一变形就退化为全表扫描。常见错误现象对索引列做函数操作WHERE YEAR(create_time) 2023 → 改成 WHERE create_time 2023-01-01 AND create_time 隐式类型转换WHERE user_id 123user_id 是 INT→ 字符串强制转数字可能丢索引应确保类型一致使用 ! 或 NOT IN尤其右值含 NULL→ 通常无法范围扫描改用 IN 或拆分逻辑前导通配符WHERE name LIKE %abc → LIKE 必须左对齐才走索引abc% 可以%abc 不行ORDER BY LIMIT 组合为什么常踩坑这个组合看似简单但极易因索引覆盖不全导致文件排序Using filesort甚至绕过索引直接扫全表。使用场景分页查最新 20 条订单按 created_at DESC 排序。 通义听悟 阿里云通义听悟是聚焦音视频内容的工作学习AI助手依托大模型帮助用户记录、整理和分析音视频内容体验用大模型做音视频笔记、整理会议记录。