WHERE 条件中使用函数会导致索引失效，因 MySQL 无法直接在 B + 树索引上计算表达式；应改写为范围查询，如 YEAR(create_time)=2023 改为 create_time>=’2023-01-01′ AND create_time
为什么 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 分析真实负载，比凭经验猜更可靠。
