MySQL的表分区是在物理存储层面把一张大表拆分成多个独立分区，但对上层SQL仍然表现为同一张表。当单表数据量突破千万甚至亿级后，即使建立了合适的索引，某些范围查询、归档操作和维护任务仍然会消耗大量资源。分区可以让数据库根据规则自动把数据落到不同存储单元中，查询时通过分区裁剪只访问必要的分区，从而减少扫描量。需要明确的是，分区并不是索引的替代品，它解决的是数据物理分布和扫描范围问题，而索引解决的是单分区内部快速定位问题。
一、表分区解决了什么问题以及它的限制
未分区的表在InnoDB存储引擎中通常对应一个或几个表空间文件，数据量增大后，B+树索引的深度会增加，范围扫描可能涉及大量连续数据页。分区表则将数据按照某种规则划分到不同的分区中，每个分区拥有独立的数据文件，但逻辑上仍然是一张表。MySQL在查询时会根据分区定义先判断需要访问哪些分区，这个过程称为分区裁剪。比如按年份分区的订单表，查询某一年的数据时，优化器只会访问对应年份的分区，而不是整张表。
不过分区并不是万能的。它要求分区键必须是主键或唯一索引的一部分，否则创建分区表时会报错。原因是MySQL需要保证唯一性在全局范围内成立，如果唯一键不包含分区键，数据库很难在多个分区之间高效地检查重复值。此外，分区表达式必须返回整数或NULL，RANGE和LIST分区需要显式列出分区，而HASH和KEY分区可以自动生成。单表最多支持8192个分区，但这个上限并不意味着分区越多越好，过多的分区会让数据字典和DDL操作变得非常缓慢。
分区表也不支持外键约束，这是很多业务系统无法直接使用分区的一个重要原因。设计时需要提前确认这些限制是否会与现有表结构冲突。如果一张表的主键是业务单号，而又想按时间分区，就必须把时间列也加入主键，这会改变主键的含义，需要在业务层评估影响。
二、四种分区类型与建表语法
MySQL提供了RANGE、LIST、HASH和KEY四种基本分区类型。RANGE分区最常用于时间序列数据或连续数值范围，每个分区定义一个取值上限。下面是一个按订单年份进行RANGE分区的示例，注意主键中包含了分区列order_date，否则创建会失败。
CREATE TABLE orders ( id INT NOT NULL, order_date DATE NOT NULL, amount DECIMAL(10,2), PRIMARY KEY (id, order_date) ) PARTITION BY RANGE (YEAR(order_date)) ( PARTITION p2022 VALUES LESS THAN (2023), PARTITION p2023 VALUES LESS THAN (2024), PARTITION p2024 VALUES LESS THAN (2025), PARTITION pmax VALUES LESS THAN MAXVALUE );
RANGE分区的优势在于可以很方便地按时间滚动维护数据。比如新一年到来时增加一个分区，历史数据过期时直接删除整个分区，删除分区的代价远小于逐行删除数据。但RANGE分区要求分区边界必须从小到大排列，并且最后一个分区通常使用MAXVALUE来兜底，否则插入超出范围的数据会报错。
LIST分区适合离散枚举值，比如按地区、状态或业务类型分区。每个分区显式列出允许的取值列表。
CREATE TABLE customer_orders ( order_id INT NOT NULL, region_id INT NOT NULL, customer_name VARCHAR(100), PRIMARY KEY (order_id, region_id) ) PARTITION BY LIST (region_id) ( PARTITION p_north VALUES IN (1,2,3), PARTITION p_south VALUES IN (4,5,6), PARTITION p_west VALUES IN (7,8,9), PARTITION p_east VALUES IN (10,11,12) );
LIST分区只支持整数类型，如果业务字段是字符串，需要先转换为整数，但这可能导致分区裁剪失效。因此使用LIST分区时，枚举值最好直接采用整数代码。HASH分区用来将数据尽量均匀地分散到多个分区中，适合没有明显范围或枚举特征的数据。HASH分区只需要指定分区键和分区数量，MySQL会根据哈希函数自动决定每行数据进入哪个分区。
CREATE TABLE users ( id INT NOT NULL, username VARCHAR(50), created_at DATE, PRIMARY KEY (id) ) PARTITION BY HASH(id) PARTITIONS 4;
KEY分区与HASH分区类似，但哈希函数由MySQL内部提供，可以作用于整数、字符串等非整数字段。KEY分区要求分区键必须包含主键或唯一键，这与分区表的总要求一致。HASH和KEY分区通常只能对等值查询产生明显裁剪效果，因为范围查询无法确定具体落在哪一个哈希分区。
CREATE TABLE logs ( log_id BIGINT NOT NULL, content TEXT, PRIMARY KEY (log_id) ) PARTITION BY KEY(log_id) PARTITIONS 6;
三、分区裁剪与查询优化
分区裁剪是分区表获得性能提升的核心机制。当SQL的WHERE条件中直接包含分区键时，优化器会先解析分区定义，计算出哪些分区与条件相关，然后只扫描这些分区。通过EXPLAIN命令可以查看一条查询实际访问了哪些分区，输出中的partitions列会显示分区名称。如果没有发生裁剪，该列会显示全部的分区名或NULL。
EXPLAIN SELECT * FROM orders WHERE order_date BETWEEN '2023-01-01' AND '2023-12-31';
上面的查询中，如果分区表达式是YEAR(order_date)，而WHERE条件使用了日期范围，MySQL不一定能自动推导出年份范围。为了确保分区裁剪生效，最好让WHERE条件直接对应分区表达式的形式。例如使用YEAR(order_date) = 2023，或者将分区键设计成可以直接比较的日期列并用RANGE COLUMNS分区。否则优化器可能扫描多个分区甚至全部分区。
分区裁剪的效果与分区类型密切相关。RANGE和LIST分区在范围查询和枚举查询中裁剪效果最好，HASH和KEY分区只有在等值条件下才能定位到单个分区。即使分区裁剪成功，分区内部仍然需要索引来快速定位行，否则扫描整个分区的代价仍然很高。最佳实践是在分区键上同时建立索引，但需要注意，MySQL的分区键本身并不自动成为索引，只是用于确定数据位于哪个分区。
四、分区维护操作与常见误区
分区表的一个显著优势是维护操作可以针对单个分区执行，而不用操作整张表。例如按年份RANGE分区后，可以快速清理历史数据。新增一个分区使用ADD PARTITION，删除历史分区使用DROP PARTITION，删除分区会同时删除该分区内的所有数据，因此执行前需要确认数据是否还需要保留。
ALTER TABLE orders ADD PARTITION (PARTITION p2025 VALUES LESS THAN (2026)); ALTER TABLE orders DROP PARTITION p2022; ALTER TABLE orders TRUNCATE PARTITION p2023;
REORGANIZE PARTITION可以用来拆分或合并已有分区，适合在分区设计需要调整时使用。例如把pmax拆分成具体年份并保留兜底分区。
ALTER TABLE orders REORGANIZE PARTITION pmax INTO ( PARTITION p2025 VALUES LESS THAN (2026), PARTITION pmax VALUES LESS THAN MAXVALUE );
分区维护虽然语法简单，但存在几个常见误区。第一，分区数量不是越多越好，每个分区都会增加元数据开销，数百个分区后DDL操作会明显变慢。第二，分区裁剪不是只要建了分区就自动发生，如果查询条件对分区键使用了函数或隐式类型转换，裁剪可能失效。第三，删除分区虽然很快，但它会直接移除数据，不是常规的数据清理手段，生产环境必须与归档流程配合。第四，分区不能替代索引，即使只扫描一个分区，该分区内的数据量仍然可能很大，依然需要索引来提升查询速度。
还有一点容易忽略：分区表的查询性能并不总是优于未分区表。如果查询条件无法触发分区裁剪，MySQL需要扫描所有分区，相比未分区表反而增加了分区间的调度开销。因此是否使用分区，需要根据业务查询模式来决定。如果大多数查询都带有明确的分区键条件，并且数据量确实到达单表瓶颈，那么分区是有效的优化手段。否则盲目上分区只会增加复杂性。