根本解法是使用覆盖索引，即索引包含WHERE条件字段、ORDER BY字段和SELECT返回字段（不含TEXT/BLOB等大字段），且遵循等值→范围→排序→查询字段的顺序，避免函数或表达式导致索引失效。
SQL报表查询性能差，常因回表次数过多导致。根本解法不是加索引数量，而是用覆盖索引把查询所需字段“一并打包”进索引，让数据库直接从索引中取全量数据，彻底避免回表。
明确哪些字段必须进覆盖索引
覆盖索引要包含 WHERE 条件字段 + ORDER BY 字段 + SELECT 返回字段（不含大字段如 TEXT、BLOB）。例如：
- 查询语句：
SELECT user_id, name, city FROM users WHERE status = 1 AND create_time > '2024-01-01' ORDER BY create_time DESC; - 理想覆盖索引：
INDEX idx_cover (status, create_time, user_id, name, city) - 注意顺序：等值条件（
status）放最左，范围条件（create_time）紧跟其后，排序字段需连续，SELECT 字段补在末尾
规避大字段和函数干扰
覆盖索引无法包含 TEXT、BLOB、JSON 等大字段，也不支持对索引字段使用函数或表达式。常见陷阱包括：
- 错误写法：
SELECT id, UPPER(name) FROM t WHERE status = 1;→UPPER(name)无法走索引，name 也不能作为覆盖字段被直接读取 - 错误写法：
SELECT * FROM t WHERE DATE(create_time) = '2024-01-01';→ 函数导致索引失效，应改用范围查询：create_time >= '2024-01-01' AND create_time - 若必须返回大字段，考虑拆分查询：先用覆盖索引查主键，再用主键 IN 子查询补大字段（适用于结果集较小时）
验证是否真正覆盖
执行 EXPLAIN 查看执行计划，关键看三项：
-
type：应为
ref或range（非ALL或index） - key：显示实际使用的索引名
-
Extra：必须出现
Using index（表示索引覆盖），不能有Using filesort或Using temporary
若 Extra 中出现 Using index condition，说明用了 ICP（索引条件下推），是优化但不等于覆盖；只有 Using index 才代表零回表。
增量重构策略，降低上线风险
生产环境不宜直接删旧索引建新索引，推荐分步操作：
- 先创建新覆盖索引（ONLINE DDL 支持的 MySQL 5.6+ 或 8.0 可设
ALGORITHM=INPLACE） - 用
pt-query-digest或慢日志确认高频报表 SQL 是否已走新索引 - 观察 buffer pool 命中率与磁盘 IO 是否下降（
SHOW ENGINE INNODB STATUS中的 Buffer pool hit rate） - 稳定运行 3–7 天后，再删除冗余的单列索引或前缀重复的低效索引
