数据库切分是系统中最关键的核心环节也是瓶颈。随着现在互联网应用的普及，使得数据库的负载非常高，数据库切分是为了保护数据库，增加缓存。当然并非所有的表都需要切分，这主要还是看具体数据的成长速度。

数据库切分的原则包括：

数据量过大，正常运行影响业务访问，数据库备份，如果表格过大，备份需要大量的磁盘IO和网络IO。例如，1T的数据在网络传输占50MB时，需要20000秒，整个过程的风险很高。

不切分尽量不切分

首先，升级硬件、升级网络、读写分离、索引优化等，尽最大努力。数据量达到单表瓶颈时，请考虑分库表。不要轻易使用分库表这个“大把戏”，避免“过度设计”和“过早优化”。在分库表之前，不要为了得分而得分。

修改大型DDL时，MySQL锁定全表，此时间长，此时业务无法访问该表，影响大。如果使用pt-online-schema-change，在使用过程中会制作触发器和影表，也需要很长时间。在这个操作过程中，被认为是风险时间。分割数据表，减少总量，有助于降低这一风险。

随着业务的发展，需要垂直拆分某些字段

在项目初期阶段，该设计符合简单的业务需求，便于快速反复开发。

举个例子，开始设计的用户表如图18-1：

业务迅速发展时，用户数从10w急剧增加到10亿，用户非常活跃，每次登录都更新last_login_name字段，user表不断变成update，压力很大。其他字段:id、name、personal_info不变或更新较少。此时，从业务角度分割last_login_time，建立新的user_time表。personal_info属性更新查询频率低，text字段占用空间过大。此时，必须垂直分割user_ext表。

安全性和可用性

利用水平切分，当数据库出现问题时，不会影响100%的用户，每个库只承担业务的一部分数据，可以提高整体的可用性。在业务水平上垂直分割，分割不相关业务的数据库，每个业务的数据量、访问量不同，所以因为一个业务搞挂而牵连其他数据库。

数据量迅速增加

随着业务的快速发展，表中的数据量持续增加，性能接近瓶颈时，需要考虑水平分割，制作分库分割表。此时，必须选择合适的分割规则，预测数据容量。

能够不切分就尽量不切分，在数据量过大的情况下，正常运行已经影响了业务访问就需要切分，企业的业务量不断扩展，需要垂直拆分某些字段等等，下面我们就来详细介绍一下它的切分原则。分割后，在一定程度上提高业务复杂性，数据库除了载入数据的存储和查询外，协助业务更好地实现需求也是其重要工作之一。大表经常访问和更新，锁可能会出现。切分数据，用空间更换时间，变相降低访问压力。

如果您想了解更多相关信息

 立刻咨询 

点击下方二维码咨询！

[1]