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

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

场景介绍：

我们有一张表，专门用来生成自增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:05'
DELETE 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

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

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来查看，同样的执行计划:

但是造成的逻辑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秒删除一次)，这种问题就不会出现。

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

依旧是妹子：