本文讲述了在面临数据库性能瓶颈时，通过垂直拆分数据库来解决主库写数据慢的问题。作者详细解析了垂直拆分的原理、步骤、好处及潜在的不足，指出垂直拆分能有效减轻数据库压力，提高查询效率，并为系统扩展提供便利，但也增加了系统复杂性和事务处理难度。最后，讨论了当单表数据量过大时，需要进一步进行水平拆分的情况。
V-xin：ruyuanhadeng获得600+页原创精品文章汇总PDF
前 言
读写分离方案上线后，订单sql查询时间再一次稳定在了300ms以下，此时对数据的增删改操作会走主库，而读请求会走从库，通过读写分离大大提升了数据读的处理能力，但遗憾的是没办法提升主库写数据的能力。
新的挑战
那么什么时候主库写数据的压力会过大呢？其实我们之前也聊过这个问题，那就是多个业务共用一个物理数据库的，比如商品相关的表、订单相关的表和用户相关的表等，所有表都放到了一个mysql数据库中，就像这样：
此时商品模块、订单模块、用户模块都部署在同一台物理数据库上，说白了就是主库上，那么此时这台物理数据库的CPU、内存和网络的负载能力，都是商品模块、订单模块、用户模块共用的。
这就很尴尬了，由于这3个模块是共用同一台数据库的资源，那么就势必会相互影响，比如某一天商品模块做了一些活动，尴尬的是商品模块并没有做读写分离，那么这个时候可能商品模块，会对这台物理数据库进行大量的读操作，此时这台物理数据库的CPU、内存和网络负载占用都很高。
而数据库的资源是有限的，既然商品模块占用了大量的数据库资源，那么留给订单模块可用的资源就非常少了，这个时候就会导致订单库写数据很慢，写入一条订单数据突增到了2s，对于订单来说，这个肯定是万万不能接受的
那么有没
最低0.47元/天 解锁文章
715
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
