sql分区表需按规则物理分布数据以提升查询性能和维护效率，核心是选好分区键（高频过滤、分布均匀）、匹配分区类型（RANGE/LIST/HASH 等）、控制分区数量（几十个为宜），并配套本地索引、统计更新与生命周期管理。
SQL 分区表不是简单把大表拆开，而是按规则把数据物理分布到不同存储单元，让查询只扫相关分区、提升性能，同时便于归档和维护。设计合理才能真正见效，否则反而增加复杂度。
分区键选什么？核心是“查询常用 + 数据分布均匀”
分区键决定数据怎么切，也直接影响查询是否能走分区裁剪（Partition Pruning）。选错了，查询仍要扫全表。
- 优先选高频过滤字段：比如订单表常按
order_date查询最近 30 天，就用它做范围分区；日志表常按region_code或app_id分析，可考虑列表或哈希分区。 - 避开低基数或易倾斜字段 ：如
is_deleted（只有 0 /1）会导致两个分区严重不均；用户性别、 状态码 等同理，容易造成“热点 分区”。 - 尽量不选更新频繁的列 ：分区键值变更可能触发跨分区数据迁移，代价高，多数 数据库（如mysql 8.0+、postgresql）不支持自动重分区，需手动处理。
用哪种分区类型？看数据特征和查询模式
常见类型不是凭感觉选，而是匹配业务场景：
- RANGE 分区：适合时间序列、ID 递增类字段（如
create_time、id）。支持按月 / 年自动管理，方便冷热分离。注意边界定义清晰，避免空隙或重叠（如VALUES less THAN (202404)要和下一分区衔接好）。 - LIST 分区：适用于明确有限取值且查询常固定枚举（如
province、device_type）。必须覆盖所有可能值，否则插入会报错；新增类别需手动添加分区。 - HASH 分区：适合均衡分布、但无明显范围或枚举特征的字段（如
user_id）。自动散列，写入负载较平均，但不支持非等值查询裁剪（比如WHERE user_id > 1000仍可能扫多个分区）。 - column 分区（MySQL 5.5+）或表达式分区（PostgreSQL）：允许直接对日期函数分区，例如
PARTITION BY RANGE (YEAR(create_time))，比存冗余年份字段更干净。
分区数量多少合适？别贪多，也别太少
分区数影响元数据开销、管理粒度和 并发 效率：
- 单分区不宜过小：每个分区至少几百 MB～几 GB 才体现 I / O 优势；太小（如每天一个分区但日数据仅 10MB）会让分区数爆炸，拖慢 DDL、备份和优化器决策。
- 总分区数建议控制在几十个量级：MySQL 官方建议不超过 8192（实际生产中 200 以内更稳妥）；PostgreSQL 对分区数容忍更高，但超千个后查询计划生成变慢。
- 预留扩展空间：比如按月分区，提前建好未来 6 个月空分区；避免高峰期实时加分区锁表或阻塞写入。
别忘了配套动作：索引、统计、维护策略
分区表不是设完就一劳永逸：
- 本地索引优于全局索引：每个分区独立建索引（LOCAL），查询落在单一分区时效率最高；全局索引（GLOBAL）跨分区维护成本高，仅在极少数跨分区排序 / 聚合场景才考虑。
- 定期更新统计信息：尤其做了分区裁剪后，优化器依赖准确的分区行数估算。MySQL 用
ANALYZE table，PostgreSQL 用VACUUM ANALYZE，建议纳入运维脚本。 - 设计自动生命周期管理：比如每月初删除 3 年前的分区（
ALTER TABLE …… DROP PARTITION），比DELETE FROM快几个数量级，且不锁全表。
基本上就这些。分区表本质是“用结构换性能”，关键在贴合真实查询路径，而不是追求技术炫酷。动手前先问自己：我最常查什么条件？数据增长有多快？冷数据怎么扔？想清楚这三点，设计就不容易跑偏。
