LESSuseLESS1. 为什么需要MySQL分区表？
当单表数据量超过千万行时，普通表的查询性能会明显下降。我去年处理过一个电商平台的订单表，数据量达到3亿条后，即使有索引，按月统计报表的查询也要15秒以上。这时分区表就派上用场了——通过把大表物理拆分成多个小表，查询时MySQL可以只扫描相关分区。
分区表的核心价值在于：
- 提升大表查询效率（特别是范围查询）
- 简化历史数据归档（直接删除整个分区）
- 优化IO性能（热点数据集中在特定分区）
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. MySQL分区类型详解
2.1 RANGE分区（最常用）
按连续范围划分，适合日期、自增ID等场景。这是我们订单表的分区方案：
sql复制CREATE TABLE orders (
id INT AUTO_INCREMENT,
order_date DATETIME,
amount DECIMAL(10,2),
PRIMARY KEY (id, order_date)
) PARTITION BY RANGE (YEAR(order_date)) (
PARTITION p2019 VALUES LESS THAN (2020),
PARTITION p2020 VALUES LESS THAN (2021),
PARTITION p2021 VALUES LESS THAN (2022),
PARTITION pmax VALUES LESS THAN MAXVALUE
);
注意：分区字段必须包含在主键中，这是MySQL的硬性要求
2.2 LIST分区
离散值分区，适合地区、状态码等有限枚举值。比如按地区存储用户：
sql复制PARTITION BY LIST(region_code) (
PARTITION p_east VALUES IN (1,3,5),
PARTITION p_west VALUES IN (2,4,6),
PARTITION p_other VALUES IN (DEFAULT)
)
2.3 HASH分区
均匀分布数据，适合消除热点。但分区数量固定后不易修改：
sql复制PARTITION BY HASH(user_id)
PARTITIONS 4;
2.4 KEY分区
类似HASH但只接受MySQL内置哈希算法，兼容性更好：
sql复制PARTITION BY KEY()
PARTITIONS 10;
3. 分区表实战避坑指南
3.1 分区字段选择原则
我踩过的坑：曾经用非索引字段做分区，导致查询性能反而下降30%。正确做法：
- 优先选择WHERE条件中的字段
- 必须是表索引的一部分
- 避免使用频繁更新的字段
3.2 分区数量控制
建议单个分区数据量控制在100-1000万行。分区过多会导致：
- 内存消耗增大（每个分区需要维护元数据）
- 打开文件数暴增（每个分区对应独立的.ibd文件）
3.3 跨分区查询优化
当查询涉及多个分区时，EXPLAIN会显示"partition_union"。这时要注意：
- 避免全分区扫描（加具体分区条件）
- 对分区间排序使用
PARTITION (p1,p2) ORDER BY语法
4. 分区维护操作手册
4.1 动态管理分区
添加2022年分区（RANGE示例）：
sql复制ALTER TABLE orders REORGANIZE PARTITION pmax INTO (
PARTITION p2022 VALUES LESS THAN (2023),
PARTITION pmax VALUES LESS THAN MAXVALUE
);
删除旧数据最快的方式是直接DROP分区：
sql复制ALTER TABLE orders DROP PARTITION p2019;
4.2 分区监控SQL
查看分区分布：
sql复制SELECT partition_name, table_rows
FROM information_schema.PARTITIONS
WHERE table_name = 'orders';
检查分区裁剪是否生效：
sql复制EXPLAIN PARTITIONS
SELECT * FROM orders
WHERE order_date BETWEEN '2021-01-01' AND '2021-03-31';
5. 分区表性能对比测试
在我的测试服务器（16核32G，SSD）上对2亿条数据测试：
| 操作类型 | 普通表 | 分区表(按月) | 提升幅度 |
|---|---|---|---|
| 单条查询 | 12ms | 8ms | 33% |
| 月统计 | 1.8s | 0.3s | 83% |
| 全表扫描 | 42s | 45s | -7% |
关键发现：分区表在范围查询中优势明显，但全表扫描会有轻微性能损耗。建议配合WHERE条件使用。
6. 分区表限制与替代方案
6.1 使用限制
- 不支持外键约束
- 所有分区必须使用相同存储引擎
- 自增列会按分区单独计数
6.2 分库分表对比
当单机分区无法满足时，考虑：
- 水平分表（如按用户ID取模）
- 使用ShardingSphere等中间件
- 迁移到分布式数据库（如TiDB）
我在实际项目中总结的经验法则：单表1亿以下优先用分区，超过则考虑分片。