or 多条件查询慢因索引难以合并，易退化全表扫描；应改用 union all、建独立或联合索引、避免函数/类型转换；前导通配符 like 无效索引，小数据量可接受，大数据量需全文索引或缓存；深分页优化需覆盖索引+回表，多条件高并发场景需物化或缓存。
WHERE 子句里多个 OR 为什么慢得离谱
因为数据库很难有效使用索引做 OR 合并，尤其当各分支字段无联合索引覆盖时，往往退化成全表扫描。
常见错误现象：EXPLAIN 显示 type: ALL 或 key: NULL，哪怕单个条件本身能走索引。
- 优先改写为
UNION ALL（注意去重需求）：每个子查询独立走索引，再合并结果 - 确保每个
OR分支的字段都建了单独索引，或组合成覆盖型联合索引（顺序按查询频率和选择性排） - 避免在
OR中混用函数或类型转换，比如status = '1' OR CAST(user_id AS char) = '123'，会直接废掉索引
LIKE ‘%keyword’ 真的没法优化吗
前导通配符让 B-Tree 索引完全失效，但不是所有场景都只能硬扫。
使用场景：搜索日志内容、商品标题、用户备注等非结构化文本字段。
- 如果数据量不大（FORCE INDEX 反而更慢，不如接受全表扫描
- 考虑倒排索引方案：用
MATCH ... AGAINST（mysql 全文索引），但只支持英文分词或中文插件（如ngram） - 业务允许时，把前缀匹配改成后缀存储（如存
reverse(title)），再查LIKE 'rekw%'——前提是查询模式固定且可预知
JOIN 多张大表时执行计划突然崩了
优化器选错驱动表或连接算法（比如该用 index_merge 却用了 Nested Loop），本质是统计信息过期或条件太“模糊”。
常见错误现象：EXPLAIN 中 rows 预估严重偏低，实际执行秒变分钟；using join buffer 频繁出现。
- 先跑
ANALYZE table更新统计信息，比调 SQL 更快见效 - 用
STRAIGHT_JOIN强制指定驱动表顺序（仅限 MySQL），但必须配合EXPLAIN验证效果 - 检查
ON条件是否包含隐式类型转换，比如t1.id = t2.user_id但一个是BIGINT、一个是VARCHAR，会禁用索引
ORDER BY + LIMIT 在深分页时卡死
数据库仍要先排序全部符合条件的几百万行，再取前 20 条，LIMIT 压根不减少中间计算量。
性能影响：从 10ms 跳到 5s+ 往往就发生在 OFFSET 超过 10 万之后。
- 用游标分页替代
OFFSET：记录上一页最后一条的id或时间戳，下一页查WHERE id > ? ORDER BY id LIMIT 20 - 如果必须用
OFFSET，先用覆盖索引查出id列，再回表——避免select *直接拖垮 IO - 别在
ORDER BY字段上建索引就以为万事大吉，确认WHERE条件能否复用同一索引，否则仍是两遍扫描
最麻烦的是多条件组合过滤 + 深分页 + 高并发，这时候光靠 SQL 优化顶不住，得提前物化中间结果或引入缓存层。索引不是万能胶，它只对「确定性高」的访问路径友好。