SQL Server 2008 删除大量数据

一、写在前面 - 想说爱你不容易

　　为了升级数据库至SQL Server 2008 R2，拿了一台现有的PC做测试，数据库从正式库Restore(3个数据库大小夸张地达到100G+)，而机器内存只有可怜的4G，不仅要承担DB Server角色，同时也要作为Web Server，可想而知这台机器的命运是及其惨烈的，只要MS SQL Server一启动，内存使用率立马飙升至99%。没办法，只能升内存，两根8G共16G的内存换上，结果还是一样，内存瞬间被秒杀（CPU利用率在0%徘徊）。由于是PC机，内存插槽共俩，目前市面上最大的单根内存为16G（价格1K+），就算买回来估计内存还是不够（卧槽，PC机伤不起啊），看样子别无它法 -- 删数据！！！

　　删除数据 - 说的容易， 不就是DELETE吗？靠，如果真这么干，我XXX估计能“知道上海凌晨4点的样子”（KB，Sorry，谁让我是XXX的Programmer，哥在这方面绝对比你牛X），而且估计会暴库（磁盘空间不足，产生的日志文件太大了）。

二、沙场点兵 - 众里寻他千百度

　　为了更好地阐述我所遇到的困难和问题，有必要做一些必要的测试和说明，同时这也是对如何解决问题的一种探究。因为毕竟这个问题的根本是如何来更好更快的操作数据，说到底就是DELETE、UPDATE、INSERT、TRUNCATE、DROP等的优化操作组合，我们的目的就是找出最优最快最好的方法。为了便于测试，准备了一张测试表tmp_employee

--Create table tmp_employee
CREATE TABLE [dbo].[tmp_employee] (
    [EmployeeNo] INT PRIMARY KEY,
    [EmployeeName] [nvarchar](50) NULL,
    [CreateUser] [nvarchar](50) NULL,
    [CreateDatetime] [datetime] NULL
);

1. 数据插入PK

1.1. 循环插入，执行时间为38026毫秒

--循环插入
SET STATISTICS TIME ON;
DECLARE @Index INT = 1;
DECLARE @Timer DATETIME = GETDATE();

WHILE @Index <= 100000
BEGIN
    INSERT [dbo].[tmp_employee](EmployeeNo, EmployeeName, CreateUser, CreateDatetime) VALUES(@Index, ‘Employee_‘ + CAST(@Index AS CHAR(6)), ‘system‘, GETDATE());
    SET @Index = @Index + 1;
END

SELECT DATEDIFF(MS, @Timer, GETDATE()) AS [执行时间(毫秒)];
SET STATISTICS TIME OFF;

1.2.   事务循环插入，执行时间为6640毫秒

--事务循环
BEGIN TRAN;
SET STATISTICS TIME ON;
DECLARE @Index INT = 1;
DECLARE @Timer DATETIME = GETDATE();

WHILE @Index <= 100000
BEGIN
    INSERT [dbo].[tmp_employee](EmployeeNo, EmployeeName, CreateUser, CreateDatetime) VALUES(@Index, ‘Employee_‘ + CAST(@Index AS CHAR(6)), ‘system‘, GETDATE());
    SET @Index = @Index + 1;
END

SELECT DATEDIFF(MS, @Timer, GETDATE()) AS [执行时间(毫秒)];
SET STATISTICS TIME OFF;

COMMIT;

1.3.   批量插入，执行时间为220毫秒

SET STATISTICS TIME ON;
DECLARE @Timer DATETIME = GETDATE();

INSERT [dbo].[tmp_employee](EmployeeNo, EmployeeName, CreateUser, CreateDatetime)
SELECT TOP(100000) EmployeeNo = ROW_NUMBER() OVER (ORDER BY C1.[OBJECT_ID]), ‘Employee_‘, ‘system‘, GETDATE()
FROM SYS.COLUMNS AS C1 CROSS JOIN SYS.COLUMNS AS C2
ORDER BY C1.[OBJECT_ID]

SELECT DATEDIFF(MS, @Timer, GETDATE()) AS [执行时间(毫秒)];
SET STATISTICS TIME OFF;

1.4.   CTE插入，执行时间也为220毫秒

SET STATISTICS TIME ON;
DECLARE @Timer DATETIME = GETDATE();

;WITH CTE(EmployeeNo, EmployeeName, CreateUser, CreateDatetime) AS(
    SELECT TOP(100000) EmployeeNo = ROW_NUMBER() OVER (ORDER BY C1.[OBJECT_ID]), ‘Employee_‘, ‘system‘, GETDATE()
    FROM SYS.COLUMNS AS C1 CROSS JOIN SYS.COLUMNS AS C2
    ORDER BY C1.[OBJECT_ID]
)
INSERT [dbo].[tmp_employee] SELECT EmployeeNo, EmployeeName, CreateUser, CreateDatetime FROM CTE;

SELECT DATEDIFF(MS, @Timer, GETDATE()) AS [执行时间(毫秒)];
SET STATISTICS TIME OFF;

小结：

• 按执行时间，效率依次为：CTE和批量插入效率相当，速度最快，事务插入次之，单循环插入速度最慢；
• 单循环插入速度最慢是由于INSERT每次都有日志，事务插入大大减少了写入日志次数，批量插入只有一次日志，CTE的基础是CLR，善用速度是最快的。

2.  数据删除PK

2.1.   循环删除，执行时间为1240毫秒

SET STATISTICS TIME ON;
DECLARE @Timer DATETIME = GETDATE();

DELETE FROM [dbo].[tmp_employee];

SELECT DATEDIFF(MS, @Timer, GETDATE()) AS [执行时间(毫秒)];
SET STATISTICS TIME OFF;

2.2.  批量删除，执行时间为106毫秒

SET STATISTICS TIME ON;
DECLARE @Timer DATETIME = GETDATE();

SET ROWCOUNT 100000;

WHILE 1 = 1
BEGIN
    BEGIN TRAN
    DELETE FROM [dbo].[tmp_employee];
    COMMIT
    IF @@ROWCOUNT = 0
        BREAK;
END

SET ROWCOUNT 0;

SELECT DATEDIFF(MS, @Timer, GETDATE()) AS [执行时间(毫秒)];
SET STATISTICS TIME OFF;

2.3.  TRUNCATE删除，执行时间为0毫秒

SET STATISTICS TIME ON;
DECLARE @Timer DATETIME = GETDATE();

TRUNCATE TABLE [dbo].[tmp_employee];

SELECT DATEDIFF(MS, @Timer, GETDATE()) AS [执行时间(毫秒)];
SET STATISTICS TIME OFF;

 小结：

• TRUNCATE太快了，清除10W数据一点没压力，批量删除次之，最后的DELTE太慢了；
• TRUNCATE快是因为它属于DDL语句，只会产生极少的日志，普通的DELETE不仅会产生日志，而且会锁记录。

三、磨刀霍霍 - 犹抱琵琶半遮面

　　由上面的第二点我们知道，插入最快和删除最快的方式分别是批量插入和TRUNCATE，所以为了达到删除大数据的目的，我们也将采用这两种方式的组合，其中心思想是先把需要保留的数据存放之新表中，然后TRUNCATE原表中的数据，最后再批量把数据插回去，当然实现方式也可以随便变通。

1. 保留需要的数据之新表中->TRUNCATE原表数据->还原之前保留的数据之原表中

　　脚本类似如下

SELECT * INTO #keep FROM Original WHERE CreateDate > ‘2011-12-31‘
TRUNCATE TABLE Original
INSERT Original SELECT * FROM #keep

　　第一条语句会把所有要保留的数据先存放至表#keep中（表#keep无需手工创建，由SELECT INTO生效），#keep会Copy原始表Original的表结构。PS：如果你只想创建表结构，但不拷贝数据，则对应的脚本如下

SELECT * INTO #keep FROM Original WHERE 1 = 2

　　第二条语句用于清除整个表中数据，产生的日志文件基本可以忽略；第三条语句用于还原保留数据。

几点说明：

• 你可以不用SELECT INTO，自己通过写脚本（或拷贝现有表）来创建#keep，但是后者有一个弊端，即无法通过SQL脚本来获得对应的表生成Script（我的意思是和原有表完全一致的脚本，即基本列，属性，索引，约束等），而且当要操作的表比较多时，估计你肯定会抓狂；
• 既然第一点欠妥，那考虑新建一个同样的数据库怎么样？既可以使用现有脚本，而且生成的数据库基本一致，但是我告诉你最好别这么做，因为第一要跨库，第二，你得准备足够的磁盘空间。

2. 新建表结构->批量插入需要保留的数据->DROP原表->重命名新表为原表

　　CREATE TABLE #keep AS (xxx) xxx -- 使用上面提到的方法（使用既有表的创建脚本），但是不能够保证完全一致；

　　INSERT #keep SELECT * FROM Original where clause

　　DROP TBALE Original

　　EXEC SP_RENAME ‘#keep‘,‘Original‘

　　这种方式比第一种方法略快点，因为省略了数据还原（即最后一步的数据恢复），但是稍微麻烦点，因为你需要创建一张和以前原有一模一样的表结构，包括基本列、属性、约束、索性等等。

三、数据收缩 - 秋风少落叶

 　　数据删除后，发现数据库占用空间大小并没有发生变化，此时我们就用借助强悍的数据收缩功能了，脚本如下，运行时间不定，取决于你的数据库大小，多则几十分钟，少则瞬间秒杀

DBCC SHRINKDATABASE(DB_NAME)

在SQL Server中，如何快速删除大表中的数据呢？  回答这个问题前，我们必须弄清楚上下文环境和以及结合实际、具体的需求，不同场景有不同的应对方法。

1： 整张表的数据全部删除

如果是整张表的数据全部清空、删除，这种场景倒是非常简单，TRUNCATE TABLE肯定是最快的。 反而用DELETE处理的话，就是一个糟糕的策略。

2： 大表中删除一部分数据

对于场景1、非常简单，但是很多实际业务场景，并不能使用TRUNCATE这种方法，实际情况可能只是删除表中的一部分数据或者进行数据归档后的删除。假设我们遇到的表为TEST，需要删除TEST表中的部分数据。那么首先我们需要对表的数据量和被删除的数据量做一个汇总统计，具体，我们应该采用下面方法：

·           检查表的数据量，以及要删除的数据量。然后计算删除的比例，

    sp_spaceused‘dbo.TEST‘;

    SELECT COUNT(*) AS DELETE_RCD WHERE TEST WHERE ......<删除条件>

2.1 删除大表中绝大部分的数据，但是这个绝大部分怎么定义不好量化，所以我们这里就量化为60%。如果删除的数据比例超过60%，就采用下面方法：

1： 新建表TEST_TMP

2:  将要保留的数据转移到TEST_TMP

3： 将原表TEST重命名为TEST_OLD， 而将TEST_TMP重命名为TEST

4： 检查相关的触发器、约束，进行触发器或约束的重命名

5： 核对操作是否正确后，原表（TEST_OLD）要么TRUANCATE后，再DROP掉。要么保留一段时间，保险起见。

注：至于这个比例60%是怎么来的。这个完全是个经验值，有简单的测试，但是没有很精确和科学的概率统计验证。

另外，还要考虑业务情况，如果一直有应用程序访问这个表，其实这种方式也是比较麻烦的，因为涉及数据的一致性，业务中断等等很多情况。但是，如果程序较少访问，或者在某个时间段没有访问，那么完全可以采用这种方法。

2.2 删除大表中部分数据，如果比例不超过60%

1：先删除或禁用无关索引（无关索引，这里指执行计划不用到的索引，这里是指对当前DELETE语句无用的索引）。因为DELETE操作属于DML操作，而且大表的索引一般也非常大，大量DELETE将会对索引进行维护操作，产生大量额外的IO操作。

2：用小批量,分批次删除（批量删除比一次性删除性能要快很多）。不要一次性删除大量数据。一次性删除大量记录。会导致锁的粒度范围很大，并且锁定的时间非常长，而且还可能产生阻塞，严重影响业务等等。而且数据库的事务日志变得非常大。执行的时间变得超长，性能非常糟糕。

批量删除时，到底一次性删除多少数量的记录数，SQL效率最高呢？  这个真没有什么规则计算，个人测试对比过，一次删除10000或100000，没有发现什么特别规律。（有些你发现的“规律”，换个案例，发现不一样的结果，这个跟环境有关，有时候可能是一个经验值）。不过一般用10000，在实际操作过程，个人建议可以通过做几次实验对比后，选择一个合适的值即可。

案例1：

DECLARE @delete_rows INT;

DECLARE @delete_sum_rows INT =0;

DECLARE @row_count INT=100000

WHILE 1 = 1

    BEGIN

        DELETE TOP ( @row_count )

        FROM    dbo.[EmployeeDayData]

        WHERE    WorkDate < CONVERT(DATETIME, ‘2012-01-01 00:00:00‘,120);

        SELECT  @delete_rows = @@ROWCOUNT;

            SET @delete_sum_rows +=@delete_rows

            IF @delete_rows = 0

            BREAK;

        END;

SELECT @delete_sum_rows;

案例2：

DECLARE @r INT;

DECLARE @Delete_ROWS  BIGINT;

SET @r = 1;

SET @Delete_ROWS =0

WHILE @r > 0

BEGIN

    BEGIN TRANSACTION;

        DELETE TOP (10000) -- this will change

           YourSQLDba..YdYarnMatch

           WHERE Remark=‘今日未入‘ and Operation_Date<CONVERT(datetime, ‘2019-05-30‘,120);

          SET @r = @@ROWCOUNT;

          SET @Delete_ROWS += @r;

    COMMIT TRANSACTION;

    PRINT(@Delete_ROWS);

END

该表有下面两个索引

USE [YourSQLDba]

GO

IF  EXISTS (SELECT * FROM sys.indexes WHERE object_id = OBJECT_ID(N‘[dbo].[YdYarnMatch]‘) AND name = N‘IX_YdYarnMatch_N2‘)

DROP INDEX [IX_YdYarnMatch_N2] ON [dbo].[YdYarnMatch] WITH ( ONLINE = OFF )

GO

USE [YourSQLDba]

GO

CREATE NONCLUSTERED INDEX [IX_YdYarnMatch_N2] ON [dbo].[YdYarnMatch] 

(

    [Job_No] ASC,

    [GK_No] ASC

)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON, FILLFACTOR = 90) ON [PRIMARY]

GO

USE [YourSQLDba]

GO

IF  EXISTS (SELECT * FROM sys.indexes WHERE object_id = OBJECT_ID(N‘[dbo].[YdYarnMatch]‘) AND name = N‘IX_YdYarnMatch_N1‘)

DROP INDEX [IX_YdYarnMatch_N1] ON [dbo].[YdYarnMatch] WITH ( ONLINE = OFF )

GO

USE [YourSQLDba]

GO

CREATE NONCLUSTERED INDEX [IX_YdYarnMatch_N1] ON [dbo].[YdYarnMatch] 

(

    [Operation_Date] ASC

)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON, FILLFACTOR = 90) ON [PRIMARY]

GO

重点：实践证明，如果新建一个索引，能够避免批量删除过程中执行计划走全表扫描，也能大大加快删除的速度。个人对这个案例进行了测试、验证。发现加上合适索引后，让DELETE语句走Index Seek后，删除效率确实大大提升。

删除索引IX_YdYarnMatch_N2，保留索引IX_YdYarnMatch_N1，但是发现SQL执行计划走全表扫描，执行SQL时，删除非常慢

删除索引IX_YdYarnMatch_N1，重新创建索引IX_YdYarnMatch_N1后，执行计划走Index Seek，删除效率大大提示。

CREATENONCLUSTEREDINDEX [IX_YdYarnMatch_N1] ON [dbo].[YdYarnMatch]

(

    [Operation_Date] ASC,

    Remark

)

注意：此处索引名相同，但是索引对应的字段不一样。

所以正确的做法是：

1：先删除或禁用无关索引（对当前DELETE语句无用的索引），删除前生成对应的SQL，以便完成数据删除后，重新创建索引。注意，前提是在操作阶段，这个操作不会影响应用。否则应重新考虑。

2：检查测试当前SQL的执行计划，能否创建合适的索引，加快DELETE操作。如上面例子所示

3：批量循环删除记录。

4：在ORACLE数据库中，有些表的设置可以减少对应DML操作的日志生成量，但是SQL Server没有这些功能，但是要及时关注或调整事务日志的备份情况。

    如果我们能将将数据库的恢复模式设置为SIMPLE，那么可以减少日志备份引起的额外的IO开销。但是很多生产环境不能切换用户数据库的恢复模式。

其实说了这么多，SQL Server中大表快速删除索引的方法就是将一次性删除改成分批删除，逐次提交而已。其它的方式都是一些辅助方式而已。另外，如果你想亲自做一些细节测试，建议参考博客https://sqlperformance.com/2013/03/io-subsystem/chunk-deletes