MySQL索引失效本质是优化器认为走索引代价高于全表扫描，关键在于查询是否匹配索引结构及数据能否高效定位：1.联合索引须遵循最左前缀；2.避免函数、运算、隐式转换破坏有序性；3.LIKE仅前缀匹配有效；4.OR含无索引列、IS NOT NULL冗余、数据量小或统计过期等均致失效。
MySQL索引失效，本质是优化器判断走索引的代价高于全表扫描，于是主动放弃使用索引。它不是“坏了”，而是“不划算”或“用不了”。真正影响执行计划的关键，在于查询写法是否匹配索引结构、数据是否可被高效定位。
比如建立了 (sn, name, age) 联合索引，只有以下条件能用上索引：
而 name = ? 或 name = ? AND age = ? 就完全跳过索引——因为B+树是按 sn 排序的，没有 sn 就不知道从哪开始找。中间断开（如只用 sn 和 age，跳过 name）也会导致后续列失效。
索引依赖字段原始值的有序存储，一旦被干扰，就无法做范围查找或等值跳转：
WHERE UPPER(name) = 'LISA'、WHERE DATE(create_time) = '2025-12-01'
WHERE price * 1.1 > 100、WHERE id + 1 = 1000
VARCHAR，却写成 WHERE mobile = 13812345678（MySQL会转成字符串比较，但过程不可下推到索引层）只有前缀匹配能用索引：
LIKE '张%' ✅ 可走索引（知道起始位置）LIKE '%张' ❌ 全表扫描（结尾不确定，无法定位起点）LIKE '%张%' ❌ 同样无法定位，除非是全文索引注意：LIKE '张_'（单字符通配）或 LIKE '张__' 仍可走索引，因为前缀固定且长度可控。
这些情况容易被忽略，但同样让索引“形同虚设”：
WHERE indexed_col = 1 OR unindexed_col = 'x' → 整个条件放弃索引NOT NULL，再写 WHERE col IS NOT NULL，优化器认为恒真，可能跳过索引WHERE status = 1 匹配了95%的数据，优化器倾向直接扫表
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移，垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是，许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
748
收藏
取消收藏
