「分库分表不是万能药」：高并发MySQL架构的理性选择

越“分”越乱，是不是你也掉过这个坑？

前些日子，朋友所在的公司为了冲刺年末促销，大张旗鼓地将原本的单个数据库拆分成八个分库、十六个分表，不过结果却事与愿违，系统不仅没有提速，反而慢得像蜗牛爬行一般，连基本的报表都查不出来；老板一怒之下，DBA不得不连夜加班，开发团队也纷纷抱怨连连。

我问他一个问题：是不是所有高并发问题，都能靠分库分表解决？

他说：“以前我也这么以为——现在真不敢了。”

分库分表不是银弹，它只是架构演进中的一枚棋子。

今天我们就聊聊，到底什么时候该“分”？怎么“分”？分完又该怎么“活下去”？

看完这篇，你会对“分库分表”这事，有个清晰、冷静、能吹也能干的判断。

并发瓶颈真的是数据库的问题吗

很多项目一上来就喊“数据库扛不住了”，但真相往往扎心。并发的瓶颈，八成不在数据库，而在业务设计和SQL习惯上。

一堆慢SQL没索引

一个事务锁着十几张表

同步更新、死循环队列

甚至还有人用
SELECT *查全表

不是MySQL不行，是设计太随性

单库其实可以支撑起相当高的并发，要是你加上主从读写分离、Redis缓存命中以及SQL优化，或许都能让性能翻倍很多回。

所以，别一看到TPS上升就喊“我要分库！”。那不是架构升级，那是交智商税。

想想你上次线上“高并发”是不是，其实是日志打太多了？

从事实指标判断需要“分”的时机

真正要不要分，要看三个硬指标：QPS、数据量、事务耦合度