【TechTarget中国原创】在本文中，我将对事务运行过程中事务日志增长对性能的影响做测试。我这次的测试环境和配置同前两次的相同。
数据库
本次测试中使用的ShrinkDB数据库要预先配置好，保证数据库足够大并在事务运行中不会增长。事务日志文件大小只有2MB。测试的目的就是让它随着事务进行而增长，从而衡量它的影响：
ShrinkDB数据库的还原模型设置为FULL。
使用以下查询语句（fileid = 2 → the T-Log file）：
select size from sysfiles where fileid = 2
这是事务日志文件的大小（每页8KB）。256*8=2MB。
原先测试用过的ExpandDB表在本次测试用依然使用。
create table ExpandDB （a varchar（8000））
测试
测试的目标就是检验让数据库事务日志自动增长的INSERT, UPDATE和DELETE命令如何影响性能。
由于升级，插入和删除可能会相互影响，所以这个测试包含三个部分，每次一个操作：
UPDATES
INSERTS
DELETE
注意：在原先的文章中，我证明了只有大量的事务才能使事务日志自动增长。
插入命令
在本次测试中，一次事务我都向表中插入了10，000行。每一步都执行相同的代码，但事务日志的autogrowth设定不同：
在第一步中， autogrowth设置为1MB;
在第二步中， autogrowth设置为10MB。
这两个步骤总共执行三次，SQL Profiler来捕获执行统计。以下为代码：
-- Truncate the table
truncate table ExpandDB
go
-- Truncate the T-Log
backup transaction ShrinkDB with truncate_only
go
-- Shrink T-Log back to 2MB （initial size）:
DBCCSHRINKFILE （N'ShrinkDB_Log', 0, TRUNCATEONLY
Go
-- Insert 10000 rows
-- Big transaction
begin tran
declare @i int
set @i = 1
while @i <= 10000
begin insert into ExpandDB select replicate （'a',8000）
set @i = @i + 1
end
commit
Go
-- Check size and % free space in T-Log
dbcc sqlperf（logspace
go
select count（*） from ExpandDB
go |
在第一步中，事务日志达到110MB。在第二步中达到了102MB。 以下是结果比较（只有插入）：
我又进行了第三次测试，事务日志文件设定为130MB并在事务运行期间不增长。这次我没有缩减事务日志，代码如下：
-- Truncate the T-Log
backup transaction ShrinkDB with truncate_only
go
-- Insert 10000 rows
-- Big transaction
begin tran
declare @i int
set @i = 1
while @i <= 10000
begin
insert into ExpandDB select replicate （'a',8000）
set @i = @i + 1
end
commit
Go
-- Check size and % free space in T-Log
dbcc sqlperf（logspace）
go
select count（*）
from ExpandDB
go |
现在我们有了上一次执行和第一次执行的比较，只有插入命令：
插入总结：
平均改进数据显示性能的增强和事务运行中事务日志增长数目有关。自动增长越少性能越佳，特别是对于整段时间而言（无增长比1MB增长性能改进了80%）。
升级命令
在上一篇文章中显示，当每次都有很多行改变时，升级会令事务日志增长。为此，我执行了以下代码：
-- 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
-- Update 10000 rows at a time
update ExpandDB set a = 'aaaaaaaaaaaaaaaaaaaaaaaa'
go
-- Check size and % free space in T-Log
dbcc sqlperf（logspace）
go |
我运行了两次以确保事务日志按相同比例增长，令人困惑的是第一次运行中时事务日志增长了，而第二次一点没有增长（停留在2MB）！ 这可能意味着行值不变的话，事务日志也就不增长。为证明，我加了一个Select语句来输出被升级影响的行数：
-- 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
-- Update 10000 rows at a time
update ExpandDB set a = 'aaaaaaaaaaaaaaaaaaaaaaaa'
select @@rowcount go
-- Check size and % free space in T-Log
dbcc sqlperf（logspace）
go |
返回的行值一直是10000.
当我修改了升级值（update ExpandDB set a = 'abcde'），
-- #1 ITERATION:
-- 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
-- Update 10000 rows at a time
update ExpandDB set a = 'aaaaaaaaaaaaaaaaaaabc'
go
-- Check size and % free space in T-Log
dbcc sqlperf（logspace）
go
-- #2 ITERATION:
-- 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
-- Update 10000 rows at a time
update ExpandDB set a = 'AAA'
go
-- Check size and % free space in T-Log
dbcc sqlperf（logspace）
go
-- #3 ITERATION:
-- 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
-- Update 10000 rows at a time
update ExpandDB set a = 'zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz'
go
-- Check size and % free space in T-Log
dbcc sqlperf（logspace）
go |
不出所料，当事务日志设置为每次增长1MB时，它最后的大小是不同的。 以下是结果的对比：
