分区表需确保查询触发分区裁剪，关键选高频查询字段作分区键：时间字段用 RANGE，离散值用 LIST，高基数 ID 用 HASH；控制分区数（mysql≤1000，PG≤1 万），避免按小时 / 分钟分区；写入带分区键，查询 WHERE 须显式含分区键且不可函数包裹。
分区表不是加个 PARTITION BY 就完事，关键得让查询真正用上分区裁剪，否则和普通表没 区别。
按查询模式选分区键
分区键必须是高频查询条件里的字段，比如订单表常按时间查最近 7 天数据，那就用 order_time 做范围分区；用户行为日志按 user_id 聚合分析多，就用 user_id 做哈希或列表分区。别为了“看着整齐”而选一个从不进 WHERE 的字段。
- 时间类字段（create_time、event_date）适合 RANGE 分区，配合按月 / 按天归档
- 状态码 、地区 编码、业务线 ID 等离散值少的字段，适合 LIST 分区
- ID 类或用户标识类高基数字段，可用 HASH 分区均衡数据分布
控制分区数量别贪多
单表分区数不是越多越好。MySQL 建议控制在 1000 个以内，postgresql官方建议不超过 1 万，但实际要看硬件和维护成本。分区太多会导致元数据膨胀、DDL 变慢、执行计划生成耗时增加。
- 按月分区：2 年数据 =24 个分区，较稳妥
- 按天分区：只保留 90 天热数据 + 自动 DROP 旧分区，避免无限增长
- 避免按小时或分钟建分区，除非 QPS 极高且查询极聚焦
写入和查询都要适配分区逻辑
插入数据时尽量带分区键值（如 INSERT INTO t VALUES (…, ‘2024-06-15’, …)），确保落到目标分区；查询时 WHERE 条件必须显式包含分区键，才能触发分区裁剪。像select * FROM t WHERE DATE(create_time) = ‘2024-06-15’ 这种写法，函数包裹会让分区失效。
- 改写为 WHERE create_time >= ‘2024-06-15’ AND create_time
- 批量导入前先确认目标分区是否存在，缺失时自动添加（可脚本化）
- 定期 ANALYZE table，让优化器准确估算各分区行数
配合归档与清理机制
分区表真正的优势在于“删旧如飞”。比起delete WHERE time
- 设定固定窗口（如保留 12 个月），用 事件 或定时任务自动新建 + 删除分区
- 冷数据可先 EXCHANGE PARTITION 导出到归档表，再 DROP，便于备份回溯
- 注意外键、主键约束在分区表中的限制（MySQL 不支持全局外键，PG 需主键含分区键）
基本上就这些。分区是 工具，不是银弹——设计前先看慢查日志里最卡的是哪类查询，再反推怎么切，比照着文档硬套容易白忙活。
