SQL报表多条件统计慢的核心原因是查询字段未被索引有效覆盖；联合索引需按等值→最左前缀→范围/排序顺序设计，如(status, region, create_time)可高效支持status='paid' AND region='east' AND create_time>'2024-01-01'；避免冗余单列索引，优先建立高频组合的覆盖索引，并改写函数条件为可索引形式。
SQL报表多条件统计慢，核心问题往往不是SQL写得不好，而是查询条件涉及的字段没被索引有效覆盖。联合索引不是“把所有WHERE字段堆在一起”就管用，关键在于**匹配顺序、过滤强度和查询模式**。
联合索引要按“等值 → 最左前缀 → 范围/排序”顺序设计
MySQL（及多数主流数据库）使用B+树索引，只支持从左到右连续匹配。例如查询：
SELECT COUNT(*) FROM orders WHERE status = 'paid' AND region = 'east' AND create_time > '2024-01-01';
理想联合索引是：(status, region, create_time)，因为：
- status 是高区分度等值条件，放在最左可快速定位数据块
- region 是第二个等值条件，继续缩小范围
- create_time 是范围查询，放最后仍可利用索引有序性做区间扫描
若反过来建 (create_time, status, region)，则 status = 'paid' 无法走索引——它不在最左且前面是范围，索引失效。
避免冗余索引，但别省略高频组合
一张表不需要为每个字段单独建索引，但也不该只靠单列索引拼凑。比如已有 (status) 和 (region) 单列索引，对 WHERE status = ? AND region = ? 查询，优化器通常只会选其一，导致回表或全表扫描。
更优做法是：
- 删掉低效单列索引（如只有
region且区分度低） - 补一个高频组合的联合索引，如
(status, region) - 若还有
ORDER BY create_time，可扩展为(status, region, create_time)（前提是排序方向一致，如都是 ASC）
统计类查询要关注“覆盖索引”和“索引下推”
报表常只查 COUNT(*) 或少量字段，不必回主表。例如：
SELECT COUNT(*), SUM(amount) FROM orders WHERE status IN ('paid','shipped') AND year(create_time) = 2024;
这时建议建覆盖索引：(status, create_time, amount)。注意：
-
year(create_time) = 2024无法直接走索引，应改写为create_time >= '2024-01-01' AND create_time -
amount加入索引，使聚合在索引层完成，避免回表 - MySQL 5.6+ 支持索引下推（ICP），能把部分 WHERE 条件下推到存储引擎层过滤，进一步减少回表次数
定期检查执行计划，别信“建了索引就快”
用 EXPLAIN FORMAT=TRADITIONAL 看实际是否用了索引、是否用了索引全扫描（type=range/index）、key_len 是否合理、rows 是否明显下降。
常见陷阱：
- 隐式类型转换：如
WHERE user_id = '123'（user_id 是 INT），导致索引失效 - 函数包裹字段：如
WHERE DATE(create_time) = '2024-01-01'，应改用范围写法 - OR 条件未统一索引：多个 OR 分支没共用同一索引时，可能退化为全表扫描
