历史数据查询慢的核心在于归档表索引设计未匹配查询模式：需为时间字段建单列索引，组合查询时时间字段须在联合索引最左位，高频主键字段（如order_id）需显式加索引，常用查询应使用覆盖索引，超大表可结合分区裁剪优化。
历史数据查询慢，核心问题往往不在SQL写法本身，而在归档表的索引设计是否匹配实际查询模式。没有针对性的索引，即使数据已归档，全表扫描仍会发生。
按时间范围查询？必须有时间字段的高效索引
绝大多数历史查询都带 WHERE create_time BETWEEN '2023-01-01' AND '2023-12-31' 这类条件。如果 create_time 或 update_time 没有单独索引，或只有联合索引但时间字段不在最左位，索引就无法生效。
- 优先建单列索引：
CREATE INDEX idx_archive_create_time ON archive_order (create_time); - 若常和状态（如
status）组合过滤，再考虑联合索引，但确保时间字段在前：CREATE INDEX idx_archive_time_status ON archive_order (create_time, status); - 避免在时间字段上用函数，比如
WHERE YEAR(create_time) = 2023—— 会跳过索引
按业务主键回查？别忘了归档后主键的独立索引
线上查订单详情时习惯用 order_id，归档表里它往往不再是主键（主键可能是自增id），但仍是高频查询条件。若没索引，每次回查都是全表扫。
- 为高频查询字段显式加索引：
CREATE INDEX idx_archive_order_id ON archive_order (order_id); - 如果
order_id唯一且常用，可建唯一索引，兼顾约束与性能 - 注意：不要假设“原表有索引，归档表也有”——归档是物理迁移，索引需手动重建
联合查询多？覆盖索引能省掉回表开销
比如经常执行：SELECT order_id, amount, status FROM archive_order WHERE create_time > '2022-01-01' AND status = 'paid';，只查这三列，却要回原表取数据？没必要。
- 建覆盖索引，把 WHERE 条件字段 + SELECT 字段 全部包含进去：
CREATE INDEX idx_cover ON archive_order (create_time, status, order_id, amount); - 注意字段顺序：等值条件（
status）放前，范围条件（create_time）放后；SELECT字段补在末尾 - 覆盖索引不适用于
SELECT *，但历史归档查询通常字段明确，正好适用
数据量极大？考虑分区裁剪替代全表索引
单表超千万甚至上亿行时，单靠B+树索引效果下降明显。按月/季度做 RANGE 分区，能让查询直接定位到某几个分区，跳过90%以上数据。
- 例如按年份分区：
PARTITION BY RANGE (YEAR(create_time))，配合WHERE create_time >= '2022-01-01'可自动剪枝 - 分区键必须是索引的一部分（通常是主键或唯一索引的组成部分），否则无法启用分区裁剪
- 分区不是索引的替代品，而是协同手段：先分区缩小范围，再在分区内走索引
归档表不是“扔进冷库里就完事”，它的索引策略要跟着查询习惯长出来。建得对，查十年数据也秒出；建得随意，归档反而成了性能黑洞。
