联合索引生效需满足最左前缀、避免函数运算、保持类型一致、LIKE 前缀匹配；失效时 EXPLai N 显示 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
