报表系统中最常见的性能投诉就是：白天数据量小的时候跑得好好的，数据涨到几千万行之后，同样一条SQL从3秒变成30分钟。抓个执行计划一看，type是ALL，扫描行数等于全表，索引形同虚设。这类问题的解决思路其实相当固定：先确认索引为什么失效，再通过覆盖索引避免回表，最后借助条件下推让过滤尽量在存储引擎层完成。下面结合一个真实的报表场景，把这三个环节完整讲清楚。
一、先看慢在哪：读懂执行计划里的全表扫描
假设有一张订单明细表，结构如下，数据量约8000万行：
CREATE TABLE order_detail (
id BIGINT PRIMARY KEY,
order_id BIGINT NOT NULL,
customer_id BIGINT NOT NULL,
channel TINYINT NOT NULL,
status TINYINT NOT NULL,
amount DECIMAL(12,2),
created_at DATETIME NOT NULL,
KEY idx_created (created_at),
KEY idx_customer (customer_id)
);报表SQL长这样：按客户和日期范围统计各渠道的销售额。用EXPLAIN看执行计划：
SELECT customer_id, channel, SUM(amount) FROM order_detail WHERE customer_id = 88231 AND created_at >= '2024-01-01' AND created_at < '2024-06-01' GROUP BY channel;
结果extra列显示Using where，key列是NULL，也就是全表扫描。原因不难分析：customer_id上虽然有索引，但单个客户的数据可能占全表的百分之几，优化器估算走这个索引要回表几十万次，还不如直接全表扫。而created_at索引的选择性同样不高，单列索引都不划算。这是典型的"索引存在但不可用"场景，问题根源在于没有针对查询条件设计联合索引。
注意这里有一个容易踩的坑：很多人看到全表扫描就急着加索引，加了idx_customer_created之后发现计划还是不走，原因是统计信息里的cardinality偏差太大，或者WHERE里对列做了函数处理。排查时先用EXPLAIN和SHOW INDEX FROM order_detail确认索引的基数是否接近真实值，必要时执行ANALYZE TABLE重新采样。
二、覆盖索引：把回表彻底消掉
上面的SQL查询了customer_id、channel、amount三列，加上过滤条件created_at，一共四列。如果建立一个联合索引把这几列全部包含进去，InnoDB就可以直接从索引里取数据，extra列会显示Using index，这一步就叫索引覆盖，省掉的正是回表的随机IO。
ALTER TABLE order_detail ADD INDEX idx_cust_time_chan_amt (customer_id, created_at, channel, amount);
索引列的顺序是有讲究的。等值条件的customer_id放最前面，范围条件的created_at放第二位（范围列之后的列无法参与索引定位，但仍可用于覆盖），channel用于分组，amount放在最后纯粹是为了覆盖。改完再跑EXPLAIN，key列变成idx_cust_time_chan_amt，扫描行数从8000万降到这个客户半年内的几十万行，extra同时出现Using index，整条SQL在SSD机器上从原来的25分钟降到1.8秒。
覆盖索引的代价也要心里有数：索引变宽意味着占用的磁盘空间增大，写入时需要维护的索引页更多，插入和更新的开销会上升。报表库通常是读多写少的场景，这笔账划算；但如果是高并发的交易表，就要权衡是否单独为报表建一张带宽索引的影子表，或者用只读从库来承载报表查询。另外，如果SELECT的列太多导致索引过宽，可以考虑把大字段查询拆成两步，第一步用覆盖索引拿到主键，第二步再回表取详情。
三、条件下推：让过滤发生在存储引擎层
没有覆盖索引时，MySQL有一个兜底优化叫索引条件下推（Index Condition Pushdown，ICP）。以前的使用方式是：存储引擎按索引定位到一行，把整行返回给Server层，Server层再用WHERE条件过滤，不满足的行白白回表了一次。开启ICP后，Server层会把能够用索引列判断的条件（比如本例中的created_at范围）下推给存储引擎，先在索引里过滤，通过的才回表。
在EXPLAIN的extra列里看到Using index condition就说明ICP生效了。它受系统变量控制，确认方法如下：
-- 查看ICP是否开启 SELECT @@optimizer_switch LIKE '%index_condition_pushdown=on%'; -- 会话级开启（一般默认就是开的） SET optimizer_switch = 'index_condition_pushdown=on';
ICP的适用场景是：WHERE条件里既有能走索引定位的列，也有索引里存在但无法用于定位的列。例如联合索引(customer_id, created_at, channel)中，created_at是范围条件时，channel虽然排在范围列之后无法参与定位，但如果WHERE里写死了channel = 2，这个条件依然可以被下推到引擎层，在索引里就过滤掉大量无关行，减少回表次数。本例加上channel = 2后，回表次数从30万次降到了9万次左右，耗时进一步下降约40%。
需要注意ICP并不能替代覆盖索引：ICP只是减少回表，不能消除回表。优先级应该是先争取覆盖索引（Using index），做不到时再依靠ICP（Using index condition）。另外多表关联场景下，MySQL 8.0.18之后引入的哈希连接配合连接条件也能获得类似效果，被驱动表的关联列上有索引时，关联条件的过滤同样会尽可能下推。
四、验证与防退化：别让优化成果悄悄溜走
优化做完不是终点。报表SQL经常会被人改字段、加条件，一次不经意的改动就可能让索引彻底失效。建议做三件事：第一，把EXPLAIN结果固化到上线检查流程，重点盯type、key、extra三个字段，出现ALL或Using filesort骤增时告警；第二，对范围条件的写法做规范约束，比如created_at >= '2024-01-01' AND created_at < '2024-07-01'这种左闭右开写法，比BETWEEN和函数包装更稳，且绝不写DATE(created_at) = '2024-05-01'这种对列做函数的表达式，那样索引直接报废；第三，定期执行ANALYZE TABLE刷新统计信息，特别是大批量批量导入之后。
还有一种情况值得单独说：隐式类型转换。如果customer_id在表里是BIGINT，而SQL里写成WHERE customer_id = '88231'（字符串），MySQL会把列转成字符串比较，索引同样用不上。这类问题在EXPLAIN里表现为明明有索引却不走，看warning信息能看到CAST字样，排查时用SHOW WARNINGS能看到优化器改写后的真实SQL，非常实用。
总结一下这套方法的核心：先通过EXPLAIN定位全表扫描的真实原因（索引缺失、统计信息偏差、函数或隐式转换），再用联合索引配合覆盖特性消除回表，利用条件下推把过滤压到存储引擎层，最后用流程化的手段守住优化成果。绝大多数报表慢查询都能沿着这条路径解决，而且不需要升级硬件。
SQL优化索引覆盖条件 pushdown修改时间：2026-09-10 06:58:42