SQL分区表需匹配业务访问模式以提升查询性能、高效清理旧数据及支撑生命周期管理；选时间类字段为分区键，用RANGE策略并配套自动滚动维护与分区验证。
SQL分区表不是简单加个PARTITION BY就完事，核心是让数据分布匹配业务访问模式——查得快、删得稳、扩得顺。设计不对，反而拖慢查询、增加维护成本。
明确分区目标：先想清楚“为什么分”
常见目标有三类，选错方向后续全白搭：
- 提升查询性能：比如订单表按月分区，90%的报表只查最近3个月，就能跳过历史分区
-
高效清理旧数据：日志表按天分区，删7天前数据只需
DROP PARTITION，秒级完成，不用走DELETE逐行扫描 - 支撑数据生命周期管理：冷热分离，把1年前分区迁到归档库或压缩存储，主库只留热数据
选对分区键：业务字段 + 高基数 + 稳定性
分区键不是主键，也不是随便挑个时间字段。关键看三点：
-
必须出现在WHERE条件中：比如按
create_time分区，但查询总用user_id过滤，分区就失效了 -
值分布均匀：避免“某一天订单暴增10倍”，导致一个分区巨大，其他空转；用
EXPLAIN PARTITIONS验证实际命中分区数 -
长期稳定不可变：别用
status或updated_at——状态会改，更新时间会变，分区键一旦写入就不能改，否则要重建
推荐优先级：时间类字段（event_date、log_day）＞ 业务ID哈希（MOD(user_id, 32)）＞ 枚举+时间组合（如(region, log_day)）
定好分区策略：RANGE最常用，LIST和HASH有边界
MySQL/PostgreSQL主流支持三种，别硬套：
- RANGE分区：适合时间、序号等连续值。建表时预定义范围，比如每月一个分区，注意提前建好未来2–3个月分区，避免运行时自动分裂卡顿
-
LIST分区：适合固定分类，如
region IN (1,2,3)、app_type IN ('ios','android','web')。新增类型需手动ALTER TABLE ... ADD PARTITION -
HASH分区：适合均匀打散，比如
user_id % 16。但无法做范围查询（如查user_id BETWEEN 1000 AND 2000会扫多个分区），慎用于主查询字段
落地关键动作：建表 + 维护 + 验证闭环
不只写DDL，还要配套运维习惯：
-
建表一步到位：用
CREATE TABLE ... PARTITION BY RANGE (TO_DAYS(create_time))，别等表大了再转分区（MySQL不支持在线转，需重建） -
自动滚动分区：写定时任务（如每天凌晨），
DROP PARTITION p_20240101删过期分区，ADD PARTITION加新分区，用SHOW CREATE TABLE确认结构 -
强制走分区验证：加
SELECT ... FROM tbl PARTITION(p_202405)查单个分区，或用EXPLAIN PARTITIONS看是否只访问目标分区，避免隐式全扫 -
索引要配合分区键：本地索引（
LOCAL）每个分区独立建索引，速度更快；全局索引（GLOBAL）跨分区维护成本高，多数场景不用
基本上就这些。分区不是银弹，小表（＜500万行）加了可能更慢；真正起效的前提是——查询条件能精准落到1～2个分区里。设计前先跑一周慢查日志，找出高频过滤字段和时间范围，再动手。
