这是一个或许对你有用的社群 一对一交流/面试小册/简历优化/求职解惑欢迎加入「芋道快速开发平台」知识星球。下面是星球提供的部分资料《项目实战视频》从书中学往事上“练”《互联网高频面试题》面朝简历学习春暖花开《架构 x 系统设计》摧枯拉朽掌控面试高频场景题《精进 Java 学习指南》系统学习互联网主流技术栈《必读 Java 源码专栏》知其然知其所以然这是一个或许对你有用的开源项目国产Star破10w的开源项目前端包括管理后台、微信小程序后端支持单体、微服务架构RBAC权限、数据权限、SaaS多租户、商城、支付、工作流、大屏报表、ERP、CRM、AI大模型、IoT物联网等功能多模块https://gitee.com/zhijiantianya/ruoyi-vue-pro微服务https://gitee.com/zhijiantianya/yudao-cloud视频教程https://doc.iocoder.cn【国内首批】支持 JDK17/21SpringBoot3、JDK8/11Spring Boot2双版本凌晨 1 点 DBA 加索引业务抖到天亮倒回 2010 年那时候没有更好的选择5 个真坑 · 大坑 vs 小坑NewSQL 这十年悄悄起来了主流 3 个产品我自己用 / 朋友在用 / 候选还没死透3 类场景里它仍然合理数据量没到大盘先用「分区表」过渡分库分表里的复杂查询建议引入 ES决策矩阵你属于哪一象限我的判断凌晨 1 点 DBA 加索引业务抖到天亮凌晨 1 点DBA 在群里 我「order_status字段的索引现在加上来一下」。我们的订单库分了 16 个库 × 8 张表。理论上加索引就是ALTER TABLE按理几分钟就完。实际跑起来——128 张表挨个加每加一张锁几十秒到几分钟。第 17 张表碰到一行被业务事务长持的记录直接锁了 5 分钟。下游订单详情、退款查询、对账作业全跟着抖——告警群从凌晨 1 点响到天亮。我就是在那一夜重新意识到一件事我们花了大半年设计的这套分库分表方案给业务带来的不再是性能红利而是每次变更都要熬一个通宵的成本。这篇文章想聊聊分库分表为什么正在从「标配」变成「历史遗留」以及现在做技术选型该往哪走。基于 Spring Boot MyBatis Plus Vue Element 实现的后台管理系统 用户小程序支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能项目地址https://github.com/YunaiV/ruoyi-vue-pro视频教程https://doc.iocoder.cn/video/倒回 2010 年那时候没有更好的选择时间拉回到 2010 年前后。那时候 MySQL 是绝大多数互联网公司的标配单表数据扛过几千万行就开始抖。电商、社交、支付这些业务数据量涨得飞快服务器配置堆到头也扛不住。解法只有一个——拆。按某个维度把数据打散分到多张表 / 多个库里去。那时候还没有成熟的分布式数据库MySQL 分区表有局限、Oracle 太贵剩下能选的就是这一套。淘宝、美团、微博这些大厂都在用社区里整天讨论怎么选分片键、怎么做数据迁移热得很。它确实解决了问题至少当时解决了。单库扛不住的写入量拆成 16 库 16 表扛住了流量、留住了用户。这是它的历史功劳不能否认。基于 Spring Cloud Alibaba Gateway Nacos RocketMQ Vue Element 实现的后台管理系统 用户小程序支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能项目地址https://github.com/YunaiV/yudao-cloud视频教程https://doc.iocoder.cn/video/5 个真坑 · 大坑 vs 小坑凡是真正在项目里维护过分库分表的基本都经历过这几件事。按破坏力分大坑、小坑。 大坑 1分片键选错几乎不可逆最致命分片键是整个方案的基础。你用user_id分片查单个用户没问题。但业务一上来「按商家查所有订单」、「按手机号反查用户」的需求——中间件只能去所有库捞、合并结果慢得离谱。想换分片键需要停服、重新导数据、重新验证。亿级别的表光迁移就要 2-3 天——你赔不起这个时间窗。 大坑 2跨库 JOIN 几乎不能用高频踩到「用户 订单 商品」三张表正常一条 SQL 解决。分库分表后三张表可能在不同的库中间件不支持真正的跨库 JOIN——只能在应用层手拼。先查用户、再批量查订单、再批量查商品、最后在 Java 代码里组装。这类代码写起来繁琐、出错率高——一个简单的列表页可能要写 50 行胶水代码。 大坑 3分布式事务吃力不讨好破坏力大下单要同时写订单库和库存库两个写操作要么全成功要么全失败。但它们在不同 MySQL 实例上本地事务管不到——你只能引入 XA 或 Seata。XA性能损耗大并发一上来就明显抖Seata配置复杂、出问题难排查线上事故从找根因到能复现动辄几小时最终一致性 补偿很多团队最后选择放弃强一致性靠补偿逻辑兜底——但补偿逻辑本身又是新的复杂度来源。 小坑 1扩容不是弹性扩容业务数据涨了原来 8 库不够想扩到 16 库。理论可以实际操作要凌晨手动跑一晚上停写 → 重新哈希迁移 → 改分片配置 → 验证 → 恢复写入。整个过程要人盯着、要写脚本、要做演练、要预留回滚通道——「弹性」这两个字和分库分表基本不沾边。618 / 双十一这种突发流量场景几乎只能预先扩容、不能临时加机器。 小坑 2SQL 限制不少写代码时一直要绕聚合函数、ORDER BY、GROUP BY在分库分表环境下都有坑ORDER BY要在中间件层做二次排序数据量一大容易 OOMLIMIT 100000, 10这种深翻页——中间件要从每个库各取 100010 条再合并吃内存吃时间跨库聚合COUNT DISTINCT/ 多维GROUP BY几乎做不了——逼着你绕去 ES 或离线计算。这些限制不是中间件的问题是架构本身带来的——意味着写每条复杂 SQL 前都要先想这条会不会触发跨库扫描。NewSQL 这十年悄悄起来了就在大家还在纠结「分 8 库好还是分 16 库好」的时候一批新数据库悄悄冒出来了。2012 年 Google 发了一篇关于 Spanner 的论文讲了一套全球分布式关系型数据库的实现。这篇论文后来被业内奉为经典——核心思想是存储和计算分离数据自动分片事务保证全局一致性用户面对的还是标准 SQL。期间国内外涌现出一批 NewSQLTiDB、OceanBase、CockroachDB、YugabyteDB、PolarDB-X。这一类数据库结合了传统 RDBMS 的 SQL 能力和分布式系统的扩展能力。和分库分表相比NewSQL 一次性把三件事全做对了 对应用透明——用户不关心数据在哪个节点、不选分片键、不写跨库逻辑SQL 怎么写就怎么用♾️ 计算 存储双向无限扩容——计算节点TiDB Server / CN撑不住就加存储节点TiKV / DN撑不住也加两个维度独立伸缩、不互相绑死✨ 用起来简单——不再有「分片键怎么选」「16 库还是 32 库」「明年是不是要再扩一倍」这类预先决策——今天先用着业务起来再加节点。一句话分库分表是一次性预算 永久维护成本NewSQL 是按需付费 几乎零运维决策。NewSQL 与传统分库分表对比主流 3 个产品我自己用 / 朋友在用 / 候选按我自己和身边圈子的真实使用情况——不是广告只是讲讲谁用什么。TiDBPingCAP—— 我自己项目在用开源 兼容 MySQL 协议 HTAP事务和分析同一套系统。截至 2025 年初已超过 4000 家企业在用——越南支付平台 ZaloPay、杭州银行等金融场景都在用。维度评价适合数据量大、有实时分析需求、有自运维能力的团队致命短板资源消耗不小——最小生产集群要 3 个 TiKV 3 个 PD机器成本不低云托管TiDB Cloud / 国内 TiDB Serverless我自己业务库就在用 TiDB——HTAP 实时分析体验确实好跑日常 OLTP 的同时做几个核心报表的 OLAP 查询省了一套 ClickHouse 的部署。PolarDB-X阿里云—— 朋友团队在用阿里系。从早期 DRDS云上分库分表产品演进而来后来重构成真正的分布式数据库。双十一是它的压力测试——2025 年 2 月 TPC-C 跑出每分钟 20.55 亿笔刷新世界纪录。飞鹤集团用 PolarDB 分布式版替换了原有分库分表方案迁移后业务处理量提升 200%、慢 SQL 减少 90%、运营成本降低 40%。维度评价适合已在阿里云上的团队、希望有完整商业支持致命短板深度绑定阿里云私有化部署相对复杂我身边有朋友团队在用 PolarDB-X——他们已经全栈跑在阿里云上用 PolarDB-X 的弹性扩缩容体验比自建 TiDB 省心618 临时加节点就是控制台一点。OceanBase蚂蚁—— 也有朋友团队在用从阿里内部交易系统里长出来的稳定性和事务能力是核心优势。南方航空、厦门地铁这些对一致性极高的场景在用。我有几个金融行业的朋友团队在用——他们核心系统不能丢一笔数据OceanBase 的强一致 自动容灾对他们特别合适。维度评价适合金融 / 政务对高可用要求严格、不容许数据丢失致命短板运维复杂、社区文档比 TiDB 少、国际化弱还没死透3 类场景里它仍然合理有人会问那分库分表是不是没用了不是。场景为什么仍然合理老系统跑得稳迁移风险和成本远大于好处老项目稳定运行就是价值小团队 / 数据量不大上一套 NewSQL 集群机器 学习 运维成本都上来划不来对厂商有顾虑中间件底层还是 MySQL读写 / 锁行为都是熟悉的所以「淘汰」这个词其实不准确。更准确的描述是分库分表正在从「首选方案」变成「备选方案」。数据量没到大盘先用「分区表」过渡很多人一遇到「单表过亿」就立刻想分库分表——先别急。MySQL 8.0 / PostgreSQL 都原生支持分区表单实例、单数据库内部按时间或 hash 把一张大表切成多个物理分区对业务 SQL 完全透明。数据量推荐方案 1 亿优化 SQL 索引——大概率不需要拆1-10 亿数据库分区表按时间分区最常见比如订单按月分区10-50 亿 写入热点NewSQL 或分库分表 50 亿 / 多维度查询NewSQL ES分区表的好处很明显不引入中间件没有跨库 JOIN / 跨库事务的烦恼DDL / 备份按分区做不用全表锁历史数据归档容易——直接把老分区 detach 落冷存。分区表能扛的数据量比你想象的大得多——MySQL 8.0 单库十亿级数据 合理分区 索引完全跑得动。我见过不少项目硬上分库分表结果发现单库分区表读写分离就能解决 90% 的问题。分库分表里的复杂查询建议引入 ES如果你已经在分库分表里了——不要硬刚多维查询。「按用户查订单」可以走分片键但「按商家 ID 查」「按手机号反查」「按状态 时间区间统计」这些查询分库分表中间件做不了。硬刚的结果就是开头那个故事广播全库、内存合并、OOM。正确做法把查询需求拆出来扔到 Elasticsearch。MySQL分库分表 ──binlog──► Canal / 阿里云 DTS │ ▼ Elasticsearch │ ▼ 多维查询 / 全文检索 / 聚合统计为什么 ES 适合倒排索引让多维度过滤在毫秒级别返回聚合统计比中间件做内存合并快 10-100 倍全文检索 模糊匹配是 SQL 永远做不到的能力数据冗余成本低—— 几 TB 的 ES 集群成本远低于多扩一倍 NewSQL 集群。实际操作里MySQL 写订单保证事务→ 通过 binlog 同步到 ES → 复杂查询全走 ES。这种「分库分表 ES 双写」的组合扛住国内不少头部电商的搜索、运营后台、报表查询场景。决策矩阵你属于哪一象限写在选型前要先问自己 3 个问题数据量到底在哪个量级——很多「数据量大」的烦恼优化 SQL 就解决了。出现「表 1TB / 日增 10GB / DDL 失败 / 备份超时 / 写入瓶颈 / 多维查询无解」任一信号才该动手拆。团队有没有人能维护——TiDB / OceanBase / PolarDB-X 出问题不像 MySQL 那么好排查。要有人能看 slow query log、理解 Region 热点、处理 MVCC 写入放大。没人 没预算买商业支持 → 选型要慎重。业务对 SQL 兼容性多敏感——新系统问题不大老系统迁移要认真测尤其是用了 MySQL 特有语法 / 存储过程 / 触发器的地方。迁移前跑一遍全量 SQL 回放。我的判断分库分表解决过真实的问题帮很多团队扛过了那段时间。但它是为了填补 10 年前的技术空缺——那时候没有更好的选择。现在有了。就像你不会再用软盘备份数据——不是软盘的问题是有更好的东西出现了。3 条建议新项目认真看看 TiDB / OceanBase / PolarDB-X如果数据量没到先上分区表 ES老项目评估迁移成本别为了换而换——能跑稳就先跑稳现在维护一套分库分表的同学也别焦虑——把它跑稳就行等真正需要的时候再升级不迟如果有复杂查询痛点先引入 ES是性价比最高的选择。技术选型没有标准答案合适的才是好的。欢迎加入我的知识星球全面提升技术能力。 加入方式“长按”或“扫描”下方二维码噢星球的内容包括项目实战、面试招聘、源码解析、学习路线。文章有帮助的话在看转发吧。 谢谢支持哟 (*^__^*