【TechTarget中国原创】升级总结：
看上去当事务日志不增长的时候，性能会得到改善，特别是写入时。
删除命令
这个测试的目标同删除一样，也有更新与插入。
我向表中插入10，000行然后运行以下代码来删除所有行：
-- Truncate the table
truncate table ExpandDB
go
-- Truncate the T-Log
backup transaction ShrinkDB with truncate_only
go
-- Shrink T-Log back to 2MB:
DBCC SHRINKFILE （N'ShrinkDB_Log' , 0, TRUNCATEONLY）
Go
-- Delete 10,000:
declare @i int
set @i = 1
while @i <= 10000
begin
insert into ExpandDB select replicate （'a',1000）
set @i = @i + 1
end
go
-- Truncate the T-Log
backup transaction ShrinkDB with truncate_only
go
-- Shrink T-Log back to 2MB:
DBCC SHRINKFILE （N'ShrinkDB_Log' , 0, TRUNCATEONLY）
go
-- Delete 10,000:
delete from ExpandDB
-- Check size and % free space in T-Log
dbcc sqlperf（logspace）
go |
在第一步中，事务日志被缩减，autogrowth被设定为1MB。在第二步中，事务日志没有缩减丙炔他设定的足够大以至于不会增长。
下面是结果对比：
删除总结：
再次证明，事务日志不增长，性能就会越好，特别是在整个期限里。CPU差异呈现锯齿状情况（可能因为数量太少所以不精准）。
事务中的更多行
为测试大量事务的相关性能（事务日志自动增长），我重复了上面的测试，将行数改为50，000行（之前是10，000行），测试结果如下所示：
插入：
更新：
删除：
看上去，在事务日志不增长的情况下，事务越多性能改进越大。
更大的autogrowth
为测试更大autogrowth的相关性能，我将事务日志的autogrowth设置为50MB，然后连续三次运行以下代码（包括插入删除）：
-- Truncate the table
truncate table ExpandDB
go
-- Truncate the T-Log
backup transaction ShrinkDB with truncate_only
go
-- Shrink T-Log back to 2MB:
DBCC SHRINKFILE （N'ShrinkDB_Log' , 0, TRUNCATEONLY）
Go
-- Insert 50,000 rows
begin tran
declare @i int
set @i = 1
while @i <= 50000
begin insert into ExpandDB select replicate （'a',1000）
set @i = @i + 1
end
commit
Go
-- Truncate the T-Log
backup transaction ShrinkDB with truncate_only
Go
-- Shrink T-Log back to 2MB: DBCC SHRINKFILE （N'ShrinkDB_Log' , 0, TRUNCATEONLY）
Go
-- Delete 50,000: delete from ExpandDB
-- Check size and % free space in T-Log
dbcc sqlperf（logspace）
Go |
然后我对比了前两次的结果（50，000行、不同的autogrowth）： 插入：
删除：
结果显示事务日志增长越少，性能越佳。
测试结果总结——第二阶段
根据测试结果，我可以证明当事务日志在运行中增长时，它会对性能产生负面影响：
1、事务越多，性能受影响越大;
2、更新的行数越多，声场的T-Log越大;
3、Autogrowth越小，性能的影响越大。
注意我的测试只包含一个单独运行的事务。那么在多用户环境中，事务日志增长之后会发生什么？我将在今后的测试中继续研究。
另注：
同样的问题，测试证明了在一些数据库中，事务日志里的大量虚拟日志文件影响了数据修改的整体性能。这样的话，建议主动增长事务日志，不要让它自动增长。对于另外一些数据库，建议使用大的autogrowth（指大小而不是百分比）。