分区表需确保查询触发分区裁剪，关键选高频查询字段作分区键：时间字段用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需主键含分区键）
基本上就这些。分区是工具，不是银弹——设计前先看慢查日志里最卡的是哪类查询，再反推怎么切，比照着文档硬套容易白忙活。
