关于LINQ和SQL操作数据库的性能测试
微软linq技术已经出现很久，很多公司已经开始商业使用，作为我们暂时没有用到的人来说，也应该适当的了解下相关知识，但是直到目前网络上对他的看法仍然是褒贬不一，当然任何事情都不可能完美的，下面就针对大多数人比较关注的效率问题做一次试验，来实实在在的用事实说话。测试目的：主要是测试两者的时间区别
测试环境： CPU：奔腾双核T3400（2.16G）
内存：2G 667
硬盘：160G
操作系统：XP SP3
编译工具：vs 2008+mssql 2005
测试依据（非专业精密工具）： Stopwatch 类
提供一组方法和属性，可用于准确地测量运行时间。 Stopwatch 实例可以测量一个时间间隔的运行时间，也可以测量多个时间间隔的总运行时间。在典型的 Stopwatch 方案中，先调用 Start 方法，然后调用 Stop 方法，最后使用 Elapsed 属性检查运行时间。
Stopwatch 实例或者在运行，或者已停止；使用 IsRunning 可以确定 Stopwatch 的当前状态。使用 Start 可以开始测量运行时间；使用 Stop 可以停止测量运行时间。通过属性 Elapsed、ElapsedMilliseconds 或 ElapsedTicks 查询运行时间值。当实例正在运行或已停止时，可以查询运行时间属性。运行时间属性在 Stopwatch 运行期间稳固递增；在该实例停止时保持不变。
默认情况下，Stopwatch 实例的运行时间值相当于所有测量的时间间隔的总和。每次调用 Start 时开始累计运行时间计数；每次调用 Stop 时结束当前时间间隔测量，并冻结累计运行时间值。使用 Reset 方法可以清除现有 Stopwatch 实例中的累计运行时间。
Stopwatch 在基础计时器机制中对计时器的刻度进行计数，从而测量运行时间。如果安装的硬件和操作系统支持高分辨率性能的计数器，则 Stopwatch 类将使用该计数器来测量运行时间；否则，Stopwatch 类将使用系统计数器来测量运行时间。使用 Frequency 和 IsHighResolution 字段可以确定实现 Stopwatch 计时的精度和分辨率。
Stopwatch 类为托管代码内与计时有关的性能计数器的操作提供帮助。具体说来，Frequency 字段和 GetTimestamp 方法可以用于替换非托管 Win32 API QueryPerformanceFrequency 和 QueryPerformanceCounter。
注意：
在多处理器计算机上，线程在哪个处理器上运行无关紧要。但是，由于 BIOS 或硬件抽象层 (HAL) 中的 bug，在不同的处理器上可能会得出不同的计时结果。若要为线程指定处理器关联，请使用 ProcessThread..::.ProcessorAffinity 方法。
测试前准备：
新建一个数据库：SpeedTest，插入500万条记录用时38分57秒，最终数据库大小：213M
见表语句如：
CREATE TABLE Tab(
Id int IDENTITY(1,1) NOT NULL,
Context nvarchar(50) NOT NULL,
DoTime datetime NOT NULL
)
插入语句如： declare @i int,@start datetime,@end datetime
set @i=0
set @start=getdate()
while(@i<5000000)
begin
insert into tab(context,dotime)values('值:'+convert(varchar(20),rand()*10*rand()),getdate())
set @i=@i+1
end
set @end=getdate()
print '插入500万条数据用时：'+convert(varchar(20),datediff(ms,@start,@end))
第一轮测试---》查询
查询第100000到120000条数据中的长度为8的数据
查询用SQL语句如： --查询第到条数据中的长度为的数据
declare @start datetime,@end datetime
set @start=getdate()
select * from (
select top 20000 * from tab where id not in(select top 100000 id from tab)) as t where len(t.Context)=8
set @end=getdate()
print '插入万条数据用时：'+convert(varchar(20),datediff(ms,@start,@end))
测试结果如下： 单位：秒
第一次 第二次 第三次 第四次 第五次 第六次 第七次 第八次 第九次 第十次
Linq 0.6788 0.681 0.6704 0.6804 0.686 0.6555 0.6753 0.677 0.6717 0.6744
SQL 0.5653 0.5498 0.5699 0.5673 0.5699 0.5795 0.5756 0.5869 0.5749 0.5735
MSSQL 0.156 0.110 0.1430 0.170 0.126 0.156 0.126 0.143 0.140 0.126
第二轮测试----》修改
查询用SQL语句（把能被5整除的数据修改为“测”，应该影响1000000行）：
update tab set Context=Context where id%5=0
测试结果如下：
本来想批量修改数据的，更新100万行使用SQL语句用时基本在5.4——5.8秒之间，但是使用LINQ基本就挂了，5分钟都出不了结果，看来如果是批量修改，特别是大批量修改，还是尽量避免使用LINQ
现在就改变下测试思路，修改其中一条数据。
update tab set DoTime=dateadd(ms,1,DoTime) where id=2500000
测试结果如下： 单位：秒
第一次 第二次 第三次 第四次 第五次 第六次 第七次 第八次 第九次 第十次Linq 0.2068 0.2022 0.2029 0.2064 0.2055 0.2025 0.2067 0.2012 0.2058 0.2031
Sql 0.1466 0.1425 0.1386 0.1419 0.1457 0.1388 0.142 0.1384 0.1388 0.1426
第三轮测试---》插入
批量插入1万条数据
测试结果如下： 单位：秒
第一次 第二次 第三次 第四次 第五次 第六次 第七次 第八次 第九次 第十次
Linq 9.4243 9.5757 9.2637 9.5913 9.5264 9.573 9.5606 9.5448 9.4261 9.7743
Sql 8.7681 8.4239 7.9236 7.8332 7.8264 8.0614 7.997 7.979 7.888 8.2885
测试代码：
Linq速度试验.rar
(209.7 KB)
综上所述，LINQ这个新技术，在代码上和思想上的确很有优势，但是归根结底还是使用的是.net 2.0 的框架，只是抽象了一个接口而已，生成SQL语句的过程被LINQ完成，所以说LINQ即使到了极限也不能超越传统的SQL，另外据查资料，LINQ另一个瓶颈在于Lambda表达式。我们可以得出在效率要求不高的应用型系统中，使用LINQ还是很有优势的，毕竟代码少，维护方便，但是在修改操作上，特别是批量修改就毫无优势可言，效率低是一方面，内存在占用也是一个大问题，所以现在很多公司的做法就是两者混合起来用，不失为一个明智的选择。
