不一定。mysql是否使用索引取决于字段是否有索引、数据分布、条件顺序及优化器判断；应建联合索引，等值条件在前、范围条件在后，避免在索引字段上使用函数或表达式。
WHERE 子句里多个 AND 条件是否自动走索引？
不一定。MySQL 是否使用索引，取决于字段是否有索引、数据分布、条件顺序和优化器判断，不是写上 AND 就自动加速。
实操建议：
- 给高频查询的组合字段建联合索引，顺序按
WHERE中等值条件优先、范围条件靠后（如CREATE INDEX idx_user_status_time ON users(status, created_at)） - 避免在索引字段上用函数或表达式，例如
WHERE YEAR(created_at) = 2024会失效；改用created_at >= '2024-01-01' AND created_at - 用
EXPLAIN看type是否为ref或range，key列是否显示用了哪个索引
IN 和 OR 多值筛选哪个性能更好？
IN 通常更优，尤其当值数量适中（几十以内）、字段有索引时；OR 在某些版本中可能导致索引失效或全表扫描。
常见错误现象：WHERE status = 'A' OR status = 'B' OR status = 'C' 可能不走索引，而 status IN ('A','B','C') 更容易命中。
注意事项：
-
IN后面值过多（如上千）会导致优化器放弃索引，改用临时表或全表扫描；此时考虑分批查或用JOIN临时表 -
OR跨不同字段（如WHERE a=1 OR b=2）基本无法用复合索引，可考虑UNION ALL拆解 - MySQL 8.0+ 对
IN的常量列表做了优化，但依然建议控制数量
模糊查询 LIKE '%xxx' 还能优化吗？
以通配符开头的 LIKE '%xxx' 无法使用 B+ 树索引，属于典型“扫表”场景。
可行替代方案：
- 用全文索引（
FULLTEXT）配合MATCH ... AGAINST，适合文本内容较长、语义检索为主的字段 - 前置生成冗余字段并建索引，例如对
title字段反向存储为title_reversed，查LIKE '%abc'改为title_reversed LIKE 'cba%' - 用 Elasticsearch 或 Redisearch 做前缀/模糊加速，MySQL 只存主数据
注意：即使加了索引，LIKE 'xxx%' 是可以走索引的，但 LIKE '%xxx%' 仍不行。
ORDER BY + LIMIT 配合多条件时为什么变慢？
因为 MySQL 可能先按条件过滤出大量行，再排序取前 N 条——如果没覆盖索引，就会产生临时表 + filesort。
关键点：
- 确保
ORDER BY字段包含在联合索引中，且位置在WHERE等值条件之后、范围条件之前（例如INDEX(status, create_time)支持WHERE status='active' ORDER BY create_time DESC） - 避免
SELECT *，只查必要字段；若要查关联表字段，考虑延迟关联（SELECT ... FROM (SELECT id FROM t WHERE ...) t1 JOIN t ON t1.id = t.id） -
LIMIT很大（如LIMIT 10000, 20）时，偏移量越大越慢；改用游标分页（记录上一页最大create_time）
真正难处理的是“既要多条件过滤、又要任意字段排序、还要深分页”，这时候单靠索引很难解决，得结合业务逻辑做裁剪或缓存。
