mysql索引失效的首要原因是where中对索引列使用函数或表达式，如year()、upper()等，导致无法利用b+树索引；其次包括隐式类型转换、联合索引未遵循最左前缀原则、or条件部分无索引、like前导通配符、范围查询中断后续列、低选择性及统计信息过期等。
MySQL 没用你建的索引，不是它“不讲武德”，而是查询写法、数据特征或索引本身不满足使用条件——EXPLAIN 输出里 key 为 NULL 或 type 是 ALL，就是铁证。
WHERE 中对索引列用了函数或表达式
这是最常见也最容易忽略的失效点。只要索引列被包裹在函数里（比如 YEAR()、UPPER()、DATE()），MySQL 就无法直接走 B+ 树查找。
- 错误写法：
SELECT * FROM orders WHERE YEAR(created_at) = 2023—— 即使created_at有索引，也会全表扫描 - 正确写法：
SELECT * FROM orders WHERE created_at >= '2023-01-01' AND created_at - MySQL 8.0+ 可用函数索引补救：
CREATE INDEX idx_year ON orders ((YEAR(created_at)))，但注意该索引只对YEAR()查询有效
隐式类型转换导致索引列被强制转换
当查询值和索引字段类型不一致时，MySQL 会悄悄把索引列转成另一类型，导致索引失效。这不是“没匹配上”，是“匹配动作本身破坏了索引结构”。
MySQL（Linux）
下载
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
- 典型场景：
user_id是INT类型，但写成WHERE user_id = '123'—— 字符串值触发整型列转字符串，索引跳过 - 验证方法：执行
SHOW WARNINGS看是否有Truncated incorrect DOUBLE value类警告 - 修复原则：值类型必须和字段类型严格一致；宁可用
CAST('123' AS SIGNED)显式转，也不依赖隐式转换
联合索引没按最左前缀使用
复合索引 (a, b, c) 不是“三个字段都有索引”，而是一棵按 a → b → c 排序的树。跳过前面字段，后面就不可见。
- 能命中：
WHERE a = 1、WHERE a = 1 AND b = 2、WHERE a = 1 AND b = 2 AND c > 3 - 不能命中：
WHERE b = 2、WHERE c = 3、WHERE b = 2 AND c = 3（a缺失） - 注意范围查询中断后续列：如果写成
WHERE a = 1 AND b > 2 AND c = 3，c列实际无法走索引（B+ 树中b > 2是个区间，c在该区间内无序）
索引选择性太低或统计信息过期
优化器不是“一定要用索引”，而是“选成本最低的执行路径”。如果它估算用索引要回表太多次，不如直接扫表快，就会放弃索引。
- 低选择性例子：
status ENUM('pending','processing','completed')，其中 95% 是completed—— 走索引要查近百万行再过滤，不如全表扫描 - 检查基数：
SHOW INDEX FROM orders看Cardinality值，若远小于表总行数（比如只有 1 或几百），说明区分度差 - 统计信息可能滞后：大批量 INSERT/DELETE 后未
ANALYZE TABLE orders，优化器仍按旧数据分布做决策
真正容易被忽略的是：索引是否“可见”——INFORMATION_SCHEMA.STATISTICS 里 is_visible = 'NO' 表示它存在但被禁用；还有 WHERE col IS NULL 对非空索引列、LIKE '%abc' 前导通配，这些都无声无息绕过索引。别只盯着建了没，得确认它此刻“活”着、“准”着、“对”着。
