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

分区表练好就够了别动不动就上分库分表我见过太多项目数据量还没到千万级就急着上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、复杂的运维监控——每一项都是坑。适用边界的真相维度分区表分库分表数据量级千万~几十亿单机硬件百亿~无限集群规模并发压力单机扛得住的QPS单机扛不住必须水平扩展典型场景政务系统、日志、历史档案、ERP电商秒杀、社交Feed、金融高频统计能力强数据库自动聚合弱跨库统计极痛苦复杂度低DBA配置即可高需要中间件团队很多大厂文章把分库分表写得像标配好像不分就是原罪。实际上这两者的适用场景天差地别。为什么分区表被低估了我经历过的真实案例30亿数据一张表只要查询条件带上时间或主键性能依然稳。但前提是查询范围不能太大——跨年份的大范围统计查询照样会慢这时候需要把统计口径收窄或者把聚合结果预计算好存下来。分区表不是万能药它解决的是精准查询快的问题不是全表扫描快的问题。全表扫描30亿行分区表也救不了你。原因有两点硬件进步掩盖了软件缺陷。现在NVMe SSD读写极快内存越来越大。以前1000万行MySQL就卡了现在几亿行只要索引命中毫秒级响应。很多需要分库分表的判断其实是基于五年前的硬件水平做的。冷热分离是王道。大部分业务尤其是政务90%的访问集中在最近3个月的数据。利用分区表热数据留高性能盘冷数据归档到廉价盘既省钱又快。何必搞分布式我接盘过一个系统基础信息约1000万条核心业务事件表每天新增几百条一年也就十几万。项目组上了分库分表框架。结果呢统计报表需要关联多张表做多维度聚合——跨库JOIN直接报错。为了在框架限制下跑出结果把一个统计接口拆成了几十个单表单指标查询Java层拼接计算。一个看板页面加载十几秒。而事实是事件表一天几百条一年十几万这个量级单表单库完全扛得住。上分库分表是用战术上的勤奋堆机器、写复杂代码来掩盖战略上的懒惰没想清楚数据模型和业务边界。最后绕开框架直接JDBC连物理库一条SQL搞定毫秒级返回。我的选型原则第一首选分区表 读写分离。只要单机能装下数据、扛住并发绝对不上分库分表。这是性价比最高的方案。第二垂直拆分优先。如果一个库太乱先把不同业务的表拆到不同的库里用户库、订单库、日志库比水平分表简单得多也能解决大部分耦合问题。第三最后才考虑水平分库分表。只有单机磁盘真的存不下了超过4-8TB或者单机写入真的达到瓶颈每秒几万写再走这一步。结论分库分表不是架构能力的体现。能把分区表和索引优化用到极致才是真正懂数据库的表现。能用一张表解决的问题不要拆成十张表。能用一台机器扛住的系统不要搞成十台机器。简单性本身就是一种架构能力。