根本解法是索引覆盖和条件下推：索引覆盖使查询字段全在索引叶子节点中，避免回表；条件下推将where尽量下推至数据源侧，减少中间结果集。
大表全扫描是sql报表性能瓶颈的常见原因，根本解法不是“加索引”三个字能概括的，而是要结合查询逻辑，让数据库尽可能少读数据页——核心手段就是索引覆盖和条件下推。
什么是索引覆盖？为什么它能避免回表？
当一条查询所需的所有字段（select列 + WHERE/ORDER BY/GROUP BY涉及的列）都能从某个索引的B+树叶子节点中直接获取时，就构成索引覆盖。此时mysql无需回到主键索引（聚簇索引）再查整行数据，彻底跳过“回表”开销。
- 例如：表order_info(id, user_id, status, amount, create_time)，执行SELECT user_id, status FROM order_info WHERE create_time > ‘2024-01-01’；若建索引(create_time, user_id, status)，就能覆盖——WHERE条件用前导列，SELECT字段全在索引中。
- 注意：主键字段（如id）默认包含在二级索引中，但显式写入索引定义更清晰，也方便后续扩展。
- 覆盖索引对count(*)、MIN/MAX等聚合也极有效，尤其配合范围条件时，可能仅需遍历索引B+树最左或最右路径。
条件下推：别让中间结果膨胀
报表常嵌套子查询、JOIN或使用视图，若过滤条件写在最外层，数据库可能先生成巨大中间集（如千万级JOIN结果），再过滤——等于白扫一遍大表。应把WHERE条件尽可能“下推”到最靠近数据源的位置。
- JOIN时，把关联后要过滤的条件写在ON里（而非WHERE），特别是左连接中对右表的限制，否则会先完成LEFT JOIN再过滤，导致右表NULL行被保留又丢弃。
- 子查询中，优先用EXISTS替代IN（尤其右表大时），因为EXISTS可利用索引快速判断存在性，且天然支持条件下推；而IN可能触发全量物化。
- 使用union ALL代替UNION，避免去重排序开销；若业务允许，把时间分区条件（如dt=’202401’）硬编码进每个子查询，而非最后统一过滤。
如何验证是否生效？看执行计划关键项
不看EXPLAIN，一切优化都是猜测。重点关注三处：
- type：至少达到range（范围扫描），理想是ref或const；若仍是ALL，说明没走索引或索引失效。
- key：显示实际使用的索引名；为NULL表示未命中索引。
- Extra：出现using index即索引覆盖成功；若含Using filesort或Using temporary，说明ORDER BY/GROUP BY未被索引支持，需调整索引顺序或补充字段。
实战建议：从报表SQL反向设计索引
别一上来就给大表所有字段建索引。按高频报表SQL倒推：
- 列出该SQL的WHERE等值条件列 → 作为索引最左前缀；
- 追加范围条件列（如时间、金额）→ 放在等值列之后（B+树只支持单个范围列后缀）；
- 把SELECT、ORDER BY、GROUP BY中用到的其他字段，按需追加到索引末尾 → 实现覆盖；
- 避免冗余索引：如已有(a,b,c)，就不必再建(a,b)；用SHOW INDEX和sys.schema_unused_indexes定期清理。