大家好，我是小耶，写功课只是为了我踩过的坑，你们别再踩了！
MySQL 5.1开始支持分区表，到现在快15年了。但2026年了，我依然在技术群里看到各种关于分区表的灵魂提问：
“按天做了RANGE分区，为什么查某一天的数据还是扫了所有分区？”
“分区表有8192个上限，我按天分，能撑22年对吧？”
“数据量大了就该用分区表吧？这不就是MySQL自带的分库分表吗？”
这三个问题的答案分别是：分区键用错了、别真分8192个、这俩完全不是一回事。
很多人把分区表当成“免费的分布式”——建表的时候加个PARTITION BY，就觉得万事大吉了。等查询慢下来、DDL卡住、统计信息对不上，才发现这玩意儿没那么简单。
分区表不是“建完就完事了”的功能，它有一套严格的使用约束。今天从头拆一遍，讲清楚分区表到底是什么、怎么用、以及那些你踩了才知道的坑。
一、分区表的本质：对DBA友好，对优化器不友好
很多人把分区表理解成“把一张大表拆成多张小表”。这个理解方向对了，但不够准确。
分区表的本质是：逻辑上是一张表，物理上分成多个存储片段。
对DBA来说，分区表很友好——可以按时间范围批量删除旧数据（DROP PARTITION比DELETE快几百倍），可以把不同分区放到不同物理磁盘上分散I/O，还可以对冷热分区采取不同的存储策略。
但对优化器来说，分区表意味着更多选择、更多计算。优化器需要判断：查询条件能不能裁剪掉大部分分区？如果能，性能起飞；如果不能，优化器要在几十上百个分区里选执行计划，开销比单表大得多。
分区表的核心收益来自“分区裁剪” ——优化器根据WHERE条件中的分区键，自动排除不包含目标数据的分区，只扫描必要的分区。分区裁剪生效时，查询只扫描一个分区；失效时，扫描所有分区——比不分区还慢。
所以，分区表的第一个铁律是：分区裁剪能命中，分区表才有意义；分区裁剪命不中，分区表就是灾难。
二、四种分区类型，选错了直接gg
MySQL支持四种主流分区方式：
1. RANGE分区——按范围
最常用，适合时间序列数据。
CREATE TABLE orders (
id INT,
create_time DATETIME,
amount DECIMAL(10,2)
) PARTITION BY RANGE (YEAR(create_time)) (
PARTITION p2024 VALUES LESS THAN (2025),
PARTITION p2025 VALUES LESS THAN (2026),
PARTITION p2026 VALUES LESS THAN (2027)
);
适合：日志表、订单表——按时间范围查询、按时间批量删旧数据。
坑：边界值要提前规划好。如果插入的数据超出最大分区范围，会直接报错。
2. LIST分区——按离散值
按枚举值列表分区，比如按省份、按状态。
CREATE TABLE user_events (
id INT,
province VARCHAR(20),
event_data JSON
) PARTITION BY LIST COLUMNS (province) (
PARTITION p_east VALUES IN ('上海','江苏','浙江'),
PARTITION p_south VALUES IN ('广东','福建','海南')
);
MySQL 8.0引入了LIST COLUMNS分区，支持非整数类型的列作为分区键。
适合：按地域、按类别分区的场景。
坑：新增枚举值需要手动加分区，否则插入报错。
3. HASH分区——均匀散列
按哈希函数将数据均匀分布到N个分区。
CREATE TABLE user_logs (
id INT,
user_id INT,
log_time DATETIME
) PARTITION BY HASH(user_id) PARTITIONS 16;
适合：没有明显时间或类别维度、但数据量巨大的表。
坑：LINEAR HASH可以加速分区增删改，但数据分布可能不如标准HASH均匀。分区数量一变，所有数据要重分布。
4. KEY分区——类似HASH但用MySQL内部哈希
与HASH类似，但使用MySQL服务器内部的哈希函数，支持非整数类型的列。适合字符串类型的分区键。
5. 二级分区（Subpartitioning）——组合分区
先按一个维度分区，再在每个分区内按另一个维度细分。
CREATE TABLE orders (
id INT,
create_time DATETIME,
region VARCHAR(20)
) PARTITION BY RANGE (YEAR(create_time))
SUBPARTITION BY HASH(region) (
PARTITION p2024 VALUES LESS THAN (2025) (
SUBPARTITION p2024_east,
SUBPARTITION p2024_west
),
PARTITION p2025 VALUES LESS THAN (2026) (
SUBPARTITION p2025_east,
SUBPARTITION p2025_west
)
);
MySQL 8.0引入了SUBPARTITION TEMPLATE语法，确保每个子分区定义一致。
适合：多维度查询场景（如“时间+地域”）。
坑：复杂度翻倍，分区数量 = 一级分区数 × 二级分区数，容易超限。
三、3个真实踩坑场景
坑1：分区键选错，分区裁剪失效
这是最常见的坑。分区键的选择是分区表设计的核心决策。
黄金法则：分区键必须是高频查询的WHERE条件列。
错误示范：
-- 分区键是create_time，但查询条件是user_id
SELECT * FROM orders WHERE user_id = 12345;
优化器不知道user_id在哪个分区，只能扫全部。正确的做法是：如果90%的查询都带user_id，分区键就应该是user_id。
如果查询条件同时包含时间和另一个维度，可以考虑复合分区——一级按时间RANGE分区，二级按另一个维度HASH或LIST分区。
坑2：对分区键用了函数
优化器在做分区裁剪时，需要根据原始列的值来判断该扫哪个分区。一旦对分区键用了函数，优化器就不知道你查的是哪个范围了。
常见错误：
-- ❌ 对分区键用了函数
SELECT * FROM orders WHERE DATE(create_time) = '2026-08-01';
SELECT * FROM orders WHERE YEAR(create_time) = 2026;
SELECT * FROM orders WHERE TO_DAYS(create_time) = 740000;
不光是DATE()，TO_DAYS()、YEAR()这些函数同样会导致分区裁剪失效。
正确做法：直接用列本身做范围比较。
-- ✅ 正确：用列本身做范围比较
SELECT * FROM orders
WHERE create_time >= '2026-08-01' AND create_time < '2026-08-02';
坑3：分区数量过多
有人觉得“分区越多越好”——按天分区，一天一个，一年365个。
但分区数量过多会带来一系列问题：
元数据膨胀：每个分区都有独立的元数据，几百个分区会让数据字典变得臃肿
优化器开销增大：每次查询优化器都要评估所有分区，即使最终只扫一个
DDL变慢：
ALTER TABLE操作需要遍历所有分区备份恢复复杂：每个分区都要单独处理
建议：MySQL单表最大支持8192个分区。按天分区的话，大约能撑22年——但实际生产中建议控制在1000个分区以内。如果数据量增长快，可以按月分区，或者定期合并历史分区。
四、分区表 vs 分库分表：不是替代关系
很多人把分区表和分库分表混为一谈，其实两者有本质区别：
| 对比维度 | 分区表 | 分库分表 |
|---|---|---|
| 实现层级 | 数据库内部 | 应用层或中间件 |
| 物理分布 | 同一数据库实例 | 跨数据库实例甚至跨服务器 |
| 对应用透明性 | 完全透明 | 需要感知分片键 |
| 解决的核心问题 | 大表管理、查询性能 | 单机容量上限、写入瓶颈 |
| 跨分区/跨分片查询 | 支持，但可能慢 | 复杂，需要中间件支持 |
| 水平扩展能力 | 有限（受限于单机） | 无限（加机器即可） |
分区表解决的是“单表太大”的问题——通过物理分片、逻辑统一的方式管理数据。
分库分表解决的是“单机装不下”的问题——把数据分散到多台机器上。
两者的关系不是“二选一”，而是不同层次解决不同问题。数据量在单机范围内 → 分区表就够了；单机扛不住了 → 考虑分库分表或分布式数据库。
五、分区表适用场景速判
✅ 适合用的场景：
时间序列数据：日志、监控指标、订单——按时间RANGE分区，查询带时间范围，历史数据可批量清理
数据有明显“冷热”之分：最近3个月的数据高频访问，更早的数据偶尔查询——冷分区可以用压缩或慢速存储
需要按某个维度批量删除数据：
DROP PARTITION比DELETE快几个数量级可以把不同分区放到不同物理磁盘：分散I/O，提升吞吐
❌ 不适合用的场景：
查询条件几乎不带分区键 → 分区裁剪永远失效，比不分区还慢
表数据量不大（<1000万行） → 分区的维护成本超过收益
频繁跨分区JOIN → 每个分区都要参与，性能灾难
分区键频繁更新 → 更新分区键意味着数据要在分区之间移动，代价极高
六、小结
分区表不是“免费的分布式”，也不是“分库分表的平替”。它本质上是MySQL内置的大表管理工具，和分库分表解决的是不同层面的问题。分区表的收益完全取决于分区裁剪能否命中，而分区裁剪的命中和否则完全取决于你的查询模式和分区键设计是否匹配。数据量在单机范围、查询模式清晰、分区数量可控——满足这三个条件，分区表是利器；反之，它可能比不分区更让人头疼。
小耶在手，SQL 不愁
还有什么想了解的，欢迎留言！小耶一定知无不言言无不尽……我们下次见~
