走向DBA[MSSQL篇] 针对大表 设计高效的存储过程【原理篇】 附最差性能sql语句进化过程客串

简介: 原文:走向DBA[MSSQL篇] 针对大表 设计高效的存储过程【原理篇】 附最差性能sql语句进化过程客串测试的结果在此处 本篇详解一下原理 设计背景 由于历史原因,线上库环境数据量及其庞大,很多千万级以上甚至过亿的表。
原文: 走向DBA[MSSQL篇] 针对大表 设计高效的存储过程【原理篇】 附最差性能sql语句进化过程客串

测试的结果在此处 本篇详解一下原理


设计背景

由于历史原因,线上库环境数据量及其庞大,很多千万级以上甚至过亿的表。目标是让N张互相关联的表 按照一张源表为基表,数据搬移归档 这里我们举例N为50 每张表数据5000W


最差性能sql进化客串

2表KeyName 字段意义 名称等相同 从bug01 表中取出前500条不在bug02 表中的数据

最差性能:

SELECT TOP 500 a.KeyName FROM bug01 a LEFT JOIN bug02 b on a.KeyName = b.KeyName 
WHERE (a.KeyName not in (select distinct b.KeyName From bug02)) 
ORDER BY a.KeyName asc

 进化体在篇尾揭晓


详细设计

问题点:性能 安全 容错

流程篇 为何如此设计 在下文中会解释

step.1 源表数据过滤

这部分没什么好说的 根据大家自己的业务场景设定不同的过滤规则

step.2 源表数据副本

程序的入口点肯定是源表了,扩展表中的内容都是以源表为Key来展开。那么这个展开的过程如何来做。

首先确定一些概念,这50表中的层级关系如何。可能直接和源表key键关联的表只有10张。

例如我统计市内所有图书馆详细信息,那么我们以图书馆为源表。图书馆关联书架、地址、会员信息。那么这3中信息我们分为一级别表。

书架关联图书类别,地址关联街道信息,会员关联用户借阅信息,那么后面3者我们继续分为二级表,......按照场景继续扩展。

方案1:使用游标 循环源表 根据源表key值 处理和key相关的数据  假设我们没批次处理500跳源表数据

    也就是根据图书馆ID,遍历所有节点。假设我们不分二级三级表,都是一级表 我们的insert操作次数是500*50。select操作同数据量

    这个给谁肯定都不大乐意,而且如果再遍历2级表3级更难想象。

方案2:对源表key数据进行集合,存进变量,然后用in表达式。貌似可行。直接减少到1/500的操作次数。但是这里有个最恐怖的问题。

    变量都有长度,例如varchar 最大长度不能超过65535。

方案3:将源表Key做成一个查询过滤池(相对于一级表 底层的sql where条件语句 下面会详细介绍一下) 相对于第二种方案,我们这种似乎又将操作数提高了。

    不考虑层级的情况下,insert操作50。select操作50*2可以接受.

方案3扩展: 对于一张大表来说 操作50次也不是什么可以乐观的数字,并且这个50还有可能变成500,5000,50000。

      更有一个问题就是,当你操作这500条的时候,可能会有数据干扰,你1秒前取得的这500条可不一定是1秒后的内容。

      所以采取临时表策略。

       CREATE TABLE #p
	(      
		OrderID varchar(50), 
		primary key (OrderID)      
	);
	SET @temp_text = 'INSERT INTO #p '+@KeyText
	--PRINT @temp_text
	EXEC (@temp_text)	
	
	SET @KeyText = 'SELECT OrderID FROM #p'
	--如果一级表关联的操作次数比较多那么可以访源表操作 以临时表取代物理表
	SET @SubKeyText = 'select 一级表_A_被关联键 From 一级表_A with(nolock) where 一级表_A_关联源表键 in (' + @KeyText+')'
	
	CREATE TABLE #q
	(      
		OrderID varchar(50), 
		primary key (OrderID)      
	);
	SET @temp_text = 'INSERT INTO #q '+@SubKeyText
	EXEC (@temp_text)	
	SET @SubKeyText ='SELECT OrderID FROM #q'
	
	--如果一级表关联的操作次数不多可以直接生成数据过滤池
	SET @SubKeyTextforA ='select 一级表_B_被二级关联键 From 一级表_B with(nolock) where 一级表_B_关联源表键 in (' + @KeyText+')'
	SET @SubKeyTextforB ='select 一级表_C_被二级关联键 From 一级表_C with(nolock) where 一级表_C_关联源表键 in (' + @KeyText+')'
	
	--如果存在更多层操作在此处可以继续关联资源过滤池 Demo只做到三层
SET @THKeyTextforA ='select 二级表_A_被三级关联键 From 二级表_A with(nolock) where 二级表_A_关联一级表键 in (' + @SubKeyTextforA+')'

 --step.3 分表归档操作

这个环节的问题是安全 事务如何控制 事务的大小如何衡量 如何容错 以及如何将程序做得可扩展 可维护

大家根据业务场景 区分自己的批次范围 拿虫子这篇demo来说 50张千万级大表 如果是批次5000条以上 事务要放在内层处理 如果是5000条以下 可以放在最外层

事务的大小直接影响性能的波动

容错的方案大家也可以自己设计 虫子的程序员采用第三类表 异常表来重置 失败了就插入 下一个批次直接就过滤

--将错误的批次订单号入异常表
	Insert into 异常表(@ExTable) SELECT OrderID FROM #p
--@ExTable用来存放异常数据 如果当期批次出错 则将本次批次订单信息入库@ExTable下一批次则过滤这些数据再执行
	SET @KeyText = 'SELECT TOP '+CAST(@SynSize AS VARCHAR(10))+' '+@Base_Key+' FROM +
'+@BaseTable+'+ WHERE '+@Base_Key+' not in (select '+@Base_Key+' From '+@ExTable+') ' 

 如何让程序变的漂亮 可维护

我们在存储过程中同样可以使用面试对象的思想 只不过存储过程没有类这样的概念给我们 那么我们不妨自己设计

用什么 还是临时表

--一级 直接关联源表主键 或为二级被关联的主表
	INSERT INTO #k VALUES ('一级表_A',@Base_Key,@KeyText,'')					--一级表_A
	INSERT INTO #k VALUES ('一级表_B',@Base_Key,@KeyText,'')					--一级表_B
	INSERT INTO #k VALUES ('一级表_C',@Base_Key,@KeyText,'')					--一级表_C
--二级 规则间接关联
	--@SubKeyText相关
	INSERT INTO #k VALUES ('二级表_A','二级表_A_关联一级键',@SubKeyText,'')				--二级表_A
	INSERT INTO #k VALUES ('二级表_B','二级表_B_关联一级键',@SubKeyText,'')				--二级表_B	
	INSERT INTO #k VALUES ('二级表_C','二级表_C_关联一级键',@SubKeyText,'')				--二级表_C
--特殊处理 
	--自定义操作
	INSERT INTO #k VALUES ('特殊表','特殊表关联键','自定义数据过滤方式','')			
	
	--其他 自增列处理
	--修改订单,及其取消修改订单状态历史表
	INSERT INTO #k VALUES ('自增表',@Base_Key,@KeyText,'自定义字段')

 --step.4 处理细节 

 游标循环临时表 针对每一张表操作一次

DECLARE CUR_ORDERHEDER INSENSITIVE CURSOR FOR SELECT TableName,KeyName,temptext,colname FROM #k 
	OPEN CUR_ORDERHEDER
	FETCH CUR_ORDERHEDER INTO @Cur_Table,@Cur_Key,@Cur_W,@Cur_K
		WHILE @@FETCH_STATUS = 0
			BEGIN				
				 EXECUTE P_Task_Sub_Synchronization
				 @OutParam  = @OutParam OUT, @OutMessage = @OutMessage OUT,
			@KeyText =  @Cur_W,@Table= @Cur_Table,@Extension=@Extension,@IsDelSource=@IsDelSource,@KeyName=@Cur_Key,@ColName=@Cur_K
				 --SET @OutMessage = @OutMessage+@OutMessage
				 --PRINT @OutMessage
				 IF @OutParam <> 0  
					 BEGIN
						SET @OutMessage = @OutMessage + @Cur_Table +'操作失败'						
						ROLLBACK TRAN
						--将错误的批次订单号入异常表
						Insert into 异常表(@ExTable) SELECT OrderID FROM #p
						DROP TABLE #k 
						DROP TABLE #p 
						DROP TABLE #q
						RETURN
					 END	
				 FETCH CUR_ORDERHEDER INTO @Cur_Table,@Cur_Key,@Cur_W,@Cur_K
			END
	ClOSE CUR_ORDERHEDER
	DEALLOCATE CUR_ORDERHEDER		

 --step.5 资源释放

 --step.6 流程处理

 

这2个部分就不详细说了  


最差性能sql进化过程

step.1 not in了 就别再distinc了 distinc和not in都是臭名昭著的角色 not in后+dinstinc画蛇添足而已

改后sql:

SELECT TOP 500 a.KeyName FROM bug01 a LEFT JOIN bug02 b on a.KeyName = b.KeyName
WHERE (a.KeyName not in (select  b.KeyName From bug02))
ORDER BY a.KeyName asc

step.2 别名 别小看别名 用图来说话 原sql计划

改后sql:

 SELECT TOP 500 a.KeyName FROM bug01 a LEFT JOIN bug02 b on a.KeyName = b.KeyName
WHERE (a.KeyName not in (select  c.KeyName From bug02 c))
ORDER BY a.KeyName asc

step.3 何必要用外联 直接过滤不就得了 嘿嘿

改后sql:

SELECT TOP 500 a.KeyName FROM bug01 a
WHERE (a.KeyName not in (select  c.KeyName From bug02 c))
ORDER BY a.KeyName asc

step.4 根据luofer同学的建议 再进化一次 直接EXCEPT

SELECT TOP 500 a.KeyName FROM bug01 a except
SELECT b.KeyName from bug02 b


本篇就讲到此处 欢迎大家讨论

目录
相关文章
|
2月前
|
SQL 安全 UED
通义灵码在DBA日常SQL优化中的使用分享
通义灵码在DBA日常SQL优化中的使用分享
157 1
通义灵码在DBA日常SQL优化中的使用分享
|
7天前
|
SQL Java 数据库连接
如何在 Java 代码中使用 JSqlParser 解析复杂的 SQL 语句?
大家好,我是 V 哥。JSqlParser 是一个用于解析 SQL 语句的 Java 库,可将 SQL 解析为 Java 对象树,支持多种 SQL 类型(如 `SELECT`、`INSERT` 等)。它适用于 SQL 分析、修改、生成和验证等场景。通过 Maven 或 Gradle 安装后,可以方便地在 Java 代码中使用。
99 11
|
2月前
|
SQL 数据库 UED
SQL性能提升秘籍:5步优化法与10个实战案例
在数据库管理和应用开发中,SQL查询的性能优化至关重要。高效的SQL查询不仅可以提高应用的响应速度,还能降低服务器负载,提升用户体验。本文将分享SQL优化的五大步骤和十个实战案例,帮助构建高效、稳定的数据库应用。
138 3
|
2月前
|
SQL IDE 数据库连接
IntelliJ IDEA处理大文件SQL:性能优势解析
在数据库开发和管理工作中,执行大型SQL文件是一个常见的任务。传统的数据库管理工具如Navicat在处理大型SQL文件时可能会遇到性能瓶颈。而IntelliJ IDEA,作为一个强大的集成开发环境,提供了一些高级功能,使其在执行大文件SQL时表现出色。本文将探讨IntelliJ IDEA在处理大文件SQL时的性能优势,并与Navicat进行比较。
43 4
|
2月前
|
SQL 存储 缓存
如何优化SQL查询性能?
【10月更文挑战第28天】如何优化SQL查询性能?
213 10
|
2月前
|
SQL 关系型数据库 MySQL
惊呆:where 1=1 可能严重影响性能,差了10多倍,快去排查你的 sql
老架构师尼恩在读者交流群中分享了关于MySQL中“where 1=1”条件的性能影响及其解决方案。该条件在动态SQL中常用,但可能在无真实条件时导致全表扫描,严重影响性能。尼恩建议通过其他条件或SQL子句命中索引,或使用MyBatis的`&lt;where&gt;`标签来避免性能问题。他还提供了详细的执行计划分析和优化建议,帮助大家在面试中展示深厚的技术功底,赢得面试官的青睐。更多内容可参考《尼恩Java面试宝典PDF》。
|
2月前
|
SQL 缓存 监控
SQL性能提升指南:五大优化策略与十个实战案例
在数据库性能优化的世界里,SQL优化是提升查询效率的关键。一个高效的SQL查询可以显著减少数据库的负载,提高应用响应速度,甚至影响整个系统的稳定性和扩展性。本文将介绍SQL优化的五大步骤,并结合十个实战案例,为你提供一份详尽的性能提升指南。
69 0
|
3月前
|
SQL 监控 数据库
慢SQL对数据库写入性能的影响及优化技巧
在数据库管理系统中,慢SQL(即执行缓慢的SQL语句)不仅会影响查询性能,还可能对数据库的写入性能产生显著的不利影响
|
3月前
|
SQL 关系型数据库 PostgreSQL
遇到SQL 子查询性能很差?其实可以这样优化
遇到SQL 子查询性能很差?其实可以这样优化
174 2
|
3月前
|
SQL Oracle 关系型数据库
Oracle SQL:了解执行计划和性能调优
Oracle SQL:了解执行计划和性能调优
106 1