WHERE 中用了函数或表达式，索引直接失效
MySQL 索引里存的是原始值，一旦你在
WHERE条件里对索引列做计算、取子串、格式化时间，优化器就无法用索引做快速定位。
常见错误现象：
EXPLAIN显示
type=ALL或
key=NULL，哪怕字段明明建了索引。
WHERE DATE(create_time) = '2024-04-21'→ 改成
WHERE create_time >= '2024-04-21' AND create_time
WHERE SUBSTRING(name, 1, 3) = 'Tom'→ 改成
WHERE name LIKE 'Tom%'
WHERE price * 1.1 > 100→ 改成
WHERE price > 100 / 1.1
注意：MySQL 5.7+ 可用「生成列 + 索引」绕过这类限制，但要权衡写入开销和维护成本。
联合索引没按最左前缀用，右边全作废
复合索引
INDEX(a, b, c)不是“三个字段都有索引”，而是按顺序组织的 B+ 树。跳过最左或中间列，后续列就进不了搜索路径。
使用场景：查用户时经常按
city和
age过滤，但只建了
INDEX(city, age)，却写了
WHERE age > 25—— 这条语句根本不会走索引。 ❌
WHERE b = 2 AND c = 3（没包含
a） ❌
WHERE a = 1 AND c = 3（跳过了
b） ✅
WHERE a = 1 AND b > 10 AND c = 3（
c不生效，但
a,b有效）
别指望优化器“聪明地重排条件顺序”——它只认定义顺序。业务查询模式变了，索引也得跟着调。
隐式类型转换让索引悄悄下线
字段是
VARCHAR，你传数字；字段是
INT，你传字符串。MySQL 会自动加转换函数，等价于在索引列上套了一层函数，索引立刻失效。
典型错误：
SELECT * FROM users WHERE id = '123'（
id是
INT）
SELECT * FROM orders WHERE order_no = 10001（
order_no是
VARCHAR）
JOIN时两边字段类型不一致，比如
t1.user_id INT关联
t2.uid VARCHAR
解决方法很简单：查什么类型，就传什么类型。用
EXPLAIN看
Extra字段，如果出现
Using where; Using index是好的，但若带
Using temporary或没显示
key，就要怀疑类型是否对齐。
LIKE 左模糊、OR 拆分、IS NULL 都容易踩坑
这些不是“绝对不走索引”，而是在多数数据分布和 MySQL 版本下，优化器倾向放弃索引走全表扫描。
LIKE '%abc'：B+ 树没法从中间开始找，必须扫全量 → 改用
LIKE 'abc%'或上
FULLTEXT
WHERE a = 1 OR b = 2：即使
a和
b各有单列索引，
OR通常也不走 → 拆成
UNION或建
INDEX(a,b)
WHERE status IS NULL：如果字段没设
NOT NULL，
IS NULL查询基本不走索引 → 建索引前先加约束，或显式建
INDEX(status)（MySQL 8.0+ 对
IS NULL支持更好）
最容易被忽略的一点：索引列参与
!=、
NOT IN、
NOT EXISTS时，只要排除比例稍高（比如 > 15%），优化器大概率放弃索引——这不是 bug，是成本估算的结果。
