记一次SQL Server的清理过程

由于历史原因，库里有几张表的行数已经超过了几亿条，而且99%都是无用的历史数据（别问我为什么这么多，就是这么刺激），简单的top 1查询都能跑个十几分钟。
以上，是背景。

业务上来看，服务器已经完全无法工作了，所以选择了停机维护。

第一步，使用获取总行数

select count(0) from t1

悲催的跑了10分钟还没得出结果，放弃了。。。
因为表内的业务数据具有时效性，所以选择直接清表。
两种方式，delete和truncate

delete from t1;
truncate table t1;

delete是DML命令，删除数据会写事务日志，对磁盘、内存影响较大，而且很慢，但是支持条件删除（这个是优点，但是这次用不到）。
truncate是DDL命令，删除数据，效率较高不锁数据库写日志较小，看起来比较适合我们。

但是！！！

表里的数据实在是太大了，truncate跑了1个半小时还没跑完。。赶时间啊兄弟，只能把你kill掉了！

好在truncate取消是不会回滚的，结束truncate之后发现表里只有900w+的数据，起码还是有效果的。

重点来了，在结束truncate table t1之前，我们对另外一张亿级行数的表t2做了drop操作，1s就结束了，然后用备份的结构重建了t2，真是美滋滋。。。

drop table t2

这玩意就是清理超大表的神器！（生产环境慎用）

数据清理结束了，下面就是数据库收缩了，把占用的空间资源释放出来。
先查看使用情况：

USE 你的库名;
GO
-- 数据库空间使用情况
EXEC sp_spaceused;

-- 查下文件空间使用情况
SELECT 
    file_id, name,
    [文件大小（MB）] = size / 128.,
    [未使用空间（MB）] = (size - FILEPROPERTY(name, N'SpaceUsed')) / 128.
FROM sys.database_files

-- 表空间使用情况
DECLARE @tb_size TABLE(
    name sysname,
    rows int,
    size varchar(100),
    data_size varchar(100),
    INDEX_size varchar(100),
    unused_size varchar(100)
);
INSERT @tb_size
EXEC sp_msforeachtable '
sp_spaceused ''?''
'
SELECT * FROM @tb_size

检查过数据文件和log文件之后，按照实际使用情况进行收缩

DBCC SHRINKFILE (N'逻辑文件名' , 10) -- targe size单位是m