你没见过的分库分表原理解析和解决方案(一)

最新推荐文章于 2023-09-06 16:17:51 发布
最新推荐文章于 2023-09-06 16:17:51 发布
阅读量105 收藏
点赞数
文章标签： java github 数据库
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/BASK2311/article/details/131083737
版权

你没见过的分库分表原理解析和解决方案(一)

高并发三驾马车:分库分表、MQ、缓存。今天给大家带来的就是分库分表的干货解决方案,哪怕你不用我的框架也可以从中听到不一样的结局方案和实现。

一款支持自动分表分库的orm框架easy-query 帮助您解脱跨库带来的复杂业务代码,并且提供多种结局方案和自定义路由来实现比中间件更高性能的数据库访问。

上篇文章简单的带大家了解了框架如何使用分片本章将会以理论为主加实践的方式呈现不一样的分表分库。

介绍

分库分表一直是老生常谈的问题,市面上也有很多人侃侃而谈,但是大部分的说辞都是一样,甚至给不出一个实际的解决方案,本人经过多年的深耕在其他语言里面多年的维护和实践下来秉着happy coding的原则希望更多的人可以了解和认识到该框架并且给大家一个全新的针对分库分表的认识。 我们也经常戏称项目一开始就用了分库分表结果上线没多少数据,并且整个开发体验来说非常繁琐,对于业务而言也是极其不友好,大大拉长开发周期不说,bug也是更加容易产生,针对上述问题该框架给出了一个非常完美的实现来极大程度上的给用户完美的体验

分片存储

分库分表简单的实现目前大部分框架已经都可以实现了,就是动态表名来实现分表下的简单存储,如果是分库下面的那么就使用动态数据源来切换实现,如果是分库加分表就用动态数据源加动态表名来实现，听上去是不是很完美,但是实际情况下你需要表写非常繁多的业务代码,并且会让整个开发精力全部集中在分库分表下,针对后期的维护也是非常麻烦的一件事。 但是分库分表的分片规则又是和具体业务耦合的所以合理的解耦分片路由是一件非常重要的事情。

插入

假设我们按订单id进行分表存储 

通过上述图片我们可以很清晰的了解到分片插入的执行原理,通过拦截执行sql分析对应的值计算出所属表名,然后改写表名进行插入。该实现方法有一个弊端就是如果插入数据是increment的自增类型,那么这种方法将不适合,因为自增主键只有在插入数据库后才会正真的被确定是什么值,可以通过拦截器设置自定义自增拨号器来实现伪自增，这样也可以实现“自增”列。

更新删除)

这边假设我们也是按照订单id进行分表更新

更新分片键

 一模一样的处理,将sql进行拦截后解析where和分片字段id然后计算后将结果发送到对应路由的表中进行执行。

那么如果我们没办法进行路由确定呢,如果我们使用created字段来更新的那么会发生生呢

###更新非分片键 

 为了得到正确的结果需要将每条sql进行改写分别发送到对应的表中,然后将各自表的执行结果进行聚合返回最终受影响行数

分片查询

众所周知分库分表的难点并不在如何存储数据到对应的db,也不在于如何更新指定实体数据,因为他们都可以通过分片键的计算来重新路由,可以让分片的操作降为单表操作,所以orm只需要支持动态表名那么以上所有功能都是支持的， 但是实际情况缺是如果orm或者中间件只支持到了这个级别那么对于稍微复杂一点的业务你必须要编写大量的业务代码来实现业务需要的查询,并且会浪费大量的重复工作和精力

单分片表查询

加下来我来讲解单分片表查询,其实原理和上面的insert一样 

 到这里为止其实都是ok的并没有什么问题.但是如果我们的本次查询需要跨分片呢比如跨两个分片那么应该如何处理

跨分片表查询

到这一步我们已经将对应的数据路由到对应的数据库了,那么我们应该如何获取自己想要的结果呢 

通过上图我们可以了解到在跨分片的聚合下我们可以分表通过对a,b两张表进行查询可以并行可以串行,最终将结果汇聚到同一个集合那么返回给用户端就是一个完整的数据包,并没有缺少任何数据

跨分片排序

基于上述分片聚合方式我们清晰的了解到如何可以进行跨分片下降数据获取到内存中，但是通过图中结果可以清晰的了解到返回的数据并不像我们预期的那样有序,那是因为各个节点下的所有数据都是仅遵循各自节点的数据库排序而不受其他节点分片影响。 那么如果我们对数据进行分片聚合+排序那么又会是什么样的场景呢

方案一内存排序

首先我们将执行sql分别路由到t_order_1和t_order_2两张表,并且执行order by id desc将其数据id大的排在前面这样可以保证单个Connection的ResultSet肯定是大的先被返回 所以在单个Connection下结果是正确的但是因为多个分片节点间没有交互所以当取到内存中后数据依然是乱的,所以这边需要对sql进行拦截获取排序字段并且将其在内存中的集合里面实现,这样我们就做到了和排序字段一样的返回结果

方案二流式排序

大部分orm到这边就为止了,毕竟已经实现了完美的节点处理,但是我们来看他需要消耗的性能事多少,假设我们分片命中2个节点,每个节点各自返回2条数据,我们对于整个ResultSet的遍历将是每个链接都是2那么就是4次，然后在内存中在进行排序如果性能差一点还需要多次所以这个是相对比较浪费性能的,因为如果我们有1000条数据返回那么内存中的排序是很高效的但是这个也是我们这次需要讲解的更加高效的排序处理流式排序 

相较于内存排序这种方式十分复杂并且繁琐,而且对于用户也很不好理解,但是如果你获取的数据是分页,那么内存排序进行获取结果将会变得非常危险,有可能导致内存数据过大从而导致程序崩溃

无order字段

到这边不要以为跨分片聚合已经结束了因为当你的sql查询order by了一个select不存在的字段,那么上述两种排序方式都将无法使用,因为程序获取到的结果集并没有排序字段,这个时候一般我们会改写sql让其select的时候必须要带上对应的order by字段这样就可以保证我们数据的正确返回

以下两个问题因为涉及到过多内容本章节无法呈现所以将会在下一章给出具体解决方案

跨分片分组

如果我们程序遇到了这个那么我们该如何处理呢

跨分片分页

业务中常常需要的跨分片分页我们该如何解决,easy-query又如何处理这种情况,如果跨的分片过多我们又该怎么办,

  • 如何解决深分页问题
  • 如何解决流式瀑布问题
  • 如何进行分页缓存高效获取问题

接下来将在下篇文章中一一解答近

最后

我这边将演示easy-query在本次分片理论中的实际应用 这次采用h2数据库作为演示

 

sql
 

复制代码
 

CREATE TABLE IF NOT EXISTS `t_order_0` ( `id` INTEGER PRIMARY KEY, `status` Integer, `created` VARCHAR(100) ); CREATE TABLE IF NOT EXISTS `t_order_1` ( `id` INTEGER PRIMARY KEY, `status` Integer, `created` VARCHAR(100) ); CREATE TABLE IF NOT EXISTS `t_order_2` ( `id` INTEGER PRIMARY KEY, `status` Integer, `created` VARCHAR(100) ); CREATE TABLE IF NOT EXISTS `t_order_3` ( `id` INTEGER PRIMARY KEY, `status` Integer, `created` VARCHAR(100) ); CREATE TABLE IF NOT EXISTS `t_order_4` ( `id` INTEGER PRIMARY KEY, `status` Integer, `created` VARCHAR(100) ); 
 

安装maven依赖
 

 

xml
 

复制代码
 

<dependency> <groupId>com.easy-query</groupId> <artifactId>sql-h2</artifactId> <version>0.9.32</version> <scope>compile</scope> </dependency> <dependency> <groupId>com.easy-query</groupId> <artifactId>sql-api4j</artifactId> <version>0.9.32</version> <scope>compile</scope> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <version>1.18.24</version> </dependency> <dependency> <groupId>com.h2database</groupId> <artifactId>h2</artifactId> <version>1.4.199</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-context-support</artifactId> <version>${spring.version}</version> </dependency> 
 

创建实体对象对应数据库
 

 

java
 

复制代码
 

@Data @Table(value = "t_order",shardingInitializer = H2OrderShardingInitializer.class) public class H2Order { @Column(primaryKey = true) @ShardingTableKey private Integer id; private Integer status; private String created; } // 分片初始化器 public class H2OrderShardingInitializer extends AbstractShardingTableModInitializer<H2Order> { @Override protected int mod() { return 5;//模5 } @Override protected int tailLength() { return 1;//表后缀长度1位 } } //分片路由规则 public class H2OrderRule extends AbstractModTableRule<H2Order> { @Override protected int mod() { return 5; } @Override protected int tailLength() { return 1; } } 
 

创建datasource和easyquery
 

 

java
 

复制代码
 

orderShardingDataSource=DataSourceFactory.getDataSource("dsorder","h2-dsorder.sql"); EasyQueryClient easyQueryClientOrder = EasyQueryBootstrapper.defaultBuilderConfiguration() .setDefaultDataSource(orderShardingDataSource) .optionConfigure(op -> { op.setMaxShardingQueryLimit(10); op.setDefaultDataSourceName("ds2020"); op.setDefaultDataSourceMergePoolSize(20); }) .build(); EasyQuery easyQueryOrder = new DefaultEasyQuery(easyQueryClientOrder); QueryRuntimeContext runtimeContext = easyQueryOrder.getRuntimeContext(); QueryConfiguration queryConfiguration = runtimeContext.getQueryConfiguration(); queryConfiguration.applyShardingInitializer(new H2OrderShardingInitializer());//添加分片初始化器 TableRouteManager tableRouteManager = runtimeContext.getTableRouteManager(); tableRouteManager.addRouteRule(new H2OrderRule());//添加分片路由规则 
 

插入代码
 

 

java
 

复制代码
 

ArrayList<H2Order> h2Orders = new ArrayList<>(); for (int i = 0; i < 100; i++) { H2Order h2Order = new H2Order(); h2Order.setId(i); h2Order.setStatus(i%3); h2Order.setCreated(String.valueOf(i)); h2Orders.add(h2Order); } easyQueryOrder.insertable(h2Orders).executeRows(); 
 

 

sql
 

复制代码
 

==> main, name:ds2020, Preparing: INSERT INTO t_order_3 (id,status,created) VALUES (?,?,?) ==> main, name:ds2020, Parameters: 0(Integer),0(Integer),0(String) <== main, name:ds2020, Total: 1 ==> main, name:ds2020, Preparing: INSERT INTO t_order_4 (id,status,created) VALUES (?,?,?) ==> main, name:ds2020, Parameters: 1(Integer),1(Integer),1(String) <== main, name:ds2020, Total: 1 ==> main, name:ds2020, Preparing: INSERT INTO t_order_0 (id,status,created) VALUES (?,?,?) ==> main, name:ds2020, Parameters: 2(Integer),2(Integer),2(String) <== main, name:ds2020, Total: 1 ==> main, name:ds2020, Preparing: INSERT INTO t_order_1 (id,status,created) VALUES (?,?,?) ==> main, name:ds2020, Parameters: 3(Integer),0(Integer),3(String) <== main, name:ds2020, Total: 1 ==> main, name:ds2020, Preparing: INSERT INTO t_order_2 (id,status,created) VALUES (?,?,?) ==> main, name:ds2020, Parameters: 4(Integer),1(Integer),4(String) .....省略 
 

 

java
 

复制代码
 

List<H2Order> list = easyQueryOrder.queryable(H2Order.class) .where(o -> o.in(H2Order::getId, Arrays.asList(1, 2, 6, 7))) .toList(); Assert.assertEquals(4,list.size()); 
 

 

sql
 

复制代码
 

==> SHARDING_EXECUTOR_2, name:ds2020, Preparing: SELECT id,status,created FROM t_order_3 WHERE id IN (?,?,?,?) ==> SHARDING_EXECUTOR_4, name:ds2020, Preparing: SELECT id,status,created FROM t_order_0 WHERE id IN (?,?,?,?) ==> SHARDING_EXECUTOR_3, name:ds2020, Preparing: SELECT id,status,created FROM t_order_4 WHERE id IN (?,?,?,?) ==> SHARDING_EXECUTOR_1, name:ds2020, Preparing: SELECT id,status,created FROM t_order_2 WHERE id IN (?,?,?,?) ==> SHARDING_EXECUTOR_4, name:ds2020, Parameters: 1(Integer),2(Integer),6(Integer),7(Integer) ==> SHARDING_EXECUTOR_5, name:ds2020, Preparing: SELECT id,status,created FROM t_order_1 WHERE id IN (?,?,?,?) ==> SHARDING_EXECUTOR_3, name:ds2020, Parameters: 1(Integer),2(Integer),6(Integer),7(Integer) ==> SHARDING_EXECUTOR_5, name:ds2020, Parameters: 1(Integer),2(Integer),6(Integer),7(Integer) ==> SHARDING_EXECUTOR_1, name:ds2020, Parameters: 1(Integer),2(Integer),6(Integer),7(Integer) ==> SHARDING_EXECUTOR_2, name:ds2020, Parameters: 1(Integer),2(Integer),6(Integer),7(Integer) <== SHARDING_EXECUTOR_2, name:ds2020, Time Elapsed: 0(ms) <== SHARDING_EXECUTOR_5, name:ds2020, Time Elapsed: 0(ms) <== SHARDING_EXECUTOR_1, name:ds2020, Time Elapsed: 1(ms) <== SHARDING_EXECUTOR_4, name:ds2020, Time Elapsed: 1(ms) <== SHARDING_EXECUTOR_3, name:ds2020, Time Elapsed: 1(ms) <== Total: 4 `` 通过上述sql展示我们可以清晰的看到哪个线程执行了哪个数据源(分片下会不一样),执行了什么sql,最终执行消耗多少时间参数是多少,一共返回多少条数据 分片排序 ```java List<H2Order> list = easyQueryOrder.queryable(H2Order.class) .where(o -> o.in(H2Order::getId, Arrays.asList(1, 2, 6, 7))) .orderByDesc(o->o.column(H2Order::getId)) .toList(); Assert.assertEquals(4,list.size()); Assert.assertEquals(7,(int)list.get(0).getId()); Assert.assertEquals(6,(int)list.get(1).getId()); Assert.assertEquals(2,(int)list.get(2).getId()); Assert.assertEquals(1,(int)list.get(3).getId()); 
 

 

sql
 

复制代码
 

==> SHARDING_EXECUTOR_1, name:ds2020, Preparing: SELECT id,status,created FROM t_order_1 WHERE id IN (?,?,?,?) ORDER BY id DESC ==> SHARDING_EXECUTOR_5, name:ds2020, Preparing: SELECT id,status,created FROM t_order_3 WHERE id IN (?,?,?,?) ORDER BY id DESC ==> SHARDING_EXECUTOR_4, name:ds2020, Preparing: SELECT id,status,created FROM t_order_2 WHERE id IN (?,?,?,?) ORDER BY id DESC ==> SHARDING_EXECUTOR_3, name:ds2020, Preparing: SELECT id,status,created FROM t_order_4 WHERE id IN (?,?,?,?) ORDER BY id DESC ==> SHARDING_EXECUTOR_5, name:ds2020, Parameters: 1(Integer),2(Integer),6(Integer),7(Integer) ==> SHARDING_EXECUTOR_1, name:ds2020, Parameters: 1(Integer),2(Integer),6(Integer),7(Integer) ==> SHARDING_EXECUTOR_4, name:ds2020, Parameters: 1(Integer),2(Integer),6(Integer),7(Integer) ==> SHARDING_EXECUTOR_2, name:ds2020, Preparing: SELECT id,status,created FROM t_order_0 WHERE id IN (?,?,?,?) ORDER BY id DESC ==> SHARDING_EXECUTOR_3, name:ds2020, Parameters: 1(Integer),2(Integer),6(Integer),7(Integer) ==> SHARDING_EXECUTOR_2, name:ds2020, Parameters: 1(Integer),2(Integer),6(Integer),7(Integer) <== SHARDING_EXECUTOR_1, name:ds2020, Time Elapsed: 0(ms) <== SHARDING_EXECUTOR_5, name:ds2020, Time Elapsed: 0(ms) <== SHARDING_EXECUTOR_4, name:ds2020, Time Elapsed: 0(ms) <== SHARDING_EXECUTOR_2, name:ds2020, Time Elapsed: 0(ms) <== SHARDING_EXECUTOR_3, name:ds2020, Time Elapsed: 0(ms) <== Total: 4 
 

最后的最后
 

附上源码地址,源码中有文档和对应的qq群,如果决定有用请点击star谢谢大家了
 

                

        

        

        

    

  


    

      

        

            

              
                
                  「已注销」
                
              
            

            

                关注
              
            

        

        

          
      

      









                



	

		

			

				
					
你如何理解mysql读写分离和分库分表？

				
			

			

				

					weixin_57907028的博客
				

				

					05-20
					
					698
					
				

			

		

		

			
				
前言
相信很多小伙伴们对于这两个概念已经比较熟悉了，这篇文章全程都是大白话的形式，希望能够给你带来不一样的感受。如果你之前不太了解这两个概念，那我建议你搞懂之后，可以把自己对于读写分离以及分库分表的理解讲给你的同事/朋友听听。
读写分离&分库分表
读写分离
何为读写分离？
见名思意，根据读写分离的名字，我们就可以知道：读写分离主要是为了将对数据库的读写操作分散到不同的数据库节点上。 这样的话，就能够小幅提升写性能，大幅提升读性能。
我简单画了一张图来帮助不太清楚读写分离的小伙伴理解。

一般情况下，

			
		

	



                

            
              



	

		

			

				
					
分库分表原理

				
			

			

				

					qq_38730338的博客
				

				

					11-10
					
					1037
					
				

			

		

		

			
				
分库分表其实分库和分表是两个概念，只不过通常分库与分表的操作会同时进行，以至于我们习惯性的将它们合在一起叫做分库分表。分库分表是为了解决由于库、表数据量过大，而导致数据库性能持续下降的问题。按照一定的规则，将原本数据量大的数据库拆分成多个单独的数据库，将原本数据量大的表拆分成若干个数据表，使得单一的库、表性能达到最优的效果（响应速度快），以此提升整体数据库性能。简单的回顾一下分库分表的基础知识，接下来的文章会配合实战项目介绍在分库分表中的各个功能点。

			
		

	



              


  
              

                


	

		

			

				
					
分库分表的原理和实施

				
			

			

				

					qq_40419080的博客
				

				

					03-25
					
					1394
					
				

			

		

		

			
				
文章目录一、分库分表背景1  什么是分库分表？2  为什么要分库分表？从性能上看从可用性上看二 、如何分库分表1  分库？分表？还是既分库又分表？2  如何选择我们自己的切分方案？3  如何对数据进行切分？（1）水平切分（2）垂直切分三 、分库分表之后带来的新问题1  分库分表后，如何让数据均匀散落在各个分库分表内？2  分库分表环境下，如何解决分库后主键ID的唯一性问题？3  分库分表环境下，事务问题怎么解决？4  分库分表后，历史数据如何平滑迁移？5  TDDL配置分库分表路由时的注意事项四 、分库分表

			
		

	





	

		

			

				
					
【数据库专题】一文搞懂数据库分库分表的原理

				
			

			

				

					weixin_42469135的博客
				

				

					07-06
					
					1828
					
				

			

		

		

			
				
是一种数据分片技术，主要分为垂直拆分和水平拆分。垂直拆分的意思是，把部分字段及其值挪到其它表或者其它数据库实例中；水平拆分的意思是，把部分记录挪到其它表或者其它数据库实例中；单表的存储总是有上限的，并且随着单表中数据量和字段数的增长，查询效率会越来越低，无法满足正常的查询时效要求。因此需要将数据进行分片，实现降低单表中数据行数、字段个数的目标，保持单表查询效率。以MySQL为例，单表存储的上限MySQL本身并没有做限制，它是和操作系统所允许的最大文件大小有关的，单表中字段数量越多，行数越多，那么就会使得单表

			
		

	



		

			
		



	

		

			

				
					
MySQL分区分库分表和分布式集群

				
			

			

				

					单线程boy
				

				

					04-29
					
					1203
					
				

			

		

		

			
				
数据量大就分表：减少每次查询的数据总量；并发高就分库：把并发请求分散到多个实例中去；分库分表的原理是通过一些 HASH算法 或者工具实现将一张数据表垂直或者水平进行物理切分。

			
		

	





	

		

			

				
					
分库分表会带来读扩散问题？怎么解决？

				
			

			

				

					JavaShark的博客
				

				

					07-02
					
					106
					
				

			

		

		

			
				
我们平时做项目开发。一开始，通常都先用一张数据表，而一般来说数据表写到2kw条数据之后，底层B+树的层级结构就可能会变高，不同层级的数据页一般都放在磁盘里不同的地方，换言之，磁盘IO就会增多，带来的便是查询性能变差。 如果对上面这句话有疑惑的话，可以去看下我之前写的文章。于是，当我们单表需要管理的数据变得越来越多，就不得不考虑数据库 分表 。而这里的分表，分为 水平分表和垂直分表 。垂直分表的原理比较简单，一般就是把某几列拆成一个新表，这样单行数据就会变小，B+树里的单个数据页（固定16kb）内能放入的行数

			
		

	





	

		

			

				
					
SpringBoot+ShardingJDBC实现读写分离、分库分表

				
			

			

				

					weixin_70730532的博客
				

				

					06-24
					
					688
					
				

			

		

		

			
				
最早是当当网内部使用的一款分库分表框架，到2017年的时候才开始对外开源，这几年在大量社区贡献者的不断迭代下，功能也逐渐完善，现已更名为 ，2020年4⽉16日正式成为 Apache 软件基金会的顶级项目。ShardingSphere-Jdbc定位为轻量级Java框架，在Java的Jdbc层提供的额外服务。它使用客户端直连数据库，以jar包形式提供服务，可理解为增强版的Jdbc驱动，完全兼容Jdbc和各种ORM框架。 随着版本的不断更迭 ShardingSphere 的核心功能也变得多元化起来。从最开始 S

			
		

	





	

		

			

				
					
你如何理解mysql读写分离和分库分表？，java实用教程第五版课后答案

				
			

			

				

					m0_64867802的博客
				

				

					12-09
					
					830
					
				

			

		

		

			
				
读写分离

何为读写分离？
见名思意，根据读写分离的名字，我们就可以知道：读写分离主要是为了将对数据库的读写操作分散到不同的数据库节点上。 这样的话，就能够小幅提升写性能，大幅提升读性能。
我简单画了一张图来帮助不太清楚读写分离的小伙伴理解。

一般情况下，我们都会选择一主多从，也就是一台主数据库负责写，其他的从数据库负责读。主库和从库之间会进行数据同步，以保证从库中数据的准确性。这样的架构实现起来比较简单，并且也符合系统的写少读多的特点。
读写分离会带来什么问题？如何解决？
读写分离对于提升数据库的并发非

			
		

	





	

		

			

				
					
MySQL 分库分表的实现原理及演示案例

				
			

			

				

					04-17
				

			

		

		

			
				
MySQL 分库分表的实现原理及演示案例，非常不错，可以看看

			
		

	





	

		

			

				
					
一文搞懂分库分表算法，通俗易懂（基因法、一致性 hash、时间维度）

					
最新发布

				
			

			

				

					风团团
				

				

					09-06
					
					4623
					
				

			

		

		

			
				
最近手上一个系统的访问速度有点慢，老早前用多线程优化过一些接口,将一些复杂 sql 改成单表查询，走内存处理，成功的将 一些 10 多秒的接口优化到 500 ms，但是数据量上来了单表查询效率也有点慢了，不得不考虑进行分库分表了，当然我这里只进行分表，没分库，问就是服务器资源紧张！并借此深入总结一下主流的几种分库还有分表算法。分库分表最繁琐的地方在于迁移数据和比对数据！！！！！！顾名思义将基因拼接到订单 id 上去，这里着重说一下雪花算法，先贴一下烂大街的雪花算法源码/**

			
		

	





	

		

			

				
					
数据库分库分表、读写分离的原理实现，使用场景

				
			

			

				

					jjc4261的博客
				

				

					03-09
					
					1021
					
				

			

		

		

			
				
1.分区对业务透明，分区只不过把存放数据的文件分成了许多小块，根据一定的规则把数据文件(MYD)和索引文件（MYI）进行了分割，分区后的表呢，还是一张表。2.分表当数据量大到一定程度的时候，都会导致处理性能的不足，这个时候就没有办法了，只能进行分表处理。也就是把数据库当中数据根据按照分库原则分到多个数据表当中，这样，就可以把大表变成多个小表，不同的分表中数据不重复，从而提高处理效率。3.分库。

			
		

	





	

		

			

				
					
mysql_分库、分表、分区详解

				
			

			

				

					chuige2013的博客
				

				

					01-21
					
					2055
					
				

			

		

		

			
				
在实际的应用中，绝大部分情况都是读远大于写。Mysql提供了读写分离的机制，所有的写操作都必须对应到Master，读操作可以在 Master和Slave机器上进行，Slave与Master的结构完全一样，一个Master可以有多个Slave，甚至Slave下还可以挂 Slave，通过此方式可以有效的提高DB集群的 QPS。

			
		

	





	

		

			

				
					
分库分表方案对比

				
			

			

				

					ice-wee的专栏
				

				

					10-17
					
					3094
					
				

			

		

		

			
				
房晓乐（葱头巴巴），PingCAP 资深解决方案架构师，前美团数据库专家、美团云 CDS 架构师、前搜狗、百度资深 DBA，擅长研究各种数据库架构，NewSQL 布道者。

原文链接：https://dbaplus.cn/news-11-1854-1.html

一、分库分表的背景

在谈论数据库架构演变和优化时，我们经常会听到分片、分库分表（Sharding）这样的关键词，在很长一段时间内，在各个公司、各中技术论坛里都很热衷谈论各种分片方案，尤其是互联网非常普及的 MySQL 数据库。但对笔者来说，分片、

			
		

	





	

		

			

				
					
分表分库学习（一）之“基本概念“

				
			

			

				

					依剑行走天下的博客
				

				

					12-24
					
					379
					
				

			

		

		

			
				
Mycat学习（一）之"Mycat基础"



			
		

	





	

		

			

				
					
MySQL 分库分表原理和详细实现过程，看完就懂了

				
			

			

				

					weixin_40648256的博客
				

				

					05-05
					
					5196
					
				

			

		

		

			
				
MySQL 分库分表是指将一张表的数据分散到多个库或多个表中，从而减轻单个数据库或表的压力，达到水平扩展的目的。MySQL 分库分表是一种常用的扩展数据库性能的方法，但是需要根据业务需求选择合适的分库分表策略，并且实现过程较为复杂，需要开发和维护成本。因此，在实际应用中需要权衡利弊，慎重选择。

			
		

	





	

		

			

				
					
分库分表技术及技术方案

				
			

			

				

					Terry的专栏
				

				

					04-26
					
					3408
					
				

			

		

		

			
				
分库分表

			
		

	





	

		

			

				
					
亿万级分库分表后如何进行跨表分页查询

				
			

			

				

					寒冰屋的专栏
				

				

					03-31
					
					2234
					
				

			

		

		

			
				
在常规的应用系统开发中，很少会涉及到需要对数据进行分库或者分表的操作，多数情况下，我们习惯使用ORM带来的便利，且使用连接查询是一种高效率的开发方式，就算涉及到分表的场景，很多时候也都可以使用ORM自带的分表规则来解决问题。

			
		

	





	

		

			

				
					
Sharding-JDBC深度解析：数据库分库分表解决方案

				
			

			

				

					
				

			

		

		

			
				
总结来说，分库分表中间件Sharding-JDBC是应对大数据量和高并发场景的一种有效解决方案，通过水平拆分和分库策略，可以显著提高数据库的处理能力和响应速度。同时，Sharding-JDBC作为一个开源框架，为企业提供了灵活...

			
		

	



              




          




        



    





    



      

      

        
      

      





	

		评论	
	

	
	




  

    

      添加红包
      
    

    

      

        
        

          
          
        

        
请填写红包祝福语或标题

      

      

        
        

          
          个
        

        
红包个数最小为10个

      

      

        
        

          
          元
        

        
红包金额最低5元

      

      

        
        

          当前余额3.43元
          前往充值 >
        

      

      

        

          需支付：10.00元
        

        
        
      

    

  





  

    
    
  

  

    
    
  








  

    

      

        

          

            
            
成就一亿技术人!

          

          

        

        

          

          

            领取后你会自动成为博主和红包主的粉丝
            规则
          

        

      

      

        

          

            
              
            
            

              
hope_wisdom
 发出的红包
            

          

        

        

          

          

          

        

      

    

    

  



      
      

      
实付元

      
使用余额支付

      

        

          

            
            点击重新获取
          

        

        
扫码支付

      

      

        
          
            
          
          
        
      

      

        
        钱包余额
          0
          

            
            

              

                
抵扣说明：

                
 1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
 2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

              

            

          

      

      余额充值