一、前言关系型数据库本身比较容易成为系统瓶颈单机存储容量、连接数、处理能力都有限。当单表的数据量达到1000W或100G以后由于查询维度较多即使添加从库、优化索引做很多操作时性能仍下降严重。此时就要考虑对其进行切分了切分的目的就在于减少数据库的负担缩短查询时间。数据库分布式核心内容无非就是数据切分Sharding以及切分后对数据的定位、整合。数据切分就是将数据分散存储到多个数据库中使得单一数据库中的数据量变小通过扩充主机的数量缓解单一数据库的性能问题从而达到提升数据库操作性能的目的。数据切分根据其切分类型可以分为两种方式垂直纵向切分和水平横向切分二、数据库瓶颈不管是IO瓶颈还是CPU瓶颈最终都会导致数据库的活跃连接数增加进而逼近甚至达到数据库可承载的活跃连接数的阈值。在业务service来看 就是可用数据库连接少甚至无连接可用接下来就可以想象了并发量、吞吐量、崩溃。2.1 IO瓶颈第一种磁盘读IO瓶颈热点数据太多数据库缓存放不下每次查询会产生大量的IO降低查询速度-分库和垂直分表第二种网络IO瓶颈请求的数据太多网络带宽不够 -分库2.2 CPU瓶颈第一种SQl问题如SQL中包含join,group by, order by非索引字段条件查询等增加CPU运算的操作-SQL优化建立合适的索引在业务Service层进行业务计算。第二种单表数据量太大查询时扫描的行太多SQl效率低增加CPU运算的操作。-水平分表。三、分库分表3.1 水平分库1、概念以字段为依据按照一定策略hash、range等将一个库中的数据拆分到多个库中。2、结果每个库的结构都一样 每个库中的数据不一样没有交集 所有库的数据并集是全量数据3、场景系统绝对并发量上来了分表难以根本上解决问题并且还没有明显的业务归属来垂直分库的情况下。4、分析库多了io和cpu的压力自然可以成倍缓解3.2 水平分表1、概念以字段为依据按照一定策略hash、range等讲一个表中的数据拆分到多个表中。2、结果每个表的结构都一样 每个表的数据不一样没有交集所有表的并集是全量数据。3、场景系统绝对并发量没有上来只是单表的数据量太多影响了SQL效率加重了CPU负担以至于成为瓶颈可以考虑水平分表。4、分析单表的数据量少了单次执行SQL执行效率高了自然减轻了CPU的负担。3.3 垂直分库1、概念以表为依据按照业务归属不同将不同的表拆分到不同的库中。2、结果每个库的结构都不一样 每个库的数据也不一样没有交集 所有库的并集是全量数据3、场景系统绝对并发量上来了并且可以抽象出单独的业务模块的情况下。4、分析到这一步基本上就可以服务化了。例如随着业务的发展一些公用的配置表、字典表等越来越多这时可以将这些表拆到单独的库中甚至可以服务化。再者随着业务的发展孵化出了一套业务模式这时可以将相关的表拆到单独的库中甚至可以服务化。3.4 垂直分表1、概念以字段为依据按照字段的活跃性将表中字段拆到不同的表中主表和扩展表。2、结果每个表的结构不一样。 每个表的数据也不一样一般来说每个表的字段至少有一列交集一般是主键用于关联数据。 所有表的并集是全量数据。3、场景系统绝对并发量并没有上来表的记录并不多但是字段多并且热点数据和非热点数据在一起单行数据所需的存储空间较大以至于数据库缓存的数据行减少查询时回去读磁盘数据产生大量随机读IO产生IO瓶颈。4、分析可以用列表页和详情页来帮助理解。垂直分表的拆分原则是将热点数据可能经常会查询的数据放在一起作为主表非热点数据放在一起作为扩展表这样更多的热点数据就能被缓存下来进而减少了随机读IO。拆了之后要想获取全部数据就需要关联两个表来取数据。但记住千万别用join因为Join不仅会增加CPU负担并且会将两个表耦合在一起必须在一个数据库实例上。关联数据应该在service层进行分别获取主表和扩展表的数据然后用关联字段关联得到全部数据。四、分库分表工具sharding-jdbc当当 TSharding蘑菇街 Atlas奇虎360 Cobar阿里巴巴 MyCAT基于Cobar Oceanus58同城 Vitess谷歌 各种工具的利弊自查五、分库分表带来的问题分库分表能有效缓解单机和单表带来的性能瓶颈和压力突破网络IO、硬件资源、连接数的瓶颈同时也带来一些问题下面将描述这些问题和解决思路。5.1 事务一致性问题分布式事务当更新内容同时存在于不同库找那个不可避免会带来跨库事务问题。跨分片事务也是分布式事务没有简单的方案一般可使用“XA协议”和“两阶段提交”处理。分布式事务能最大限度保证了数据库操作的原子性。但在提交事务时需要协调多个节点推后了提交事务的时间点延长了事务的执行时间导致事务在访问共享资源时发生冲突或死锁的概率增高。随着数据库节点的增多这种趋势会越来越严重从而成为系统在数据库层面上水平扩展的枷锁。最终一致性对于那些性能要求很高但对一致性要求不高的系统往往不苛求系统的实时一致性只要在允许的时间段内达到最终一致性即可可采用事务补偿的方式。与事务在执行中发生错误立刻回滚的方式不同事务补偿是一种事后检查补救的措施一些常见的实现方法有对数据进行对账检查基于日志进行对比定期同标准数据来源进行同步等。5.2 跨节点关联查询join问题切分之前系统中很多列表和详情表的数据可以通过join来完成但是切分之后数据可能分布在不同的节点上此时join带来的问题就比较麻烦了考虑到性能尽量避免使用Join查询。解决的一些方法全局表全局表也可看做“数据字典表”就是系统中所有模块都可能依赖的一些表为了避免库join查询可以将这类表在每个数据库中都保存一份。这些数据通常很少修改所以不必担心一致性的问题。字段冗余一种典型的反范式设计利用空间换时间为了性能而避免join查询。例如订单表在保存userId的时候也将userName也冗余的保存一份这样查询订单详情顺表就可以查到用户名userName就不用查询买家user表了。但这种方法适用场景也有限比较适用依赖字段比较少的情况而冗余字段的一致性也较难保证。数据组装在系统service业务层面分两次查询第一次查询的结果集找出关联的数据id然后根据id发起器二次请求得到关联数据最后将获得的结果进行字段组装。这是比较常用的方法。ER分片关系型数据库中如果已经确定了表之间的关联关系如订单表和订单详情表并且将那些存在关联关系的表记录存放在同一个分片上那么就能较好地避免跨分片join的问题可以在一个分片内进行join。在1:1或1n的情况下通常按照主表的ID进行主键切分。5.3 跨节点分页、排序、函数问题跨节点多库进行查询时会出现limit分页、order by 排序等问题。分页需要按照指定字段进行排序当排序字段就是分页字段时通过分片规则就比较容易定位到指定的分片当排序字段非分片字段时就变得比较复杂.需要先在不同的分片节点中将数据进行排序并返回然后将不同分片返回的结果集进行汇总和再次排序最终返回给用户如下图取第一页的数据对性能影响还不是很大。但是如果取得页数很大情况就变得复杂的多因为各分片节点中的数据可能是随机的为了排序的准确性需要将所有节点的前N页数据都排序好做合并最后再进行整体排序这样的操作很耗费CPU和内存资源所以页数越大系统性能就会越差。在使用Max、Min、Sum、Count之类的函数进行计算的时候也需要先在每个分片上执行相应的函数然后将各个分片的结果集进行汇总再次计算。5.4 全局主键避重问题在分库分表环境中由于表中数据同时存在不同数据库中主键值平时使用的自增长将无用武之地某个分区数据库自生成ID无法保证全局唯一。因此需要单独设计全局主键避免跨库主键重复问题。这里有一些策略UUIDUUID标准形式是32个16进制数字分为5段形式是8-4-4-4-12的36个字符。UUID是最简单的方案本地生成性能高没有网络耗时但是缺点明显占用存储空间多另外作为主键建立索引和基于索引进行查询都存在性能问题尤其是InnoDb引擎下UUID的无序性会导致索引位置频繁变动导致分页。结合数据库维护主键ID表在数据库中建立sequence表CREATETABLEsequence(idbigint(20)unsignedNOTNULLauto_increment,stubchar(1)NOTNULLdefault,PRIMARYKEY(id),UNIQUEKEYstub(stub))ENGINEMyISAM;stub字段设置为唯一索引同一stub值在sequence表中只有一条记录可以同时为多张表生辰全局ID。使用MyISAM引擎而不是InnoDb已获得更高的性能。MyISAM使用的是表锁对表的读写是串行的所以不用担心并发时两次读取同一个ID。当需要全局唯一的ID时执行REPLACE INTO sequence (stub) VALUES (‘a’); SELECT LAST_INSERT_ID();此方案较为简单但缺点较为明显存在单点问题强依赖DB当DB异常时整个系统不可用。配置主从可以增加可用性。另外性能瓶颈限制在单台Mysql的读写性能。另有一种主键生成策略类似sequence表方案更好的解决了单点和性能瓶颈问题。这一方案的整体思想是建立2个以上的全局ID生成的服务器每个服务器上只部署一个数据库每个库有一张sequence表用于记录当前全局ID。表中增长的步长是库的数量起始值依次错开这样就能将ID的生成散列到各个数据库上这种方案将生成ID的压力均匀分布在两台机器上同时提供了系统容错第一台出现了错误可以自动切换到第二台获取ID。但有几个缺点系统添加机器水平扩展较复杂每次获取ID都要读取一次DBDB的压力还是很大只能通过堆机器来提升性能。Snowflake分布式自增ID算法Twitter的snowfalke算法解决了分布式系统生成全局ID的需求生成64位Long型数字组成部分第一位未使用 接下来的41位是毫秒级时间41位的长度可以表示69年的时间 5位datacenterId,5位workerId。10位长度最多支持部署1024个节点 最后12位是毫秒内计数12位的计数顺序号支持每个节点每毫秒产生4096个ID序列。数据迁移、扩容问题当业务高速发展、面临性能和存储瓶颈时才会考虑分片设计此时就不可避免的需要考虑历史数据的迁移问题。一般做法是先读出历史数据然后按照指定的分片规则再将数据写入到各分片节点中。此外还需要根据当前的数据量个QPS以及业务发展速度进行容量规划推算出大概需要多少分片一般建议单个分片的单表数据量不超过1000W六、什么时候考虑分库分表能不分就不分并不是所有表都需要切分主要还是看数据的增长速度。切分后在某种程度上提升了业务的复杂程度。不到万不得已不要轻易使用分库分表这个“大招”避免“过度设计”和“过早优化”。分库分表之前先尽力做力所能及的优化升级硬件、升级网络、读写分离、索引优化等。当数据量达到单表瓶颈后在考虑分库分表。数据量过大正常运维影响业务访问这里的运维是指对数据库备份如果单表太大备份时需要大量的磁盘IO和网络IO 对一个很大的表做DDLMYSQL会锁住整个表这个时间会很长这段时间业务不能访问此表影响很大。 大表经常访问和更新就更有可能出现锁等待。随着业务发展需要对某些字段垂直拆分这里就不举例了。在实际业务中都可能会碰到有些不经常访问或者更新频率低的字段应该从大表中分离出去。数据量快速增长随着业务的快速发展单表中的数据量会持续增长当性能接近瓶颈时就需要考虑水平切分做分库分表了。 
长河君 · 2026/10/30 2:20:45 · 阅读 1.2k 浅谈分库分表
一、前言关系型数据库本身比较容易成为系统瓶颈单机存储容量、连接数、处理能力都有限。当单表的数据量达到1000W或100G以后由于查询维度较多即使添加从库、优化索引做很多操作时性能仍下降严重。此时就要考虑对其进行切分了切分的目的就在于减少数据库的负担缩短查询时间。数据库分布式核心内容无非就是数据切分Sharding以及切分后对数据的定位、整合。数据切分就是将数据分散存储到多个数据库中使得单一数据库中的数据量变小通过扩充主机的数量缓解单一数据库的性能问题从而达到提升数据库操作性能的目的。数据切分根据其切分类型可以分为两种方式垂直纵向切分和水平横向切分二、数据库瓶颈不管是IO瓶颈还是CPU瓶颈最终都会导致数据库的活跃连接数增加进而逼近甚至达到数据库可承载的活跃连接数的阈值。在业务service来看 就是可用数据库连接少甚至无连接可用接下来就可以想象了并发量、吞吐量、崩溃。2.1 IO瓶颈第一种磁盘读IO瓶颈热点数据太多数据库缓存放不下每次查询会产生大量的IO降低查询速度-分库和垂直分表第二种网络IO瓶颈请求的数据太多网络带宽不够 -分库2.2 CPU瓶颈第一种SQl问题如SQL中包含join,group by, order by非索引字段条件查询等增加CPU运算的操作-SQL优化建立合适的索引在业务Service层进行业务计算。第二种单表数据量太大查询时扫描的行太多SQl效率低增加CPU运算的操作。-水平分表。三、分库分表3.1 水平分库1、概念以字段为依据按照一定策略hash、range等将一个库中的数据拆分到多个库中。2、结果每个库的结构都一样 每个库中的数据不一样没有交集 所有库的数据并集是全量数据3、场景系统绝对并发量上来了分表难以根本上解决问题并且还没有明显的业务归属来垂直分库的情况下。4、分析库多了io和cpu的压力自然可以成倍缓解3.2 水平分表1、概念以字段为依据按照一定策略hash、range等讲一个表中的数据拆分到多个表中。2、结果每个表的结构都一样 每个表的数据不一样没有交集所有表的并集是全量数据。3、场景系统绝对并发量没有上来只是单表的数据量太多影响了SQL效率加重了CPU负担以至于成为瓶颈可以考虑水平分表。4、分析单表的数据量少了单次执行SQL执行效率高了自然减轻了CPU的负担。3.3 垂直分库1、概念以表为依据按照业务归属不同将不同的表拆分到不同的库中。2、结果每个库的结构都不一样 每个库的数据也不一样没有交集 所有库的并集是全量数据3、场景系统绝对并发量上来了并且可以抽象出单独的业务模块的情况下。4、分析到这一步基本上就可以服务化了。例如随着业务的发展一些公用的配置表、字典表等越来越多这时可以将这些表拆到单独的库中甚至可以服务化。再者随着业务的发展孵化出了一套业务模式这时可以将相关的表拆到单独的库中甚至可以服务化。3.4 垂直分表1、概念以字段为依据按照字段的活跃性将表中字段拆到不同的表中主表和扩展表。2、结果每个表的结构不一样。 每个表的数据也不一样一般来说每个表的字段至少有一列交集一般是主键用于关联数据。 所有表的并集是全量数据。3、场景系统绝对并发量并没有上来表的记录并不多但是字段多并且热点数据和非热点数据在一起单行数据所需的存储空间较大以至于数据库缓存的数据行减少查询时回去读磁盘数据产生大量随机读IO产生IO瓶颈。4、分析可以用列表页和详情页来帮助理解。垂直分表的拆分原则是将热点数据可能经常会查询的数据放在一起作为主表非热点数据放在一起作为扩展表这样更多的热点数据就能被缓存下来进而减少了随机读IO。拆了之后要想获取全部数据就需要关联两个表来取数据。但记住千万别用join因为Join不仅会增加CPU负担并且会将两个表耦合在一起必须在一个数据库实例上。关联数据应该在service层进行分别获取主表和扩展表的数据然后用关联字段关联得到全部数据。四、分库分表工具sharding-jdbc当当 TSharding蘑菇街 Atlas奇虎360 Cobar阿里巴巴 MyCAT基于Cobar Oceanus58同城 Vitess谷歌 各种工具的利弊自查五、分库分表带来的问题分库分表能有效缓解单机和单表带来的性能瓶颈和压力突破网络IO、硬件资源、连接数的瓶颈同时也带来一些问题下面将描述这些问题和解决思路。5.1 事务一致性问题分布式事务当更新内容同时存在于不同库找那个不可避免会带来跨库事务问题。跨分片事务也是分布式事务没有简单的方案一般可使用“XA协议”和“两阶段提交”处理。分布式事务能最大限度保证了数据库操作的原子性。但在提交事务时需要协调多个节点推后了提交事务的时间点延长了事务的执行时间导致事务在访问共享资源时发生冲突或死锁的概率增高。随着数据库节点的增多这种趋势会越来越严重从而成为系统在数据库层面上水平扩展的枷锁。最终一致性对于那些性能要求很高但对一致性要求不高的系统往往不苛求系统的实时一致性只要在允许的时间段内达到最终一致性即可可采用事务补偿的方式。与事务在执行中发生错误立刻回滚的方式不同事务补偿是一种事后检查补救的措施一些常见的实现方法有对数据进行对账检查基于日志进行对比定期同标准数据来源进行同步等。5.2 跨节点关联查询join问题切分之前系统中很多列表和详情表的数据可以通过join来完成但是切分之后数据可能分布在不同的节点上此时join带来的问题就比较麻烦了考虑到性能尽量避免使用Join查询。解决的一些方法全局表全局表也可看做“数据字典表”就是系统中所有模块都可能依赖的一些表为了避免库join查询可以将这类表在每个数据库中都保存一份。这些数据通常很少修改所以不必担心一致性的问题。字段冗余一种典型的反范式设计利用空间换时间为了性能而避免join查询。例如订单表在保存userId的时候也将userName也冗余的保存一份这样查询订单详情顺表就可以查到用户名userName就不用查询买家user表了。但这种方法适用场景也有限比较适用依赖字段比较少的情况而冗余字段的一致性也较难保证。数据组装在系统service业务层面分两次查询第一次查询的结果集找出关联的数据id然后根据id发起器二次请求得到关联数据最后将获得的结果进行字段组装。这是比较常用的方法。ER分片关系型数据库中如果已经确定了表之间的关联关系如订单表和订单详情表并且将那些存在关联关系的表记录存放在同一个分片上那么就能较好地避免跨分片join的问题可以在一个分片内进行join。在1:1或1n的情况下通常按照主表的ID进行主键切分。5.3 跨节点分页、排序、函数问题跨节点多库进行查询时会出现limit分页、order by 排序等问题。分页需要按照指定字段进行排序当排序字段就是分页字段时通过分片规则就比较容易定位到指定的分片当排序字段非分片字段时就变得比较复杂.需要先在不同的分片节点中将数据进行排序并返回然后将不同分片返回的结果集进行汇总和再次排序最终返回给用户如下图取第一页的数据对性能影响还不是很大。但是如果取得页数很大情况就变得复杂的多因为各分片节点中的数据可能是随机的为了排序的准确性需要将所有节点的前N页数据都排序好做合并最后再进行整体排序这样的操作很耗费CPU和内存资源所以页数越大系统性能就会越差。在使用Max、Min、Sum、Count之类的函数进行计算的时候也需要先在每个分片上执行相应的函数然后将各个分片的结果集进行汇总再次计算。5.4 全局主键避重问题在分库分表环境中由于表中数据同时存在不同数据库中主键值平时使用的自增长将无用武之地某个分区数据库自生成ID无法保证全局唯一。因此需要单独设计全局主键避免跨库主键重复问题。这里有一些策略UUIDUUID标准形式是32个16进制数字分为5段形式是8-4-4-4-12的36个字符。UUID是最简单的方案本地生成性能高没有网络耗时但是缺点明显占用存储空间多另外作为主键建立索引和基于索引进行查询都存在性能问题尤其是InnoDb引擎下UUID的无序性会导致索引位置频繁变动导致分页。结合数据库维护主键ID表在数据库中建立sequence表CREATETABLEsequence(idbigint(20)unsignedNOTNULLauto_increment,stubchar(1)NOTNULLdefault,PRIMARYKEY(id),UNIQUEKEYstub(stub))ENGINEMyISAM;stub字段设置为唯一索引同一stub值在sequence表中只有一条记录可以同时为多张表生辰全局ID。使用MyISAM引擎而不是InnoDb已获得更高的性能。MyISAM使用的是表锁对表的读写是串行的所以不用担心并发时两次读取同一个ID。当需要全局唯一的ID时执行REPLACE INTO sequence (stub) VALUES (‘a’); SELECT LAST_INSERT_ID();此方案较为简单但缺点较为明显存在单点问题强依赖DB当DB异常时整个系统不可用。配置主从可以增加可用性。另外性能瓶颈限制在单台Mysql的读写性能。另有一种主键生成策略类似sequence表方案更好的解决了单点和性能瓶颈问题。这一方案的整体思想是建立2个以上的全局ID生成的服务器每个服务器上只部署一个数据库每个库有一张sequence表用于记录当前全局ID。表中增长的步长是库的数量起始值依次错开这样就能将ID的生成散列到各个数据库上这种方案将生成ID的压力均匀分布在两台机器上同时提供了系统容错第一台出现了错误可以自动切换到第二台获取ID。但有几个缺点系统添加机器水平扩展较复杂每次获取ID都要读取一次DBDB的压力还是很大只能通过堆机器来提升性能。Snowflake分布式自增ID算法Twitter的snowfalke算法解决了分布式系统生成全局ID的需求生成64位Long型数字组成部分第一位未使用 接下来的41位是毫秒级时间41位的长度可以表示69年的时间 5位datacenterId,5位workerId。10位长度最多支持部署1024个节点 最后12位是毫秒内计数12位的计数顺序号支持每个节点每毫秒产生4096个ID序列。数据迁移、扩容问题当业务高速发展、面临性能和存储瓶颈时才会考虑分片设计此时就不可避免的需要考虑历史数据的迁移问题。一般做法是先读出历史数据然后按照指定的分片规则再将数据写入到各分片节点中。此外还需要根据当前的数据量个QPS以及业务发展速度进行容量规划推算出大概需要多少分片一般建议单个分片的单表数据量不超过1000W六、什么时候考虑分库分表能不分就不分并不是所有表都需要切分主要还是看数据的增长速度。切分后在某种程度上提升了业务的复杂程度。不到万不得已不要轻易使用分库分表这个“大招”避免“过度设计”和“过早优化”。分库分表之前先尽力做力所能及的优化升级硬件、升级网络、读写分离、索引优化等。当数据量达到单表瓶颈后在考虑分库分表。数据量过大正常运维影响业务访问这里的运维是指对数据库备份如果单表太大备份时需要大量的磁盘IO和网络IO 对一个很大的表做DDLMYSQL会锁住整个表这个时间会很长这段时间业务不能访问此表影响很大。 大表经常访问和更新就更有可能出现锁等待。随着业务发展需要对某些字段垂直拆分这里就不举例了。在实际业务中都可能会碰到有些不经常访问或者更新频率低的字段应该从大表中分离出去。数据量快速增长随着业务的快速发展单表中的数据量会持续增长当性能接近瓶颈时就需要考虑水平切分做分库分表了。