标签：style blog http io color ar os 使用 sp
原文:曲演杂坛--一条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秒删除一次)，这种问题就不会出现。
--=============================
依旧是妹子：
标签：style blog http io color ar os 使用 sp
原文地址：http://www.cnblogs.com/lonelyxmas/p/4090884.html
