select语句前加：
declare @d datetime
set @d=getdate()
并在select语句后加：
select [语句执行花费时间(毫秒)]=datediff(ms,@d,getdate())
这是简易的查看执行时间的方法。
===========================================（一下内容转自：ＣＳＤＮ）
MSSQL Server中通过查看SQL语句执行所用的时间，来衡量SQL语句的性能。
set statistics profile on
set statistics io on
set statistics time on
go
你执行的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平台上强大的数据库平台)还在处理一些其他事务，你得到的统计信息都可能有一点不同。