如何测试sql语句执行时间
在MSSQL Server中通过查看SQL语句执行所用的时间，来衡量SQL语句的性能。
set statistics profile on set statistics io on set statistics time on 你执行的SQL语句 go set statistics profile off set statistics io off set statistics time off
执行完后点消息即可。
补充说明：
set statistics io检查查询所产生的读和写
set statistics time检查查询的运行时间
当运行一sql语句，在消息中会显示如：
SQL Server分析和编译时间：CPU时间=0毫秒，占用时间=10毫秒。SQL Server分析和编译时间：CPU时间=0毫秒，占用时间=1毫秒。
(0行受影响)表't_login_session'。扫描计数1，逻辑读取2次，物理读取0次，预读0次，lob逻辑读取0次，lob物理读取0次，lob预读0次。
(3行受影响)
SQL Server执行时间：CPU时间=0毫秒，占用时间=11毫秒。SQL Server分析和编译时间：CPU时间=0毫秒，占用时间=1毫秒。
SQL Server执行时间：CPU时间=0毫秒，占用时间=1毫秒。
SQL Server执行时间：CPU时间=0毫秒，占用时间=1毫秒。
表't_login_session'。扫描计数1，逻辑读取2次，物理读取0次，预读0次，lob逻辑读取0次，lob物理读取0次，lob预读0次。
这个扫描统计告诉我们扫描执行的数量，逻辑读显示的是从缓存中读出来的页面的数量，物理读显示的是从磁盘中读的页面的数量，预读显示了放置在缓存中用于将来读操作的页面数量。
通过看这些信息我们能得到些什么呢?
◆这个查询没有扫描整个表，在表中的数据量超过1.5M字节，而仅仅执行了53个逻辑I/O操作就得到了结果。这表明该查询发现了一个可用来计算结果的索引，并且扫描索引比扫描所有数据页花费更少的I/O操作。
◆索引页几乎全部放在数据缓存中，所以物理读的值是零。这是因为我们之前不久是在employees表上执行了其他查询，此时表和它的索引已经被缓存。你的查询开销可能有不同。
◆Microsoft
报告没有read-ahead(预读)活动。在这种情况下，数据和索引页已经被缓存起来了。当对一个很大的表作表扫描时，read-ahead可能会半路
插入进来，并且在你的查询用到它们之前缓存起所需的页。当sql
server(WINDOWS平台上强大的数据库平台)确定你的事务是顺序读取数据库页并且认为它能预测到你下一步将用到的页面时，Real-ahead
会自动打开。实际上一个独立的sql
server(WINDOWS平台上强大的数据库平台)连接在你的进程之前已开始运行并为它缓存数据页。(配置和优化read-ahead参数已超出这篇
文章的讨论范围。
在这个例子中，该查询已经尽可能有效率地执行了，不必进一步优化。
SQL Server分析和编译时间：CPU时间=0毫秒，占用时间=10毫秒。
sql
server(WINDOWS平台上强大的数据库平台)仅仅花费10毫秒时间去分析和编译该查询。花费0毫秒去执行它(在查询结果可看到)。其真实的意思
是这个查询所花费的时间太短以至不能计量。最后的信息报告了这个SET STATISTICS TIME
OFF命令相关的分析及编译花费了1毫秒。你可以忽略这个信息。
SQL Server执行时间：CPU时间=0毫秒，占用时间=1毫秒。
是我们关注的运行时间
注
意实耗时间和CPU时间是以毫秒显示。这个数字在你的电脑上可能会改变(但是不要尝试与我们的笔记本电脑比较你机器的性能，因为这不是代表性的指标)。而
且，每次你执行这个脚本，考虑到你的sql
server(WINDOWS平台上强大的数据库平台)还在处理一些其他事务，你得到的统计信息都可能有一点不同。
2.简易得出SQL语句的执行时间的方法
select语句前加：declare @d datetime set @d=getdate()并在select语句后加：select[语句执行花费时间(毫秒)]=datediff(ms,@d,getdate())
----------------------------
我
做优化的时候关注3个：CPU、逻辑读和逻辑写。CPU主要是编译和重编译，而逻辑写主要出在insert的时候临时表查出来的数据量太大，建议缩减不必
要的部分，举个例子，insert into #temp select id ,name from
xxx表，而这个只是中间结果，只有在最终展示的时候才需要展示name，这次你就不应该把name字段insert进去。
然后就是逻辑读，如果
内存足够，那么几乎不引起物理读（除非维护所需，比如Checkpoint、lazy
Writer等），联机丛书上说，就算是写操作很频繁的系统，其读操作一般都还是比写操作高5~10倍，所以往往性能优化的书籍名字都是查询优化，而不是
更改优化等等的名字。逻辑读主要在内存发生。努力降低逻辑读，查询的速度会有明显提升，其实我觉得逻辑读还是会有很高成本，每一次读（SQLServer
按页来读），都要8K的空间，内存足够的时候，就是8K内存，内存不够，就是8K物理读，也就是硬盘空间，逻辑读越高，搜索的内存面积越广。降低逻辑读的
主要手段我个人认为有两个：
1、改写写法，把不必要的部分不查出来或者真正需要的时候才查出来。
2、调整索引，索引合理，你需要搜索的页面就少。这也是为什么有索引的查询会很快，很多查询光调整索引和where的顺序，就能从小时降到秒级别。