17370845950

SQL分区表是逻辑上一张表、物理上按规则分散存储，适合数据有明显时间或范围特征且查询常带条件过滤的场景：日志订单监控按时间、用户按地区或租户、历史数据需快速归档、单表超千万行IO压力大。

SQL分区表不是把数据“拆成多张表”，而是让一张逻辑表在底层按规则分散存储，查询时数据库能自动跳过无关分区，大幅提升性能。

分区表适合什么场景

核心是“数据有明显时间或范围特征，且查询常带条件过滤”：

• 日志、订单、监控等按天/月生成的数据，90%查询只查最近30天
• 用户表按地区ID或租户ID划分，不同业务线查自己分区，避免全表扫描
• 历史数据归档频繁，需要快速删除旧分区（DROP PARTITION比DELETE快得多）
• 单表超千万行、IO压力大、维护耗时长（如统计分析卡顿、备份慢）

常见分区类型与写法（以MySQL 8.0+和PostgreSQL为例）

注意：语法细节因数据库而异，以下为通用逻辑示意

• RANGE分区：按连续范围切分，最常用。例如按日期字段：
  

  PARTITION BY RANGE (YEAR(create_time)) (
    PARTITION p_2025 VALUES LESS THAN (2025),
    PARTITION p_2025 VALUES LESS THAN (2025),
    PARTITION p_2025 VALUES LESS THAN (2025)
  )

• LIST分区：按离散值匹配，适合枚举类字段。如按省份编码：
  

  PARTITION BY LIST (province_code) (
    PARTITION p_beijing VALUES IN (110000),
    PARTITION p_shanghai VALUES IN (310000),
    PARTITION p_guangdong VALUES IN (440000, 440100, 440300)
  )

• HASH分区：按表达式取模均匀分布，适合无明显范围但需负载均衡的场景（如用户ID）：
  PARTITION BY HASH (user_id) PARTITIONS 8
• KEY分区：类似HASH，但由数据库自动处理NULL和字符串哈希，更稳定，推荐替代HASH

建表与维护关键操作

分区不是一劳永逸，得配合日常管理：

• 建表时必须指定PARTITION BY子句，且分区字段必须是主键/唯一索引的一部分（MySQL要求）
• 新增分区用ALTER TABLE ... ADD PARTITION，不能跨版本自动扩展（需手动加）
• 清理旧数据优先用ALTER TABLE ... DROP PARTITION p_2025，秒级完成，不走事务日志
• 查某条记录落在哪个分区？可用EXPLAIN PARTITIONS SELECT ...看执行计划中的partitions列
• 定期检查分区数量是否合理——太少起不到效果，太多增加元数据开销（一般建议单表20~200个分区）

容易踩的坑

分区表用不好反而拖慢系统：

• 查询没带分区字段条件（如WHERE里没写create_time或province_code），会扫所有分区，比普通表还慢
• 分区字段选错：用UUID或随机字符串做HASH分区，会导致热点和倾斜
• 误以为分区=分库分表：分区仍在单实例内，无法解决连接数、CPU或磁盘瓶颈
• MyISAM引擎不支持分区；MySQL 5.7以前对NULL处理有缺陷；PG需启用partitioning扩展

基本上就这些。分区是优化手段，不是银弹。先确认瓶颈真在IO或扫描范围，再选对字段、定好策略、配上运维动作，才能真正见效。