MySQL 开始分库分表时，别急着换国产数据库：先问完这五句

一个 MySQL 集群开始不好伺候，团队通常会经历同一串动作：加只读副本、拆热点表、按用户 ID 分库、路由写进中间件、跨库查询单独做服务。

最开始都觉得还能扛。

直到某次需求只是“查一下用户在所有店铺的订单”，代码评审里先出现的不是 SQL，而是“这个表到底落在哪个库”“能不能接受异步汇总”“跨库事务谁兜底”。这时候，“换国产数据库”会突然变成一个很有诱惑力的选项。

但它不是止痛药。

国产数据库不是让 MySQL 原地变强；它是在替你接走一部分扩展、可用性和兼容性问题，同时把另一部分复杂度交还给你。

这篇不列厂商，也不讲谁排第几。只把一个只用过 MySQL 的开发者最该问的五句话讲清楚：它是什么，能干什么，你为什么可能需要它，代价落在哪里，最后又到底能换回什么。

【配图占位 1】单库 → 应用层分片 → 多节点数据层。突出“复杂度没有消失，只是换了落点”。详见配图 brief。

1. 这是啥

一句话：国产数据库是一组由本土厂商交付的关系数据库产品；对应用来说仍然是表、SQL、索引和事务，对团队来说换的是兼容边界、扩展方式和运维模型。

别把“国产”理解成一种新的数据库原理。

你不会因为换了它，就突然不用写索引、不用看慢查询、不用处理死锁。业务代码照样要连数据库，ORM 照样会生成 SQL，线上照样会有大事务和误删风险。它首先是一个产品与交付选择，不是一种脱离关系数据库常识的新技术。

真正容易误解的是后半句。

MySQL 用久了，很多人默认的世界观是：一份数据主要待在一台主库上；容量不够，先加机器；读不够，拉副本；再不够，就由应用决定数据去哪张表、哪个库。

而你考虑换的这类产品，常常会把“数据能不能放到多台机器上”“一台机器故障后谁接手”“应用看到的还是不是一张表”这些事，往数据库内部收一部分。

这不代表它替你做完了架构。

它只是把原来散在路由层、同步任务、脚本和人工操作里的规则，换成了数据库自己的规则。规则放的位置变了，责任没有消失。

2. 干什么的

和单机 MySQL 相比，开发者真正能感知到的变化，通常不是某个宣传名词，而是下面几件很具体的事。

数据可以跨机器放。

以前一张大表顶到单机磁盘、CPU 或写入上限，你的动作往往是拆库拆表。拆完以后，orders_17 和 orders_18 在应用眼里已经不是一张表了：路由要算，聚合要补，运维要记住每个库的容量。

有些数据库可以把一张逻辑表拆成多个数据分区，放到不同机器上。应用仍然面对一张表，数据到底在哪台机器，由系统按规则处理。你少写了一层分片路由，至少不用每次业务查询都先问“落点在哪”。

事务可能跨节点。

分库之后，最难受的不一定是查询，而是本来一句 BEGIN 能解决的事情，忽然要面对多个库。你可以改成最终一致，也可以上补偿和对账；这都是工程方案，但每种都要把失败路径补齐。

支持跨节点事务的数据库，能让一部分原本跨库的写入仍在数据库事务语义里完成。这里的关键词是“一部分”。数据一旦不在同一个节点，协调、网络往返和副本确认都会进账单。它能让你少造轮子，不会让物理成本归零。

高可用的动作更靠近数据库。

单主、主从、故障切换、读写漂移，这些词 MySQL 团队都不陌生。差别在于，有些产品会把副本、故障检测、切换和数据重建做得更内聚。应用不必为每一个节点故障临时拼一套流程。

但“更内聚”不等于“你不用管”。副本放在哪个故障域、切换时能丢多少数据、连接池多久感知、下游能不能承受短暂失败，仍然是你的系统问题。

扩容不再总是一次业务改造。

分库分表最贵的部分，往往不是第一次拆，而是第二次、第三次扩容。库数量从 16 变成 32 时，路由规则、历史数据、离线任务、报表口径都可能要动。

如果数据库能把数据分布与重平衡接住，扩容会更像一次受控的基础设施操作，而不是让业务团队改一轮代码。注意，是“更像”，不是“点一下按钮就结束”。热点、容量、水位和迁移窗口还是要盯。

这些能力可以压成一句：它想把你已经塞进应用层的数据分布问题，往数据库里收回去。

3. 我为什么要用它

不是因为“分布式听起来更高级”，更不是因为某个采购词。

你该考虑它，通常是因为 MySQL 的使用方式已经开始反过来塑造业务代码，而且这种塑造越来越贵。

有三个信号，缺一个都不够。

单库真的撑不住了。

这里说的不是“表有点大”或者“慢查询偶尔报警”。先把索引、SQL、归档、冷热分离、连接池、读写模型这些基础账算完。如果这些都没做，直接换库，多半是在用更复杂的系统掩盖旧问题。

真正值得抬头看新方案的情况是：数据和写入还在持续长，单机的容量或吞吐已经成了明确边界；而且你不是只想把机器再加大一档，而是需要一种能随着节点增加继续承接数据的方式。

分库分表已经把业务代码磨坏了。

这不是“项目里有 Sharding 中间件”就算。

是每做一个需求，开发者都得先问分片键；跨分片查询要改成异步任务；分页、排序、聚合在多个库之间变得别扭；全局唯一 ID、跨库事务、数据回灌和扩容迁移各自长出一套约定。最危险的是，这些约定不会集中在一个地方，而是渗进订单、账户、营销、报表的每一层。

如果你的团队已经花大量时间维护这些边界，数据库把部分分布规则收回去，可能比继续堆中间件更划算。

你想替换，但真正害怕的是被锁死。

很多替换讨论一上来就只问：“兼不兼容 MySQL？”

这个问题不够。兼容协议，和你的应用能平移，是两回事。驱动能连上，只说明第一关过了。函数、排序规则、时间语义、事务隔离、存储过程、触发器、DDL 行为、备份链路、监控脚本，后面每一关都可能留下坑。

所以“怕被锁定”不能靠承诺解决，只能靠验收解决：把现网 SQL、存储过程、关键报表、故障切换和备份恢复拉进 PoC。你能跑通、能解释、能回滚的兼容，才叫兼容。

这三件事同时出现时，才值得认真评估换库：

• 单机边界已经是现实，不是想象；
• 应用层分片复杂度已经持续吞人；
• 团队愿意为 PoC、压测和运维能力投入时间。

少一条，都别把换数据库当成默认答案。

【配图占位 2】三盏“该不该换”的信号灯：单机边界、应用层分片成本、团队治理能力。详见配图 brief。

4. 有什么负担

换过去以后，最容易失望的原因，是团队以为自己买到了“没有分库分表”，实际上买到的是“分库分表不再只写在业务代码里”。

账还在，只是换了收款方。

开发习惯要改。

以前你写 SQL，默认假设数据都在本机、事务都在本地、扫描范围可控。换到多节点环境后，要开始对分区键、热点值、跨节点访问敏感。

一条没有带分区条件的查询，单库里可能只是慢一点；在多节点环境里，它可能变成扫更多数据、走更多网络，最后把延迟和资源账一起拉高。业务里特别集中的租户、商家、用户或时间段，也可能让“横向扩展”变成少数节点很忙、其他节点很闲。

这不是让每个开发者都去当 DBA，而是 SQL 评审里要多一条判断：它会不会把数据分布规律打穿。

SQL 不能只看能不能执行。

最危险的迁移进度条是：应用启动成功了。

生产系统依赖的不只有 SELECT 和 INSERT。一段历史遗留的存储过程，一个依赖特定排序规则的查询，一次线上 ALTER TABLE，一个备份恢复脚本，都可能在新系统里有不同语义或不同代价。

特别是 online DDL。单库里你已经形成了某种“这个变更大概多久、会不会挡写入”的直觉。换库后，这个直觉必须作废重建。数据分布、复制、重平衡和元数据操作都会改变 DDL 的成本曲线。没有在接近生产的数据量上演练过，就不要给业务承诺窗口。

事务行为会多一层成本。

跨节点事务不是魔法。它能帮你保住一部分一致性，也会引入协调路径。高频、短小、跨节点的写入，往往比单节点事务更贵。

更现实的做法不是“既然支持，就放心跨”。而是把数据模型和写入路径设计成：大多数高频事务尽量局部完成；真正必须跨节点的少数路径，单独压测、监控和限流。

别因为数据库提供了能力，就把它当成默认写法。

运维不会消失，只是从主从切换，变成了更长的清单。

你会开始关心节点是否均衡、某个分区是否过热、扩容后数据有没有迁完、副本是否跨了故障域、容量余量是否够重平衡、故障时应用连接会怎样抖。

托管服务能替你做掉一部分机器活，但不能替你定义这些阈值，更不能替你判断业务是否能承受一次切换。

所以要把一句话说透：分布规则由数据库接管，不等于分布式系统由数据库替你负责。

5. 有什么收益

收益当然有，不然没人会折腾。

最直接的收益，是让应用重新把注意力放回业务，而不是长期维护数据路由的旁枝末节。

当一张逻辑表可以在多个节点上承接数据，当扩容不必同步改一轮路由规则，当部分跨库写入不必立刻拆成补偿事务，你会发现很多代码终于不需要为了“数据在哪”而存在。新需求的讨论能回到数据模型和业务规则，而不是先开一场分片键会议。

还有一个收益，是容量和可用性的操作空间变大。

单机体系到了边界，选择通常很硬：升级机器、继续拆，或者接受瓶颈。能够横向承接数据的系统，给了你多一条路。某台机器出问题时，副本与切换机制也能让故障处理更标准化，而不是每次靠人肉救火。

但这些收益有明确前提。

如果你的数据量和写入还在单机的舒适区，MySQL 的成熟生态、低心智负担和团队熟悉度，本身就是收益。为了一个未来也许会出现的瓶颈，提前引入多节点复杂度，通常不划算。

如果你的分库分表只是两三张边缘表，且团队已经把路由、迁移和查询边界控制得很稳，替换也未必值得。重写、回归、双写、演练和新的运维体系都要花钱；“少一点不舒服”换不回这笔成本。

真正能吃到收益的，是这类团队：增长边界已经清楚；应用层分片已经成了长期税；团队愿意把分区、热点、事务路径和故障演练当成日常工程，而不是上线前的临时作业。

最后给一个比“选哪个”更实用的动作。开 PoC 前，先让参与的人分别写下这五个答案：

1. 我们今天的瓶颈，究竟是单机容量、写入，还是 SQL 和索引没做好？
2. 如果继续分库分表，未来一年最贵的三件事是什么？
3. 哪些高频写入可以保证局部完成，哪些真的必须跨节点？
4. 现网有哪些 SQL、DDL、脚本和工具必须逐条验收？
5. 故障、扩容、回滚发生在晚上两点时，谁有能力把它处理完？

如果这五句写不出来，先别选产品。

数据库选型真正要买的，从来不是一个更响的名字，而是一种你们团队能长期承担的复杂度。

【配图占位 3】收益与边界的天平：少写路由、横向承接、可用性标准化，对应热点、跨节点事务、SQL 回归和运维能力。详见配图 brief。