SQL分区表是逻辑上一张表、物理上按规则分散存储，适合数据有明显时间或范围特征且查询常带条件过滤的场景：日志订单监控按时间、用户按地区或租户、历史数据需快速归档、单表超千万行IO压力大。
SQL分区表不是把数据“拆成多张表”，而是让一张逻辑表在底层按规则分散存储，查询时数据库能自动跳过无关分区，大幅提升性能。
分区表适合什么场景
核心是“数据有明显时间或范围特征，且查询常带条件过滤”：
- 日志、订单、监控等按天/月生成的数据，90%查询只查最近30天
- 用户表按地区ID或租户ID划分，不同业务线查自己分区，避免全表扫描
- 历史数据归档频繁，需要快速删除旧分区（DROP PARTITION比DELETE快得多）
- 单表超千万行、IO压力大、维护耗时长（如统计分析卡顿、备份慢）
常见分区类型与写法（以MySQL 8.0+和PostgreSQL为例）
注意：语法细节因数据库而异，以下为通用逻辑示意
-
RANGE分区：按连续范围切分，最常用。例如按日期字段：
PARTITION BY RANGE (YEAR(create_time)) (
PARTITION p_2022 VALUES LESS THAN (2023),
PARTITION p_2023 VALUES LESS THAN (2024),
PARTITION p_2024 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_2022，秒级完成，不走事务日志 - 查某条记录落在哪个分区？可用
EXPLAIN PARTITIONS SELECT ...看执行计划中的partitions列 - 定期检查分区数量是否合理——太少起不到效果，太多增加元数据开销（一般建议单表20~200个分区）
容易踩的坑
分区表用不好反而拖慢系统：
- 查询没带分区字段条件（如WHERE里没写create_time或province_code），会扫所有分区，比普通表还慢
- 分区字段选错：用UUID或随机字符串做HASH分区，会导致热点和倾斜
- 误以为分区=分库分表：分区仍在单实例内，无法解决连接数、CPU或磁盘瓶颈
- MyISAM引擎不支持分区；MySQL 5.7以前对NULL处理有缺陷；PG需启用
partitioning扩展
基本上就这些。分区是优化手段，不是银弹。先确认瓶颈真在IO或扫描范围，再选对字段、定好策略、配上运维动作，才能真正见效。
