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）
真正难处理的是“既要多条件过滤、又要任意字段排序、还要深分页”，这时候单靠索引很难解决，得结合业务逻辑做裁剪或缓存。
