联合索引生效需满足最左前缀、避免函数运算、保持类型一致、LIKE前缀匹配；失效时EXPLAIN显示key为NULL或type为ALL。
联合索引不是“建了就一定生效”，它对查询写法极其敏感。排查是否失效，核心就一条：用 EXPLAIN 看执行计划，重点盯 key 是否为 NULL、type 是否为 ALL（全表扫描）。下面这几种写法最常踩坑，一一对号入座就能快速定位。
一、最左前缀没守牢，索引直接“不认人”
联合索引 (a, b, c) 不是“三个字段随便用”，必须从最左边连续使用。跳过 a，只查 b 或 b+c，索引完全无效；只查 a 和 c（中间跳过 b），c 那部分也用不上。
- ❌ WHERE b = 20 AND c = 'Beijing' → 不走索引
- ❌ WHERE a = 'Tom' AND c = 'Shanghai' → c 列无法利用索引
- ✅ WHERE a = 'Tom' → 可用索引
- ✅ WHERE a = 'Tom' AND b > 18 → a、b 生效，c 失效（范围查询阻断后续）
二、函数/运算一加，索引当场“下线”
索引存的是原始值，不是计算结果。只要在索引列上套函数、做加减乘除，MySQL 就没法拿索引树去比对，只能逐行取数再算——等于放弃索引。
- ❌ WHERE YEAR(create_time) = 2023 → 改成 create_time >= '2023-01-01' AND create_time
- ❌ WHERE price * 1.1 > 99 → 改成 price > 99 / 1.1（计算移至右边）
- ❌ WHERE SUBSTR(name, 1, 3) = 'Tom' → 改成 name LIKE 'Tom%'（前提是能接受前缀匹配）
三、类型不一致，隐式转换悄悄“拆桥”
字段是 INT 却传字符串，字段是 VARCHAR 却传数字——MySQL 会自动转类型，但这一转，索引列就被“动了手脚”，无法直连索引值。
- ❌ WHERE user_id = '1001'（user_id 是 INT）→ 改为 user_id = 1001
- ❌ WHERE phone = 13800138000（phone 是 VARCHAR）→ 改为 phone = '13800138000'
- ? 提示：开启 STRICT_TRANS_TABLES 模式可让这类错误直接报错，避免静默失效
四、LIKE 前带 %，B+ 树彻底“找不到北”
B+ 树按字典序存储，只支持“已知前缀”的快速定位。LIKE '%关键词' 相当于让数据库猜开头，只能扫全表。
- ❌ WHERE title LIKE '%数据库' → 索引失效
- ✅ WHERE title LIKE '数据库%' → 可用索引（前缀匹配）
- ✅ WHERE title LIKE '数据%库%' → 第一个 % 后的部分无法走索引，但前缀 '数据' 仍有效
- ? 替代方案：高频模糊搜索考虑全文索引（FULLTEXT）或 Elasticsearch
