数据库--分库分表--方案/切分方式/注意的问题

原文网址：数据库--分库分表--方案/切分方式/注意的问题_IT利刃出鞘的博客-CSDN博客

简介

本文介绍数据库分库分表技术。包括：什么时候进行分库分表，分库分表的方式，分库分表需要注意的问题。

此技术也是Java后端面试中常见的问题。

什么时候分库分表

《阿里巴巴 Java 开发手册》：

1. 单表行数超过 500 万行或者单表容量超过 2GB，才推荐进行分库分表。
2. 如果预计三年后的数据量根本达不到这个级别，请不要在创建表时就分库分表。

有人测试过，超过1000万行性能急剧下降，所以建议500万行的时候进行分库分表。

其他需要分库分表的场景

场景1、数据量过大，正常运维影响业务访问

这里说的运维，指：

1）对数据库备份，如果单表太大，备份时需要大量的磁盘IO和网络IO。例如1T的数据，网络传输占50MB时候，需要20000秒才能传输完毕，整个过程的风险都是比较高的

2）对一个很大的表进行DDL修改时，MySQL会锁住全表，这个时间会很长，这段时间业务不能访问此表，影响很大。如果使用pt-online-schema-change，使用过程中会创建触发器和影子表，也需要很长的时间。在此操作过程中，都算为风险时间。将数据表拆分，总量减少，有助于降低这个风险。

3）大表会经常访问与更新，就更有可能出现锁等待。将数据切分，用空间换时间，变相降低访问压力

场景2、随着业务发展，需要对某些字段垂直拆分

举个例子，假如项目一开始设计的用户表如下：

id                   bigint             #用户的ID
name                 varchar            #用户的名字
last_login_time      datetime           #最近登录时间
personal_info        text               #私人信息.....
#其他信息字段

在项目初始阶段，这种设计是满足简单的业务需求的，也方便快速迭代开发。

而当业务快速发展时，用户量从10w激增到10亿，用户非常的活跃，每次登录会更新 last_login_name 字段，使得 user 表被不断update，压力很大。

而其他字段：id, name, personal_info 是不变的或很少更新的，此时在业务角度，就要将 last_login_time 拆分出去，新建一个 user_time 表。

personal_info 属性是更新和查询频率较低的，并且text字段占据了太多的空间。这时候，就要对此垂直拆分出 user_ext 表了。

场景3、安全性和可用性

鸡蛋不要放在一个篮子里。在业务层面上垂直切分，将不相关的业务的数据库分隔，因为每个业务的数据量、访问量都不同，不能因为一个业务把数据库搞挂而牵连到其他业务。

利用水平切分，当一个数据库出现问题时，不会影响到100%的用户，每个库只承担业务的一部分数据，这样整体的可用性就能提高。

能不切分尽量不要切分

并不是所有表都需要进行切分，主要还是看数据的增长速度。切分后会在某种程度上提升业务的复杂度，数据库除了承载数据的存储和查询外，协助业务更好的实现需求也是其重要工作之一。

不到万不得已不用轻易使用分库分表这个大招，避免"过度设计"和"过早优化"。

分库分表之前，不要为分而分，先尽力去做力所能及的事情，例如：升级硬件、升级网络、读写分离、索引优化等等。当数据量达到单表的瓶颈时候，再考虑分库分表。

分库分表中间件

站在巨人的肩膀上能省力很多，目前分库分表已经有一些较为成熟的开源解决方案：

• sharding-jdbc（当当）
• MyCAT（基于Cobar）
• TSharding（蘑菇街）
• Atlas（奇虎360）
• Cobar（阿里巴巴）
• Oceanus（58同城）
• Vitess（谷歌）
• 了解更多点击这里啊！！！

切分方式

见：数据库--分库分表--垂直分表与水平分表_IT利刃出鞘的博客-CSDN博客

分库分表带来的问题

分库分表能有效的缓解单机和单库带来的性能瓶颈和压力，突破网络IO、硬件资源、连接数的瓶颈，同时也带来了一些问题。下面将描述这些技术挑战以及对应的解决思路。

上边只是部分内容，为便于维护，本文已迁移到此地址：数据库-分库分表-方案/切分方式/注意的问题 - 自学精灵