归档表查询慢的核心原因是索引缺失、分区未用、条件写法不当和统计信息过期；应先确认sql是否真查归档表，再通过精准时间条件、合理索引、更新统计信息及避免隐式转换来优化。
归档表查询慢，核心问题往往不是数据量大本身，而是查询没走对路——索引缺失、分区未用、条件写法不当、统计信息过期，这些比“加机器”更关键。
确认是否真在查归档表
很多“归档查询慢”的问题，实际是业务没分清归档表和在线表，误把归档表当主表连查。先检查 SQL 执行计划（EXPLAIN 或 EXPLAIN ANALYZE），看是否真的命中了归档表（如 sales_history、log_archive_2023 等命名明显的表）。如果执行计划里出现全表扫描或跨多个归档分区的合并扫描，就得针对性优化。
按时间范围精准定位分区或子表
归档表通常按月/年分区（Range Partition）或按哈希拆分（List/Hash）。必须让 WHERE 条件能被优化器识别并裁剪：
- 用确定的时间字面量，避免函数包裹时间字段：✅ order_date >= '2022-01-01'；❌ DATE(order_date) = '2022-01-01'（会禁用分区裁剪）
- 避免使用变量或参数化时间导致分区不可推导（尤其在存储过程中），可考虑用动态 SQL 或显式指定分区名（如 MySQL 的 PARTITION (p202201)）
- PostgreSQL 中启用 constraint_exclusion = on，确保分区约束参与裁剪
为高频查询路径建最小必要索引
归档表一般读多写少，索引成本低、收益高。但别盲目建复合索引——先看最常查的组合条件：
- 单字段高频过滤（如 status、tenant_id）→ 单列索引
- 时间 + 业务键联合查询（如查某客户2021年所有订单）→ 建 (customer_id, order_date) 或 (order_date, customer_id)，顺序依选择性而定：高区分度字段放前（如 customer_id 区分度远高于 order_date 时优先）
- 只查少量字段（如 count(*)、sum(amount)）且条件固定 → 考虑覆盖索引，把 SELECT 字段也包含进去，避免回表
定期更新统计信息 & 避免隐式类型转换
优化器依赖统计信息决定是否走索引、选哪个连接顺序。归档表数据不常变，但统计信息可能长期未更新：
- MySQL：运行 ANALYZE TABLE archive_orders;
- PostgreSQL：运行 ANALYZE archive_orders;（注意不是 VACUUM ANALYZE，除非需清理死元组）
- 检查 WHERE 条件中是否存在隐式转换：比如 user_id = '123'（字段是 bigint），会导致索引失效；统一用数值类型或显式 CAST
不复杂但容易忽略。归档表不是“扔进去就不管”，而是要像维护一个独立轻量级数仓一样——分区清晰、索引务实、统计及时、SQL干净。
