今天5.1,在家里没什么事情,边看优化MSSQL数据库的书,边做实验,在MSSQL的TEST1数据库内创建了三个表,很简单, test1(bb varchar(100)), test2(bb varchar(100)), test3(bb varchar(100)), 我边通过insert into test1..test1 select * from test1..test1。。。三个语句往三个表里插入数据,边通过windows性能监视器观察计数器的变化,结果不知不觉的三个表里的记录已经达到了2000W的级别,系统提示C驱空间紧张,结果一看,哇塞!只剩下了10几兆了,打开企业管理一看,test1数据库数据文件近800M,日志文件更吓人,达到了惊人的6G啊,原来我的TEST1数据库不知道啥时候置成了完全恢复模式了,我的天啊,我的系统盘本身空间就紧张,没办法只能想办法删除或收缩,开始打算直接删除算了,但又有点不甘心,嫌麻烦,直接删除算了,结果还删除失败,不知道为什么,也没仔细研究,反正不打算直接删除,想通过这件事来总结一下收缩的方法,查联机文档,确定了思路,开始操作,结果在试验过程中,还是漏洞百出啊,最后还是通过了,贴一下: use master go backup log test1 with no_log use test1 go truncate table test1 truncate table test2 truncate table test3 use master go dbcc shrinkdatabase (test1,10) go 这里值得注意的是,上面TRUNCATE TABLE …语句,本来是没考虑就用了DELETE FROM TEST1..TEST1…,结果由于DELETE删除大表需要极大的LOG,因此我在删除的时候,我看到LOG在长,由开始的90M长到了近1G,最后没办法,终止,改成了TRUNCATE,由此看来,删除大表的数据时,还是TRUNCATE好使啊,几秒钟搞定,真爽!!!