MySQL 分区表入门：按时间分区的利与弊

发布时间:2025-12-08 14:34

## 分与不分的对比 按时间给大表分区，收益集中在三处：旧数据整区删除变成一条删分区的元数据操作，瞬间完成且不产生碎片；查询带上分区键时只扫相关分区，范围查询的扫描量骤减；备份可以按区拆开做，粒度更灵活。代价同样明确：所有查询必须带分区键才能吃到裁剪红利，不带键的查询照样全表扫；唯一键必须包含分区键，部分唯一性约束做不了；分区数过多推高规划开销，反而拖累整体。 ## 各自的适用面 时间序列数据是分区的标准场景：操作日志、行为流水、监控采样，写入持续追加，查询按时间段，过期数据定期清理，三件事全踩在分区的优势上。反例是主业务表：订单表按用户查询居多，用户维度与时间维度不重合，按时间分区后多数查询吃不到裁剪，等于白付分区的管理成本。表体积没到千万行级别的，索引已经足够，先别急着分区。还有一类中间形态：表是日志性质，但查询习惯固定只看最近一周，把旧数据整区归档到另一张表，热表保持小巧，效果接近分区而约束更少。 ## 落地示例 ``` ALTER TABLE access_log PARTITION BY RANGE (TO_DAYS(dt)) ( PARTITION p202501 VALUES LESS THAN (TO_DAYS('2025-02-01')), PARTITION p202502 VALUES LESS THAN (TO_DAYS('2025-03-01')), PARTITION pmax VALUES LESS THAN MAXVALUE ); ``` RANGE 分区按日期边界切块，每月一区是常见粒度。过期清理用 DROP PARTITION，与新数据写入互不干扰。 ## 选择建议 判断顺序建议固定：先确认查询模式带不带时间条件，再估表的增长速度与清理需求，两问都是肯定答案才上分区。分区数控制在两位数内，按月滚动的表提前建好未来的区，别让数据落进兜底区再迁移。已有大表改造分区是一次重量级操作，锁表时间与磁盘空间都要预留，选业务低峰执行，先在测试环境演练一遍时间预算。顺云云服务器上的日志库按这套思路分区管理，清理旧数据从几小时的删除语句变成秒级动作，运维节奏明显轻松。