SQL报表日期范围查询变慢，大概率是没用上时间分区，或者分区设计不合理。核心思路是让数据库只扫描目标日期范围内的分区，而不是全表扫描。
确认是否已启用时间分区
先查表的分区信息，避免“以为分了，其实没分”：
- MySQL（8.0+）：执行 SHOW CREATE TABLE 表名，看是否有 PARTITION BY RANGE (TO_DAYS(时间字段)) 或 PARTITION BY RANGE COLUMNS(时间字段)
- PostgreSQL：查 pg_partitions 视图或使用 \d+ 表名，确认是否为 Range 分区且按日期字段分区
- ClickHouse：执行 SELECT * FROM system.parts WHERE table = '表名' AND active，观察 partition 字段是否按天/月规律分布
分区粒度要匹配查询习惯
分区不是越细越好，关键要和常用查询范围对齐：
- 日报类查询多 → 按天分区（如 PARTITION p20240401 VALUES LESS THAN ('2024-04-02')）
- 查近3个月数据为主 → 按月分区更省元数据开销，但需确保 WHERE 条件能精确命中分区（例如 WHERE dt >= '2024-02-01' AND dt ）
- 避免用函数破坏分区裁剪：写成 WHERE DATE(create_time) = '2024-04-01' 会失效；应改写为 WHERE create_time >= '2024-04-01' AND create_time
索引与分区字段必须协同
光有分区不够，时间字段上还得有有效索引：
- 复合查询（如查某日期内某用户订单）：把时间字段放在联合索引最左位，例如 INDEX idx_dt_uid (dt, user_id)
- 避免在分区键上建单独冗余索引——分区本身已提供一级过滤，额外索引反而拖慢写入
- 定期检查执行计划：EXPLAIN SELECT ... 看 partitions 列是否只显示几个分区，type 是否为 range/ref，而非 ALL
冷热数据自动归档与分区清理
长期运行后，历史分区过多会影响元数据操作性能：
- 每月自动 DROP PARTITION 或 TRUNCATE PARTITION 超过保留期的数据（如只留2年）
- 用 REORGANIZE PARTITION 合并小分区（适用于误设过细的场景）
- ClickHouse 可配置 TTL dt + INTERVAL 2 YEAR 自动删除，无需手动干预
时间分区不是银弹，但只要分区键、查询条件、索引三者对齐，日期范围查询速度通常能从分钟级降到秒级甚至毫秒级。
