MySQL 索引失效”常被误解为“建了索引没用”或“数据库抽风了”。但本质上它是优化器在“使用索引随机 I/O”与“全表扫描顺序 I/O”之间经过成本估算后做出的“理性放弃”或者是开发者写出了让索引结构无法定位的“模糊指令”。索引不是万能钥匙它是一把精密的二叉树/跳表导航仪。一旦你的查询语句破坏了树的遍历规则如函数运算、类型转换、模糊匹配导航仪就会失灵被迫回到最原始的“逐行排查”全表扫描。理解索引失效就是理解如何写出符合 B 树遍历逻辑的 SQL避免让数据库做无用功。一、核心本质为什么索引会“罢工”1. 索引的本质索引B 树是有序的数据结构。它的核心价值在于快速定位二分查找和范围扫描。有效查询条件能利用“有序性”直接跳到目标节点。失效查询条件破坏了“有序性”或者计算成本高于直接扫表。2. 失效的两种真相物理失效写法导致索引树无法被遍历如WHERE YEAR(create_time) 2023。这是硬伤必须改 SQL。逻辑失效优化器放弃索引可用但优化器算了一笔账发现“走索引回表”的成本比“直接全表扫描”还高如查全表 90% 的数据。这是策略通常无需干预除非业务场景特殊。 核心洞察索引失效往往是因为我们给数据库出了一道“无法利用排序优势”的难题。二、六大经典失效场景硬伤篇这些场景下索引绝对不会被使用或只能部分使用必须修正。1. 违背“最左前缀”原则 (Leftmost Prefix)场景联合索引(a, b, c)。失效写法WHERE b 1(跳过 a)WHERE a 1 AND c 3(跳过 bc 无法利用索引有序性)WHERE a LIKE %xx(a 以最左模糊开头后续 b,c 全部失效)原理B 树是先按a排序a相同再按b排序。没有ab就是无序的无法二分查找。修正确保查询从索引最左列开始。如果需要跳过中间列考虑建立新的索引(b, ...)。利用索引下推 (ICP)WHERE a1 AND c3虽然c不能用于定位但可以在遍历a1的过程中利用 ICP 过滤c减少回表不算完全失效但效率打折。2. 在索引列上做计算/函数操作场景WHERE create_time 2023-01-01(有索引)。失效写法WHERE DATE(create_time) 2023-01-01WHERE age 1 18WHERE SUBSTR(name, 1, 3) abc原理索引存的是原始值create_time。你对它做了函数数据库必须把每一行都取出来算一遍函数值才能比较。索引的有序性被破坏。修正保持索引列的“纯洁性”把计算移到等号右边。✅WHERE create_time 2023-01-01 00:00:00 AND create_time 2023-01-02 00:00:00✅WHERE age 173. 隐式类型转换 (Implicit Type Conversion)场景字段phone是VARCHAR类型建有索引。失效写法WHERE phone 13800138000(数字没加引号)。原理MySQL 遵循类型优先原则会将字符串字段隐式转换为数字进行比较CAST(phone AS SIGNED)。这相当于对索引列做了函数操作导致全表扫描。修正严格匹配类型。✅WHERE phone 138001380004. 模糊查询以%开头场景name有索引。失效写法WHERE name LIKE %Jack或WHERE name LIKE %Jack%。原理B 树是按从左到右排序的。%开头意味着前缀未知无法确定从树的哪个节点开始查找只能全盘扫描。修正尽量使用WHERE name LIKE Jack%(最左匹配有效)。如果必须%开头考虑使用全文索引 (Fulltext Index)或Elasticsearch。利用覆盖索引SELECT id FROM table WHERE name LIKE %Jack(如果只查 id可能走覆盖索引扫描虽慢但不回表)。5.OR连接非索引列场景a有索引b无索引。失效写法WHERE a 1 OR b 2。原理只要OR两边有一个条件不能用索引优化器通常会放弃整个索引选择全表扫描因为分别查再合并的成本可能更高。修正给b也加上索引。改用UNION ALLSELECT*FROMtWHEREa1UNIONALLSELECT*FROMtWHEREb2;6.!或不等于场景status有索引。失效写法WHERE status ! 1。原理不等于意味着要查除了 1 以外的所有数据。如果数据分布均匀大部分数据都要被查出来优化器认为全表扫描更快。例外如果是覆盖索引查询只查索引列可能会走索引。修正业务允许的话改为IN列举具体值。接受全表扫描如果数据量不大。三、隐式陷阱优化器的“理性放弃”有时候 SQL 写对了索引也没用这是优化器基于成本模型 (Cost Based Optimizer, CBO)的决定。1. 数据区分度低 (Low Selectivity)场景性别字段gender(只有 ‘M’, ‘F’)有索引。查询WHERE gender M。现象不走索引直接全表扫描。原因如果 ‘M’ 占了 50% 的数据走索引需要查索引 - 回表 50% 次大量随机 IO。直接全表扫描是顺序 IO。顺序 IO 远快于大量随机 IO。阈值通常当查询数据量超过总表量的20%-30%时优化器倾向于弃用索引。2. 统计信息过时场景刚导入了大量数据或者删除了大量数据但未更新统计信息。现象优化器以为某列区分度很低从而放弃索引。解决执行ANALYZE TABLE table_name;更新统计信息。3. 复杂关联查询场景多表 Join驱动表选择错误。现象本该走索引的表被当成了从表或者连接算法选错了。解决使用STRAIGHT_JOIN强制指定驱动表慎用或优化 Join 字段的索引。四、诊断与验证如何确认索引失效不要猜用工具看。1.EXPLAIN命令在执行 SQL 前加上EXPLAIN。重点关注以下字段字段正常 (走索引)异常 (失效/全表扫描)含义typeconst,eq_ref,ref,rangeALLALL代表全表扫描最危险key显示具体的索引名NULLNULL代表没用到任何索引rows较小数值极大数值(接近总行数)预计扫描的行数ExtraUsing index,Using whereUsing temporary,Using filesort出现这两个通常意味着性能糟糕2. 查看 Handler 状态执行完 SQL 后运行SHOW STATUS LIKE Handler_read%;。Handler_read_rnd_next: 如果这个值很大说明发生了全表扫描正在逐行读取。Handler_read_key: 如果这个值很小或为 0说明没怎么用索引定位。五、避坑指南与优化策略1. 设计阶段区分度优先不要把索引建在“性别”、“状态只有 2-3 种值”这种低区分度字段上除非是联合索引的一部分。长字段截断对于很长的字符串如 URL建立前缀索引(INDEX(url(20)))节省空间且提高效率。2. 编码阶段三不原则不对索引列做函数运算。不让类型隐式转换严守引号。不写%开头的模糊查询除非用 ES。覆盖索引尽量SELECT需要的字段凑成覆盖索引避免回表。3. 运维阶段定期分析对频繁变动的表定期ANALYZE TABLE。慢查询监控开启 Slow Query Log捕获那些Examined_rows(扫描行数) 远大于Sent_rows(返回行数) 的 SQL。4. 终极方案引入新架构如果业务场景注定要走大量模糊查询、复杂排序、深分页不要死磕 MySQL 索引。将数据同步到Elasticsearch或ClickHouse。MySQL 只作为最终一致性存储查询走搜索引擎。 总结索引失效全景图类别核心原因典型特征解决方案最左前缀跳跃匹配破坏有序性typeALL,keyNULL调整索引顺序补全左侧列函数计算破坏原始值无法二分WHERE func(col)val移项保持列纯净类型转换隐式 CAST变相函数字符串字段查数字加引号类型严格匹配模糊匹配前缀未知无从找起LIKE %xx改后缀匹配或用 ESOR 陷阱一边失效全盘放弃col_idx1 OR col_no_idx2双索引或改 UNION优化器放弃数据量大回表太贵查全表 20% 数据接受现实或走覆盖索引终极心法索引不是保险箱而是需要精心呵护的精密仪器。失效往往不是因为索引坏了而是因为我们的 SQL“由于过于随意而拒绝了导航”。理解它们就是理解“尊重数据结构”比“盲目堆砌硬件”更重要。记住最好的优化是写出能让 B 树“丝滑”遍历的 SQL。于最左中见秩序于类型中见严谨以覆盖为盾避计算之坑于海量数据中求精准之真。最好的索引是永远处于“待命”状态随时准备为你极速定位。行动指令给开发者/DBA自查 SQL搜索代码库中所有WHERE子句检查是否有函数包裹字段、无引号数字、%开头模糊查。Explain 习惯养成习惯上线前必跑EXPLAIN看到typeALL必须警惕。审查联合索引检查现有的联合索引确认查询是否遵循了最左前缀。监控慢日志找出扫描行数巨大但返回行数很少的 SQL重点优化。类型规范在 ORM 框架或代码规范中强制要求字符串类型查询必须加引号。统计信息更新对核心大表设置定时任务定期ANALYZE。架构评估如果发现大量不可避免的模糊搜索需求认真考虑引入 Elasticsearch。这就是 MySQL 索引失效场景于失效中见逻辑于规范中见性能以类型为界避函数之雷于数据迷宫中求畅通之真。最后送你一句话索引是数据库的灯塔但你的 SQL 必须是那艘懂航向的船。别让隐式的转换、随意的函数、模糊的前缀遮蔽了灯塔的光芒。敬畏规则方能极速航行。️⚡