sql报表多条件筛选慢的核心是索引未覆盖查询模式；应按等值优先、高选择性高频字段在前的原则建组合索引，利用最左前缀匹配where顺序，并通过覆盖索引避免回表，同时定期清理冗余索引。
SQL报表多条件筛选慢，核心问题往往不在SQL写法，而在索引没覆盖查询模式。组合索引不是字段越多越好，关键要匹配WHERE子句的过滤顺序和使用频率。
按查询频率和过滤强度排字段顺序
组合索引最左前缀原则决定了字段顺序直接影响索引是否生效。应把高选择性（过滤掉大量数据）、高频出现在WHERE中的字段放在前面。
- 例如：用户表中 status（只有'active'/'inactive'）选择性低，create_time（时间范围跨度大）选择性高，若常查“活跃用户+最近7天”，索引应建为
(status, create_time)而非反过来——因为MySQL能跳过status直接走create_time的前提是status用了等值条件；若status是范围（如IN或!=），后续字段就无法走索引。 - 用
EXPLAIN验证：关注key_len是否随条件增加而变长，rows是否显著减少。如果加了第三个条件但key_len没变，说明该字段没被索引利用。
覆盖查询，避免回表
报表常需SELECT大量字段，若索引不包含SELECT列，MySQL需先查索引再回主键聚簇索引取数据，I/O翻倍拖慢速度。
- 在组合索引末尾加上常用查询字段（非WHERE条件字段），构成“覆盖索引”。例如报表常查
SELECT user_id, name, amount FROM orders WHERE dept_id = ? AND status = ? ORDER BY create_time DESC，可建索引(dept_id, status, create_time, user_id, name, amount)。 - 注意：TEXT、BLOB等大字段不宜加入索引；VARCHAR超过一定长度（如500字符）也建议只索引前缀，否则索引体积膨胀影响效率。
区分等值与范围条件的位置
组合索引中，等值条件（=、IN）可连续排列，一旦出现范围条件（>、
- 错误示例：索引
(a, b, c)，查询WHERE a = 1 AND b > 10 AND c = 5—— c不会走索引。 - 优化方向：把c提前到b之前（若业务允许），或拆分查询逻辑，用子查询/临时表先筛出b范围结果，再对c精确匹配。
- LIKE模糊查询：只有前缀匹配（
LIKE 'abc%'）可用索引；LIKE '%abc'或LIKE '%abc%'一定无法使用索引，考虑全文索引或倒排表替代。
定期清理冗余和低效索引
一张表索引过多不仅占用空间，还会拖慢INSERT/UPDATE，并干扰优化器选错执行计划。
- 用
sys.schema_unused_indexes（MySQL 5.7+）或分析information_schema.STATISTICS+ 慢日志，识别长期未被使用的索引。 - 合并相似索引：已有
(a, b)和(a, b, c)，通常只需保留后者；但若存在WHERE a = ? ORDER BY c的独立查询，则(a, c)不可被(a, b, c)替代。 - 对报表专用表，可考虑读写分离+只读实例上建更重的组合索引，不影响线上事务性能。
