解决分区表回表过多的核心是设计覆盖索引，需包含WHERE条件字段（如dt、status）、ORDER BY字段（create_time）及SELECT非主键列（user_id、name），且首字段宜为分区键以保障分区裁剪生效。
分区表回表过多，本质是查询未命中覆盖索引，导致大量随机IO读取聚簇索引（主键索引）的行数据。解决核心在于让查询所需字段全部落在二级索引中——即设计合理的覆盖索引。
明确哪些字段必须进索引
覆盖索引需包含：WHERE条件字段（按选择性从高到低排序）、JOIN/ORDER BY/GROUP BY涉及字段、SELECT列表中的非主键列。例如：
- 查询 SELECT user_id, name, status FROM orders WHERE dt = '2024-06-01' AND status = 1 ORDER BY create_time DESC
- 分区键是 dt（按天分区），则索引至少应包含：(dt, status, create_time, user_id, name)
- 注意：dt作为分区键虽不需重复建在索引前列，但WHERE中用了就必须出现在索引最左前缀中；create_time放第三位可同时支撑过滤与排序，避免filesort
警惕分区键与索引的协同陷阱
MySQL 5.7+支持“分区裁剪”，但仅当WHERE条件能精确匹配分区表达式时才生效。若索引没包含分区键，或使用了函数/范围条件（如 dt >= '2024-06-01' AND dt < '2024-06-02'），可能引发跨分区扫描，即使索引命中，回表也会放大IO压力。
- 确保WHERE中对分区键的引用是确定的等值或IN列表（如 dt IN ('2024-06-01', '2024-06-02')）
- 避免在分区键上使用函数（如 DATE(dt)），否则分区裁剪失效
- 联合索引首字段尽量设为分区键（如 (dt, status, ...)），提升裁剪准确率
精简SELECT，减少覆盖成本
覆盖索引越宽，索引体积越大、维护开销越高、缓冲池压力越大。不是所有字段都值得放进索引。
- 优先覆盖高频、低延迟要求的报表字段（如统计类指标、状态码、时间戳）
- 大字段（TEXT、BLOB、长VARCHAR）坚决不进索引；用ID关联主表查详情，比全量覆盖更高效
- 考虑用生成列（Generated Column）+索引替代复杂表达式，例如把 YEAR(create_time) 存为虚拟列再建索引
验证是否真正覆盖
执行 EXPLAIN FORMAT=JSON，重点看：
- key 显示实际使用的索引名
- key_length 是否匹配你预期的索引长度（比如 (dt,status,create_time) 应该比只用 (dt) 长得多）
- Extra 中不含 Using where; Using index condition 是正常；若出现 Using filesort 或 Using temporary，说明排序/分组未被索引覆盖
- 最关键：确认 Extra 出现 Using index（表示纯索引扫描，无回表）
