为什么 WHERE
条件里用了函数，索引就失效了
MySQL 无法对表达式结果直接使用 B+ 树索引，比如写
WHERE YEAR(create_time) = 2023，即使
create_time有索引，也会全表扫描。优化方式是把函数移到右边，改写为范围查询：
WHERE create_time >= '2023-01-01' AND create_time 。
常见踩坑点：
LIKE '%abc'开头通配符必然走全表；
LIKE 'abc%'才能用索引
IS NULL在某些版本（如 MySQL 5.7）下可走索引，但
IS NOT NULL不一定，尤其字段允许 NULL 且有大量空值时 隐式类型转换，比如
user_id是
VARCHAR，却写成
WHERE user_id = 123，MySQL 会转成数字比较，导致索引失效
联合索引的最左前缀原则不是“从左开始连续用”，而是“跳过中间列后，右边列一定无效”
假设建了联合索引
INDEX idx_name_age_status (name, age, status)，以下查询能命中索引：
WHERE name = 'Alice' AND age = 25 WHERE name = 'Alice' AND age > 20 AND status = 1 WHERE name LIKE 'Ali%' AND age = 25
但这些不行：
WHERE age = 25—— 没有
name，跳过最左列，整个索引失效
WHERE name = 'Alice' AND status = 1—— 缺少中间列
age，
status无法利用索引
WHERE name > 'Alice' AND age = 25—— 范围查询后，右边列（
status）虽然在
EXPLAIN中显示
key_len包含它，但实际只用于过滤，不参与索引查找
ORDER BY
和 LIMIT
组合时，没覆盖索引会导致临时表 + 文件排序
例如执行
SELECT id, name FROM users WHERE city = 'Beijing' ORDER BY created_at DESC LIMIT 10，如果只有
city单列索引，MySQL 必须先查出所有北京用户，再内存或磁盘排序，效率极低。解决方案是建覆盖索引：
ALTER TABLE users ADD INDEX idx_city_created (city, created_at DESC, id, name);
注意点：
MySQL 8.0+ 支持降序索引，5.7 及以前会忽略DESC，按升序建但
ORDER BY ... DESC仍可能触发 filesort 如果
SELECT字段太多，覆盖索引体积大、更新成本高，需权衡；优先保证
WHERE+
ORDER BY列，再补上主键（用于回表）
LIMIT 10000, 10这类深分页，即使有索引，也要先跳过 10000 行，建议改用游标分页（如
WHERE id > last_seen_id ORDER BY id LIMIT 10）
EXPLAIN
中 type=ALL
或 Extra=Using filesort/Using temporary
是明确信号
不要只看是否“用了索引”，重点看
type值和
Extra字段：
type=ref或
range是健康状态；
type=ALL就是全表扫描
Extra=Using index表示覆盖索引；
Using index condition是 ICP（索引条件下推），说明部分条件在引擎层过滤
key_len值比预期小，可能是字符集或前缀索引截断（如
VARCHAR(255)只建了前 50 个字符索引） 用
SHOW INDEX FROM table_name确认索引字段顺序、是否唯一、是否前缀长度，别只信建表语句注释
真正难的不是加索引，是判断哪些查询值得加、加在哪几列、要不要冗余索引。线上慢查日志 +
pt-query-digest分析真实负载，比凭经验猜更可靠。
