码迷,mamicode.com
首页 > 其他好文 > 详细

曲演杂坛--一条DELETE引发的思考

时间:2014-11-01 17:32:15      阅读:171      评论:0      收藏:0      [点我收藏+]

标签:style   blog   http   io   color   ar   使用   for   sp   

场景介绍:

我们有一张表,专门用来生成自增ID供业务使用,表结构如下:

CREATE TABLE TB001
(
    ID INT IDENTITY(1,1) PRIMARY KEY,
    DT DATETIME
)

每次业务想要获取一个新ID,就执行以下SQL:

INSERT INTO TB001(DT)
SELECT GETDATE();
SELECT @@IDENTITY

由于这些数据只需保留最近一天的数据,因此建立一个SQL作业来定期删除数据,删除脚本很简单:

DELETE TOP(10000) FROM TB001
WHERE DT<GETDATE()-1

作业每10秒运行一次,每天运行2个小时,最大能删除数据720W数据。

问题:

由于前台页面没有防刷机制,有恶意用户使用程序攻击,造成每天数据量暴增近1亿(是不是我也可以出去吹下NB!!!),当前作业无法删除这么庞大的数据,得进行调整.

 

解决思路:

在保证程序不修改的前提下,我们首先想到的办法是:

1:提高单次删除的数量,会造成锁阻塞,阻塞严重就会影响到业务,这无法接受;

2:延长整个作业运行周期,研发人员担心影响白天正常业务,要求作业只能夜里低峰区进行

3:提高删除频率,可以考虑,但具体频率需要测试

 

由于方法2只能少量的增加,因此我们集中在方法3的测试上,由于SQL Agent Job的最小周期是10秒,因此在作业调用的脚本上修改,每次作业调用多条删除语句,删除语句中间使用WAITFOR来间歇执行:

DELETE FROM TB001
WHERE DT<GETDATE()-1
WAITFOR DELAY 0:0:05DELETE FROM TB001
WHERE DT<GETDATE()-1

测试运行时,发现对业务影响不大,因此就上线修改。

结果半夜作业运行后,研发立即收到报警,程序访问延时严重,到服务器上一查,锁等待超过500000多毫秒,sys.dm_exec_requests中显示有300多回话等待同一个锁资源,停掉作业后程序立马回复正常。

让我们来测试下这是为啥呢?

首先准备测试数据

CREATE TABLE TB001
(
    ID INT IDENTITY(1,1) PRIMARY KEY,
    DT DATETIME
)
GO
INSERT INTO TB001(DT)
SELECT GETDATE()-1 FROM SYS.all_columns
GO
INSERT INTO TB001
SELECT GETDATE()-1 FROM TB001
GO 13

然后尝试删除数据

BEGIN TRAN
DELETE TOP(10000)  FROM TB001
WHERE DT<GETDATE()-1

查看锁情况:

--上面事务的回话ID为55
sp_lock 55

bubuko.com,布布扣

单次删除数据太大,造成表锁,阻塞程序插入数据,解决办法:调整单次删除数量

PS: SQL SERVER会在行集上获得5000个锁时尝试锁升级,同时也会在内存压力下尝试锁升级。

于是我们只能尝试更高的删除频率和更小的删除批量,于是将删除代码修改如下:

DECLARE @ID INT
SET @ID=0
WHILE(@ID<100)
BEGIN

DELETE TOP(100)  FROM TB001
WHERE DT<GETDATE()-1
WAITFOR DELAY 0:0:00:400 SET @ID=@ID+1 END

PS: 删除100行只是一个尝试值,应该没有一个最优的删除行数,牛逼的解释是设置该值需考虑:删除需要扫描多少页面/执行多次时间/表上索引数量/写入多少日志/锁与阻塞等等,不装逼的解释就是多测试直到达到满足需求的值就好。
假设平均删除90行数据会写60k的日志,你删除100行导致需要两次物理写,这是何必呢?

 

使用修改后的版本测试了下,速度飞快,人生如此美好,哪还等啥,更新到生产服务器上,让暴风雨来得更猛烈些吧!!!

 

果然,这不是人生的终点,悲剧出现了,执行不稳定,本来40秒能执行完的SQL,有时候需要4分钟才能完成,这不科学啊,我都测试好几遍的呢!!!

 

细细看看语句,不怪别人,自己写的SQL垃圾,没办法,在看一遍代码:

DELETE TOP(100)  FROM TB001
WHERE DT<GETDATE()-1

这是按照业务逻辑写的,没有问题,但是的但是,DT上没有索引,由于表中DT和ID都是顺序增长的,按照主键ID的升序扫描,排在最前面的ID最小,其插入时间也最早,也是我们删除的目标,因此只需要几次逻辑读便可以轻松找到满足条件的100行数据,因此消耗也最小,但是理想很丰满,现实很骨感,

在频繁地运行DELETE语句后,使用SET STATISTICS IO ON来查看,同样的执行计划:

bubuko.com,布布扣

但是造成的逻辑IO完全不一样,从4次到几千次,此现象在高频率删除下尤其明显(测试时可以连续运行10000次删除查看)

 

尝试其他写法,强制走ID索引扫描:

DECLARE @ID INT
SET @ID=0

WHILE(@ID<10000)
BEGIN

;WITH T1 AS(
SELECT TOP(100)* FROM TB001
WHERE DT<GETDATE()-1
ORDER BY ID
)
DELETE FROM T1


SET @ID=@ID+1
END

测试发现依然是同样问题,难道无解么?

再次研究业务发现,我们可以查出一个要要删除的最大ID,然后删除小于这个ID的数据,而且可以避免一个潜在风险,由于DT没有索引,当一天前的数据被清除后,如果作业继续运行,要查找满足条件的100行数据来进行删除,便会对表进行一次全表扫描,消耗更庞大数量的逻辑IO。

DECLARE @MaxID INT

SELECT @MaxID=MAX(ID) 
FROM TB001 WITH(NOLOCK)
WHERE DT<GETDATE()

DECLARE @ID INT
SET @ID=0

WHILE(@ID<10000)
BEGIN

;WITH T1 AS(
SELECT TOP(100)* FROM TB001
WHERE ID<@MaxID
ORDER BY ID
)
DELETE FROM T1


SET @ID=@ID+1
END

从逻辑IO上看,性能没有明显提升,但是从CPU的角度来看,CPU的使用明显降低,猜测有两方面原因:
1:日期比较消耗要大于INT(日期类似浮点数的存储,处理需要消耗额外的CPU资源)

2:由于ID索引排序的原因,可能不需要对页的所有数据逐行比较来判断这些数据是否满足条件(个人猜测,请勿当真)

 

由于ID是自增连续的,虽然可能有因为事务回滚或DBA干预导致不连续的情况,但这不是重点,重点是我们不一定要每次都删除100行数据,因此我们可以按ID来进行区间删除,抛弃TOP的方式:

DECLARE @MaxID INT
DECLARE @MinID INT

SELECT @MaxID=MAX(ID),@MinID=MIN(ID)
FROM TB001 WITH(NOLOCK)
WHERE DT<GETDATE()-1

DECLARE @ID INT
SET @ID=0

WHILE(@ID<10000)
BEGIN

DELETE  FROM TB001
WHERE ID>=@MinID+@ID*100
AND ID<@MinID+(@ID+1)*100
AND ID<@MaxID


SET @ID=@ID+1
END

测试发现,每次删除的逻辑IO都很稳定且消耗很低,这才是最完美的东东啊!!

--=======================================================

总结:

本来看似一个很简单的SQL,需要考虑很多方面,各种折腾,各种困惑,多看点基础原理的资料,没有坏处;大胆猜测,谨慎论证,多测试是验证推断的唯一办法;

 

提点额外话:

1. 关于业务:在很多时候,DBA不了解业务就进行优化,是很糟糕的事情,而且很多优化的最佳地方是程序而不是数据库,敢于否定开发人员所谓的“业务需求”也是DBA的一项必备技能。有一次优化发现,开发对上千万数据排序分页,问询开发得到答复“用户没有输入过滤条件”,难道用户不输入就不能设置点默认条件么?如果用户查询最新记录,我们可以默认值查询最近三天的数据。

2. 关于场景:有一些初学者,很期望获得一些绝对性的推论,而不考虑场景的影响,且缺乏测试,武断地下结论,这同样是很可怕的事情,适合你场景的解决方案,才是最佳的解决方案。

 

遗留问题:

1. 针对本文提到的业务场景,还有一些其他解决方案,比如分区方式,定期进行分区切换再删除数据,又比如使用SQL SERVER 2012中新增的“序列”;

2. 猜测上面所提到的问题根源是SQL Server删除行的实现方式,在删除时仅标示数据行被删除而不是真正的从页面删除,在高频率不间断地删除过程中,这些数据页没有被及时回收删除掉,

SQL Server扫描了“本该”删除的数据页,造成逻辑读较高;而使用ID的区间范围查找,可以避免扫描到这些数据页,直接移动到真正需要访问的数据页;当删除频率较低时(比如3秒删除一次),这种问题就不会出现。

--=============================

依旧是妹子:

bubuko.com,布布扣

bubuko.com,布布扣

 

曲演杂坛--一条DELETE引发的思考

标签:style   blog   http   io   color   ar   使用   for   sp   

原文地址:http://www.cnblogs.com/TeyGao/p/4067294.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!