SQL批量与多条件查询慢的核心在于执行计划不合理、索引未生效或写法触发全表扫描；优化应聚焦覆盖索引、拆分IN列表、避免字段运算及NULL判断等。
SQL批量查询和多条件查询慢，核心问题往往不在数据量本身，而在于执行计划不合理、索引未生效或条件写法触发全表扫描。优化的关键是让数据库“少走弯路”，而不是单纯加硬件。
用覆盖索引减少回表
当查询字段和WHERE条件字段能被同一个索引全部包含时，数据库可直接从索引中拿到所有数据，无需回主表查——这叫覆盖索引。例如：
SELECT user_id, status, create_time FROM orders WHERE status = 'paid' AND create_time > '2024-01-01';
如果建复合索引 (status, create_time, user_id)，就能完全覆盖该查询。注意字段顺序：等值条件（status）放最左，范围条件（create_time）居中，查询字段（user_id）放最后。
拆分IN列表避免执行计划失效
大批量ID用IN查询（如 IN (1,2,3,...,5000)）容易导致优化器放弃使用索引，改走全表扫描。更稳妥的做法是：
- 单次IN控制在500个以内，分批执行
- 用临时表+JOIN替代大IN：先INSERT IDs进临时表，再INNER JOIN查询
- 对有序ID范围，优先用BETWEEN或多个AND组合（如 id >= 1000 AND id
慎用OR和函数条件
WHERE a = 1 OR b = 2 可能导致索引失效，尤其当a、b无联合索引时。建议改为UNION ALL（前提是两个子查询都能走索引）：
SELECT * FROM users WHERE city = 'Beijing'
UNION ALL
SELECT * FROM users WHERE age > 35 AND city IS NULL;
同理，避免在WHERE中对字段做运算或函数调用，比如 WHERE YEAR(create_time) = 2024，应改写为 create_time >= '2024-01-01' AND create_time 。
用EXPLAIN验证实际执行路径
每次改写后务必执行 EXPLAIN FORMAT=TREE（MySQL 8.0+）或 EXPLAIN ANALYZE（PostgreSQL），重点看：
- type是否为 const/ref/range（健康），而非 ALL 或 index
- key是否命中预期索引
- rows预估扫描行数是否明显下降
- Extra里有没有 Using filesort 或 Using temporary（需优化）
不复杂但容易忽略。
