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

Wed, 15 Jul 2026 12:00:00 +0800

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

最开始都觉得还能扛。

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

但它不是止痛药。

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

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

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

1. 这是啥

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

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

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

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

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

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

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

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

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

数据可以跨机器放。

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

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

事务可能跨节点。

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

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

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

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

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

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

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

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

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

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

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