数据库分区与分片：从表分区设计到性能优化实战

看到“Partition”这个词，不同背景的人脑子里浮现的东西完全不一样：做运维的想起磁盘分区，做数据库的想起分区表，做分布式的想起分片，做业务架构的想起限界上下文。但我在一线排查了太多性能问题之后，最大的感受是，它本质上只有一句话——把一个大东西拆成多个互不干扰的小块，让每一次操作只碰它该碰的那一小块。这次想把散落在这几个层面的经验串起来聊一聊，尤其是数据库分区这一块的选型、实操和踩坑，顺便把分布式分片和窗口函数里那个同名不同物的PARTITION BY也一起理清楚。

这篇文章适合谁？如果你的表数据量已经快到千万甚至亿级，查询越来越慢、归档越来越费劲、删数据锁表锁到业务投诉，那这篇文章能给出一套从分区设计到索引优化再到分片演进的完整思路。如果你是刚接触架构设计、看到“系统架构设计师”考试里一堆分布式架构和微服务概念有点懵，那这篇文章也能帮你在最底层的“分而治之”这个点上建立起直觉。

1. 分区是同一个思想，在不同尺度上的落地

1.1 从磁盘分区说起：分区的本质是限制故障半径

很多人一听到数据库分区，第一反应是“这不就是数据分块嘛”，但真让他说出分区到底解决了什么，往往只能回答“查询变快了”。实际上分区想解决的问题远不止性能。

先拿最古老的磁盘分区来说。给一块硬盘分C盘、D盘，不是因为分区能让硬盘变快，而是为了让操作系统崩溃时不至于整个盘的文件一起遭殃，重装系统不会把个人数据弄丢，文件系统的寻址和碎片整理也能控制在一个更小的范围内。换句话说，分区是给“灾难”和“低效”划定边界。

数据库分区表的动机一模一样：单表数据量涨到一定程度后，B+树的层数变高，索引和数据的缓存命中率下降，DELETE和归档操作锁定的行数越来越多，维护成本指数级上升。通过分区，逻辑上是一张表，物理上拆成多个独立的存储单元，每次查询、每次删除只影响特定分区，这就是“限制故障半径”和数据访问半径的直接体现。

1.2 三个尺度的partition：单机存储、单库数据、分布式节点

把“限制范围”这个思想放到不同尺度上，就是一套完整的架构演进路线：

• 单机存储尺度：磁盘分区、LVM逻辑卷、文件系统目录分层，解决的是“一盘崩全盘挂、文件散乱难维护”的问题。
• 单库数据尺度：数据库分区表，解决的是“一张表数据量过大，检索和维护成本失控”的问题。
• 分布式系统尺度：数据分片（Sharding）、一致性哈希、微服务拆分的限界上下文，解决的是“单机容量和吞吐到达瓶颈后，如何横向扩展”的问题。

理解了这三个尺度，你就明白为什么招聘市场上系统架构设计师的面试总爱问分区和分片——它表面是一个数据分布问题，内核却揉合了性能优化、可用性设计、组织协作边界等多个层面的权衡。下面我重点展开数据库分区表这个尺度，因为它是绝大多数团队最容易直接碰到的一环，也是后面理解分片的基础。

2. 分区类型怎么选：range、hash、list，别等建完表才后悔

2.1 Range分区：时间序列数据的默认答案

Range分区是按连续区间来划分数据，最典型的场景就是时间。订单表、日志表、流水表，几乎只要带个created_at，大家第一个想到的就是按月或者按年做Range分区。

它的核心优势在于查询模式和生命周期管理高度匹配。业务查数据天然喜欢带时间范围，“查最近三个月订单”“统计昨天的日志量”，这类SQL只要条件的边界落在分区范围里，优化器就能直接裁剪掉无关分区。归档也方便，删除某个历史时间段的数据，直接DROP PARTITION比DELETE快几个数量级，因为DROP PARTITION是元数据操作，而DELETE是一条条走事务的。

建表的时候有几个容易忽略的细节。第一个是边界值用RANGE COLUMNS而不是RANGE加函数。MySQL早期的写法是PARTITION BY RANGE (YEAR(created_at))，到了8.0更推荐PARTITION BY RANGE COLUMNS (created_at)，后者能直接用日期类型做边界比较，支持多列，裁剪粒度更精细，性能表现也更稳定。第二个是未来分区的问题，历史数据很重要，但系统总会跑到今天，所以建议留一个VALUES LESS THAN MAXVALUE的兜底分区，否则某天忘了提前加分区，插入新数据会直接报错，这种事故我见过不止一次。

2.2 Hash分区：没有自然边界时的均匀策略

Range分区最怕的是什么？热点。如果数据没有时间这种天然连续的维度，或者按某个字段分布极不均匀，比如用户表按地区Range分区，结果80%的用户都集中在某几个地区，个别分区膨胀到别的分区好几倍，查询和管理都会有压力。

这种情况下Hash分区更合适。Hash分区把分区键的值传给哈希函数，计算出一个相对均匀的分布，让数据尽可能平均地散落在各个分区里。它的核心决策点是分区数怎么定。

分区数不是拍脑袋定的，我的经验是两张表参考：一是预估这张表两年后的总数据量，除以一个单分区合理容量（MySQL场景下单个分区在2000万到5000万行之间比较舒服），得出初始分区数；二是选一个2的幂或者质数。取2的幂是为了让哈希取模运算在底层更高效，取质数则是为了避免某些规律性的键值（比如自增ID按固定步长分布）在取模时产生共振，导致数据分布不均。实际操作中，我习惯先用一个较小的分区数上线，预留后面扩容的方式。Hash分区扩容非常痛苦，因为分区数变了，所有数据几乎都要重新计算哈希位置，所以在不确定业务增长时，宁可一开始多分几个区。

2.3 List分区：枚举值场景的精确落位

List分区是按枚举值列表来划分，适合那种字段本身取值有限且相对固定的场景。比如订单状态（待支付、已支付、已发货、已取消）、用户地域（华东、华北、华南）、业务类型（App端、Web端、小程序端）。

List分区的优点是数据归属清晰，查询特定值时裁剪非常精准。比如“统计所有已取消订单”，如果status是List分区键，查询就只扫对应的分区。痛点在于它对业务变化的容忍度低——如果产品经理过两个月加了一个新状态“已退款”，你就要记得ALTER TABLE ADD PARTITION，忘了的话插入新状态的数据直接报错，这是和Range分区未来数据同一类问题的另一种表现形式。

2.4 避坑重点：MySQL要求分区键必须包含在所有唯一键里

这块是新手踩得最狠的坑，没有之一。在MySQL里，如果一张表有主键或者唯一索引，那么分区键必须是主键或唯一索引的组成部分。原因不复杂：InnoDB的二级索引会隐式包含主键列，如果分区键不在主键里，同一个主键值的数据可能被分到不同分区，唯一性判断和索引组织都会出问题。

举个例子，订单表主键是id，想按created_at分区，直接这么写会报错：

sql复制CREATE TABLE orders (
    id BIGINT NOT NULL AUTO_INCREMENT,
    order_no VARCHAR(32) NOT NULL,
    user_id BIGINT NOT NULL,
    created_at DATETIME NOT NULL,
    PRIMARY KEY (id)
) PARTITION BY RANGE COLUMNS (created_at) (
    PARTITION p2023 VALUES LESS THAN ('2024-01-01'),
    PARTITION p2024 VALUES LESS THAN ('2025-01-01')
);

MySQL会直接拒绝：A PRIMARY KEY must include all columns in the table's partitioning function。

解决办法是改主键为联合主键：

sql复制PRIMARY KEY (id, created_at)

但这又引出新的麻烦：原本靠id就能唯一确定一行，现在业务侧所有要按id查询的地方都要带上created_at。所以在设计分区表之前，优先想清楚分区键，让分区键和业务最核心的查询条件重合。如果做不到，就要考虑是否真的需要分区，或者试试换一种数据库架构方案。

关于分区类型的选择，我用一张表简单总结：

3. 分区裁剪与执行计划：为什么加了分区反而更慢

3.1 分区裁剪的原理与查看方法

分区裁剪（Partition Pruning）是分区表性能的核心机制。理论上，优化器在生成执行计划时，会根据查询条件里分区键的过滤值，找出需要扫描的分区集合，把其它分区直接排除掉。比如按created_at做的Range分区，你查2024年的数据，优化器只扫p2024这个分区。

但“理论上”这三个字后面往往跟着残酷的现实。分区裁剪生效与否，得看执行计划里实际扫描了哪些分区。MySQL里最直接的验证方法是EXPLAIN：

sql复制EXPLAIN SELECT * FROM orders 
WHERE created_at >= '2024-01-01' AND created_at < '2024-03-01';

在MySQL 8.0里，EXPLAIN输出会多一列partitions，列出实际扫描到的分区。如果这一列是NULL或者显示全表所有分区，那就说明裁剪没有生效，SQL做了全分区扫描。

想要更详细的信息，可以用：

sql复制EXPLAIN FORMAT=JSON SELECT * FROM orders 
WHERE created_at >= '2024-01-01' AND created_at < '2024-03-01';

在JSON输出里，重点看“partition_pruning”相关的信息，以及查询计划里读取的每个分区的详细成本。这个习惯要养成，不要靠猜，执行计划会告诉你一切。

3.2 裁剪失效的三大元凶

裁剪失效的原因，排第一的是对分区键做函数或表达式计算。比如：

sql复制SELECT * FROM orders WHERE DATE_FORMAT(created_at, '%Y-%m-%d') = '2024-06-01';

这种写法从业务逻辑上完全等价于created_at = '2024-06-01'，但优化器没法直接判断DATE_FORMAT之后的值落在哪个分区，只能退化为扫描所有分区。正确写法是直接对分区键列做范围比较：

sql复制SELECT * FROM orders 
WHERE created_at >= '2024-06-01' AND created_at < '2024-06-02';

第二个元凶是隐式类型转换。分区键列是字符串类型，查询条件却传了数字，或者反过来。MySQL会做隐式转换，但转换过程会让索引和分区裁剪同时失效。比如：

sql复制-- 假设 order_date 是 VARCHAR 类型存储日期，且作为分区键
SELECT * FROM orders WHERE order_date = 20240601;

这个等值比较在MySQL里可能触发对列的函数隐式转换，导致裁剪失效。排查方法很简单——写SQL的时候严格让列的类型和条件的类型保持一致，字符串就是字符串，日期就是日期，别图省事。

第三个元凶是OR条件。查询条件是created_at >= '2024-01-01' OR status = 3，这种情况MySQL即使能按created_at裁剪，因为or的另一边可能落在别的分区，优化器往往没办法只扫一个分区，只能扩大扫描范围。能用UNION拆开就拆开，或者重新设计查询逻辑。

3.3 一个让人意外的现象：加了分区，点查反而更慢

分区裁剪在范围查询场景下是利器，但在等值查询场景下可能会帮倒忙。

有个真实案例：一张日志表按天做了Range分区，业务方反馈“按日志ID精确查询一条记录，加了分区之后反而比以前全表慢”。排查后发现两个问题叠加：第一，查询条件只有日志ID，没有时间，导致分区裁剪无法生效，需要扫描所有分区；第二，索引是每个分区独立维护的局部索引，查询时相当于要在N个分区里各查一遍小索引，最后在内存里合并结果，开销比单个大索引还大。

这种场景怎么解决？最直接的办法是业务查询尽量带上分区键；如果做不到，就要评估这个表到底适不适合分区。分区不是免费的午餐，它是在特定访问模式下才划算的优化手段。数据量没到单表性能瓶颈，没必要凑热闹硬上分区。

4. 分区索引与数据维护：局部索引、全局唯一性、归档删除

4.1 MySQL只有局部索引，这决定了唯一约束的边界

Oracle支持全局索引和局部索引，但MySQL的分区表只支持局部索引——每个分区维护一棵独立的B+树，索引结构在分区内自洽。

这个机制带来的直接后果是，唯一索引的约束范围被限制在分区内部。也就是说，两个分区里可以同时存在相同值的唯一索引列，只要它们各在各的分区里。这就是为什么第2章强调分区键必须包含在所有唯一键里——只有把分区键纳入唯一索引，才能保证唯一性判断时会带上分区键一起比较，从而在全表层面维持唯一约束。

如果业务上需要跨分区保证唯一，而分区键又无法进入唯一索引列，就只能靠应用层加锁或者引入唯一键生成服务来做兜底。分布式场景下的全局唯一ID也是同一个思路，不能简单依赖数据库单节点约束。

4.2 二级索引跨分区的成本陷阱

局部索引对等值查询的影响已经在第3.3节说过一次，这里再深入讲一下它的本质：二级索引叶子节点里存的是主键值，在分区表中，主键值本身就包含分区键列。当查询条件没有分区键时，MySQL不知道这个主键值在哪个分区，必须挨个分区去搜索引。虽然每个分区的索引都很小，但假设有24个分区，就要并发查24棵小索引树再归并结果。

这种“单查变多查”的放大效应，在并发量高的时候尤其明显。所以我一直建议：分区表上的二级索引要克制，认真分析业务查询模式，只保留那些高频且查询条件包含分区键的索引。其它的，要么通过冗余字段让查询条件带上分区键，要么干脆用覆盖索引降低回表损耗。

4.3 归档删除的正确姿势：DROP PARTITION才是王道

没怎么用过DROP PARTITION之前，你可能觉得删除历史数据就是DELETE FROM orders WHERE created_at < '2023-01-01'。数据量小的时候确实无所谓，但到了千万级、亿级，一条DELETE会把大量行锁住，事务日志暴涨，主从延迟飙升，甚至直接拖垮业务。

分区表的正确姿势是按周期增加新分区，按生命周期直接DROP PARTITION。举个例子，按月分区的订单流水保留24个月，每个月月初跑一次定时任务，新建下个月的分区，同时删除25个月前那个月的分区：

sql复制ALTER TABLE orders ADD PARTITION (
    PARTITION p202506 VALUES LESS THAN ('2025-07-01')
);

ALTER TABLE orders DROP PARTITION p202307;

DROP PARTITION是元数据级别的操作，瞬间完成，对线上业务的影响几乎可以忽略。相比之下DELETE是一条一条走事务，还要考虑Binlog复制到从库的成本。我见过有团队因为没用分区表，每次删历史数据都要停服维护，后来改成按天分区，日常清理变成定时任务的自动操作，运维压力直接降了一个量级。

4.4 用分区实现冷热数据分离

分区还有一个容易被忽略的好处，是冷热数据物理上的分离。InnoDB表空间可以灵活配置，不同分区可以放在不同的磁盘目录或表空间里。热分区放SSD，冷分区放机械盘或者压缩率更高的归档存储，成本能省不少。

实现方式上，MySQL的每个分区可以独立指定表空间。比如按月分区，近半年的分区放fast_space（SSD表空间），更早的分区放archive_space（归档表空间）。查询时，热数据的缓存命中率更高，冷数据的读取即使慢一些，也不影响核心链路。这一招在数据量很大但访问集中在近期的系统里特别实用。

5. 从单库分区到分布式分片：Partition思想的延伸

5.1 分区和分片，解决的不是同一个问题

分区和分片经常被混着提，但两者的着力点完全不同。分区解决的是单库内“一张表过大”的问题，物理位置还是在一个实例里，CPU、内存、磁盘都是共享的。分片解决的是单实例“容量和吞吐到顶”的问题，把数据真正拆到多个数据库实例上，每个实例独立运行。

一句话总结：分区是把柜子里的衣服分类叠好，柜子还是那个柜子；分片是直接多买几个柜子，每个柜子只放一部分衣服。

选择分片前，可以先问自己三个问题。第一，单表数据量是否已经超过单实例的合理承载范围？第二，单实例的CPU、IO、连接数是不是长期处于高水位？第三，业务的读写请求是否天然可以按某个维度隔离？如果前两个答案是“是”，第三个也能给出明确的拆分维度，那分片才有意义。数据量还在千万以内，盲目上分片只会让架构复杂度爆炸，事务、Join、排序全部变难，纯属给自己挖坑。

5.2 分片键的选择：均匀与路由缺一不可

分片键是整个分片架构里最重要的决策，它的好坏直接决定了后续每一行SQL的命运。

一个合格的分片键需要满足两点：一是值的分布足够均匀，不能让某个分片变成热点；二是业务查询要尽量能带上它，这样才能直接路由到单个分片。

以订单系统为例，多数团队会选user_id作为分片键。理由很朴素：用户的订单查询是最高频的，按user_id分片后，同一个用户的所有订单都落在同一个分片，查“我的订单”只需要访问一个实例，不需要跨片聚合。以order_id作为分片键的也有，但更多是配合user_id做二级索引。两种方案都有代价，核心是看业务读多还是写多、查询入口是什么。

分片算法上，最经典的是取模：

sql复制-- 假设分16片
shard_id = user_id % 16

实现简单，路由快，但扩缩容的代价极高——从16片扩到32片，理论上所有数据都要重新分布。一致性哈希则通过哈希环减少扩缩容时迁移的数据量，但引入了虚拟节点的复杂度，路由也要多一次计算。我自己的经验是，早期业务和分片数都不大时，取模方案就够用；等真的需要频繁扩缩容了，一致性哈希才能体现出优势，但那时候一般也应该考虑引入分布式数据库中间件了。

5.3 分片之后，事务和Join怎么办

分片最麻烦的不是拆数据，而是拆完之后的“缝合”。

原本一个事务里可以同时更新订单表和账户表，分片之后如果这两个表的数据被分到了不同实例，就变成了分布式事务问题。主流方案无非几类：两阶段提交、本地消息表加最终一致性、事务消息。每种的取舍都很明确，追求强一致就要接受延迟和复杂度的代价，追求高可用和高吞吐就要接受最终一致性的窗口期。

Join也是同样的逻辑。理想的架构是让Join发生在同一个分片内，这就要求分片键设计时把关联紧密的数据放在一起。比如订单表和订单明细表，都用order_id或者user_id作为分片键，这样Join就不需要跨实例了，性能完全可控。如果做不到，就要把原本的Join拆成多次单表查询然后在应用层组装，这是微服务架构下的常态。

5.4 分片加分区：两级拆分的实践案例

分片和分区并不是互斥的，相反，它们在真实系统里经常叠加使用，称为两级拆分。

一个比较通用的设计是“先分片，后分区”。比如订单系统按user_id分到16个数据库实例，每个实例里的订单表再按created_at做月Range分区。分片解决了数据量的横向扩展，分区解决了单实例内部的时间维归档和裁剪。

这类架构下，批量报表统计是个挑战。分片前一条SQL能全表扫，分片后就得跑16个实例再汇总。如果只是离线统计，可以用定时任务逐片拉取数据合并；如果要实时统计，就需要引入OLAP引擎或者流式计算框架，把明细数据同步过去做分析。分片解决的是交易链路的性能问题，分析链路不要硬塞进同一个架构里，专业的事交给专业的组件做。

6. 同名不同物：PARTITION BY窗口函数与表分区别混为一谈

6.1 为什么这么多人被“PARTITION BY”迷惑

数据库里有个高频热搜词叫“rownumber over partition by”，它和上面讲的分区表完全是两回事，但是名字里都带着“Partition”，无数人在这上面栽过跟头。

表分区（Table Partitioning）是DDL层面的物理存储设计，把一张表的数据按照一定规则拆到不同物理存储单位里。窗口函数里的PARTITION BY是SQL查询层面的逻辑分组，它不会改变数据的存储结构，只是告诉数据库“计算窗口函数时，按哪些列分组”。

这样说还是抽象，看个具体的。假设有张订单表，要取每个用户最近一笔订单，SQL可以这么写：

sql复制SELECT user_id, order_no, amount, created_at
FROM (
    SELECT 
        user_id, order_no, amount, created_at,
        ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) AS rn
    FROM orders
) t
WHERE rn = 1;

这个PARTITION BY user_id的意思是，对每个用户单独编号，按created_at倒序排，最新一条的序号是1。整个扫描还是全表扫描，数据物理上没有做任何拆分，纯粹是计算过程中的分组逻辑。

6.2 PARTITION BY和GROUP BY的本质差异

很多刚接触窗口函数的人会问，为什么不直接用GROUP BY？这个问题问得好，因为它们的差异恰恰是窗口函数存在的价值。

GROUP BY会把同一个分组的多行折叠成一行，SELECT的列只能是分组键或聚合函数；PARTITION BY不会折叠行，每一行原样保留，同时还能在组内做排名、累计、前后行比较等操作。

还是用订单表的例子，按用户统计订单数和总金额，GROUP BY是这么写的：

sql复制SELECT user_id, COUNT(*), SUM(amount) 
FROM orders 
GROUP BY user_id;

结果里每个用户一行。如果想知道每笔订单占该用户总金额的比例，GROUP BY就不好办了，因为你要同时保留订单明细和用户聚合值。窗口函数可以这样写：

sql复制SELECT 
    user_id, order_no, amount,
    amount / SUM(amount) OVER (PARTITION BY user_id) AS amount_ratio
FROM orders;

每个用户的订单行都还保留着，同时每一行旁边多了一列“该用户全部订单总金额”。这就是窗口函数“既保留明细，又得到分组聚合”的独特能力。

6.3 窗口函数在大分区数下的性能坑

窗口函数写起来爽，但性能问题也要心里有数。PARTITION BY的字段如果过多，每个分组很小，排序和开窗计算的开销虽然分摊到很多小组，但总的分组数量巨大，会增加排序和内存管理的压力。更严重的是，窗口函数通常需要在内存或者临时表里维护整个分组的数据，如果单个分组的行数巨大，内存不够时会落盘，性能断崖式下跌。

典型场景是拿PARTITION BY对超大表做全局排名：

sql复制SELECT *, ROW_NUMBER() OVER (PARTITION BY category ORDER BY score DESC) rn
FROM scores;

如果这个scores表有几千万行，分组后单个分组几十万行，数据库需要为每一组维护排序状态，内存很容易被打爆。这时候要么给sort_buffer_size和tmp_table_size做针对性调优，要么拆小批次，要么把“每组前N名”的逻辑改成先粗筛再精算，尽量避免在一次窗口计算里处理过多的行。

6.4 怎么区分这两个东西，我自己的记忆方法

为了避免每次写SQL都在脑子里打架，我自己的记忆锚点很简单：表分区的关键动词是“存储”，窗口函数PARTITION BY的关键动词是“分组计算”。一个管数怎么放，一个管数怎么算，两个完全不同的层次。

面试和排查问题的时候，只要听到“分区裁剪”“局部索引”“DROP PARTITION”这些词，谈的是表分区；听到“ROW_NUMBER”“排名”“每组Top N”这些词，谈的是窗口函数。两者不在一个知识域，但都属于大家常说的“Partition架构”这个概念家族的成员。

数据量到了需要分区和分片的阶段，说明业务已经过了“能跑就行”的阶段。分区键怎么选、用Range还是Hash、分片要不要上，这些问题没有标准答案，但有一点是我的切身体会：方案越简单越难出错，能用分区解决就不要急着上分片，能用时间维度解决就不要硬造哈希规则。我每次设计新表之前，都会先花十分钟把业务查询模式写下来，哪些查询带时间范围、哪些是等值匹配、生命周期多久——这些东西确定了，分区方案基本就有结论了，后面那些坑也都能提前避开。