# 分区表练好就够了，别动不动就上分库分表

分区表练好就够了，别动不动就上分库分表

我见过太多项目，数据量还没到千万级，就急着上ShardingSphere，搞得跨库JOIN写几十个单表查询，一个统计接口十几秒。也见过30亿数据一张表，只用了分区表，查询稳如老狗。

今天说清楚这件事。

一句话定位

分区表是"内功"，解决存储和IO效率；分库分表是"外家功夫"，解决算力和资源瓶颈。

绝大多数被吹上天的场景，练好内功就够了。

分区表——整理术

分区表是数据库内核层面的优化。对应用层来说，它还是一张表，SQL不用改，统计语句数据库自己会去各个分区跑完再汇总。但在物理磁盘上，它被切成了多个文件（如p2023.ibd, p2024.ibd）。

三个核心价值：

索引更小更快。查某个分区的数据，只需要扫描该分区的索引树，不用扫全表。分区裁剪（Partition Pruning）是数据库自动做的，你不需要改SQL。

运维神器。删除历史数据不是DELETE（会产生大量碎片和日志），而是直接DROP PARTITION（秒级删除物理文件）。日志归档、历史数据清理，这个特性简直是绝杀。

开发无感。SQL不用改，业务代码不用改，DBA配一下就行。

局限：所有分区在同一台服务器上。单机CPU、内存、磁盘IO打满了，分区表救不了你。

分库分表——扩张术

分库分表是架构层面的分布式方案。通过中间件或代码硬编码，把数据打散到不同的数据库实例甚至不同的物理机器上。

两个价值：

突破单机极限。一台扛不住1万QPS？加到10台，每台只扛1000。

分散存储压力。磁盘不够？加机器，理论容量无限扩展。

代价极高：分布式事务、跨库JOIN、全局唯一ID、复杂的运维监控——每一项都是坑。

适用边界的真相

很多大厂文章把分库分表写得像标配，好像不分就是原罪。实际上这两者的适用场景天差地别。

为什么分区表被低估了

我经历过的真实案例：30亿数据一张表，只要查询条件带上时间或主键，性能依然稳。但前提是查询范围不能太大——跨年份的大范围统计查询照样会慢，这时候需要把统计口径收窄，或者把聚合结果预计算好存下来。分区表不是万能药，它解决的是"精准查询快"的问题，不是"全表扫描快"的问题。全表扫描30亿行，分区表也救不了你。

原因有两点：

硬件进步掩盖了软件缺陷。现在NVMe SSD读写极快，内存越来越大。以前1000万行MySQL就卡了，现在几亿行只要索引命中，毫秒级响应。很多"需要分库分表"的判断，其实是基于五年前的硬件水平做的。

冷热分离是王道。大部分业务，尤其是政务，90%的访问集中在最近3个月的数据。利用分区表，热数据留高性能盘，冷数据归档到廉价盘，既省钱又快。何必搞分布式？

我接盘过一个系统，基础信息约1000万条，核心业务事件表每天新增几百条，一年也就十几万。项目组上了分库分表框架。结果呢？统计报表需要关联多张表做多维度聚合——跨库JOIN直接报错。为了在框架限制下跑出结果，把一个统计接口拆成了几十个单表单指标查询，Java层拼接计算。一个看板页面加载十几秒。

而事实是：事件表一天几百条，一年十几万，这个量级单表单库完全扛得住。上分库分表是用战术上的勤奋（堆机器、写复杂代码）来掩盖战略上的懒惰（没想清楚数据模型和业务边界）。最后绕开框架直接JDBC连物理库，一条SQL搞定，毫秒级返回。

我的选型原则

第一，首选分区表 + 读写分离。只要单机能装下数据、扛住并发，绝对不上分库分表。这是性价比最高的方案。

第二，垂直拆分优先。如果一个库太乱，先把不同业务的表拆到不同的库里（用户库、订单库、日志库），比水平分表简单得多，也能解决大部分耦合问题。

第三，最后才考虑水平分库分表。只有单机磁盘真的存不下了（超过4-8TB），或者单机写入真的达到瓶颈（每秒几万写），再走这一步。

结论

分库分表不是架构能力的体现。能把分区表和索引优化用到极致，才是真正懂数据库的表现。

能用一张表解决的问题，不要拆成十张表。能用一台机器扛住的系统，不要搞成十台机器。简单性本身就是一种架构能力。