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_20250101删过期分区，ADD PARTITION加新分区，用SHOW CREATE TABLE确认结构
• 强制走分区验证：加SELECT ... FROM tbl PARTITION(p_202505)查单个分区，或用EXPLAIN PARTITIONS看是否只访问目标分区，避免隐式全扫
• 索引要配合分区键：本地索引（LOCAL）每个分区独立建索引，速度更快；全局索引（GLOBAL）跨分区维护成本高，多数场景不用

基本上就这些。分区不是银弹，小表（＜500万行）加了可能更慢；真正起效的前提是——查询条件能精准落到1～2个分区里。设计前先跑一周慢查日志，找出高频过滤字段和时间范围，再动手。