GO SET STATISTICS TIME ON SELECT count([StyleId]) FROM [dbo].[Ky_Style] SET STATISTICS TIME OFF SET STATISTICS TIME ON SELECT count(*) FROM [dbo].[Ky_Style] SET STATISTICS TIME OFF SET STATISTICS TIME ON SELECT count(*) as H FROM [dbo].[Ky_Style] SET STATISTICS TIME OFF
(1 行受影响) SQL Server 执行时间: CPU 时间 = 687 毫秒,占用时间 = 925 毫秒。 (1 行受影响) SQL Server 执行时间: CPU 时间 = 594 毫秒,占用时间 = 594 毫秒。 (1 行受影响) SQL Server 执行时间: CPU 时间 = 594 毫秒,占用时间 = 688 毫秒。
1.应尽量避免在 where 子句中使用!=或<>操作符,否则将引擎放弃使用索引而进行全表扫描。
不太准确,在sql server 2008测试过,不等于也可以走索引查找的,主要取决于返回的列是不是索引键,以及返回的行数在表中总行数的比率;
3.应尽量避免在 where 子句中对字段进行 null 值判断,否则将导致引擎放弃使用索引而进行全表扫描,如:
select id from t where num is null
可以在num上设置默认值0,确保表中num列没有null值,然后这样查询:
select id from t where num=0
错误,既然给了用例,那么就很好测试了,is null可以走索引查找的;
4.应尽量避免在 where 子句中使用 or 来连接条件,否则将导致引擎放弃使用索引而进行全表扫描,如:
select id from t where num=10 or num=20
可以这样查询:
select id from t where num=10
union all
select id from t where num=20
不太准确,是否全表扫描看OR里的条件的,如果条件都能走索引查找,那就没必要全表扫描了,而且用union或者union all也存在这个问题;
6.in 和 not in 也要慎用,否则会导致全表扫描,如:
select id from t where num in(1,2,3)
对于连续的数值,能用 between 就不要用 in 了:
select id from t where num between 1 and 3
错误,SQL谓词只是代表语义,通常不会代表执行计划;
7.如果在 where 子句中使用参数,也会导致全表扫描。因为SQL只有在运行时才会解析局部变量,但优化程序不能将访问计划的选择推迟到运行时;它必须在编译时进行选择。然 而,如果在编译时建立访问计划,变量的值还是未知的,因而无法作为索引选择的输入项。如下面语句将进行全表扫描:
select id from t where num=@num
可以改为强制查询使用索引:
select id from t with(index(索引名)) where num=@num
错误,参数化当然可以走索引查找;
20.尽量使用表变量来代替临时表。如果表变量包含大量数据,请注意索引非常有限(只有主键索引)。
不知道用意何在,表变量不支持索引,没有统计信息,而且超过固定大小,表变量也会存到tempdb和临时表一样;
21.避免频繁创建和删除临时表,以减少系统表资源的消耗。
不知道用意何在,会话结束,临时表自动释放的;
23.在新建临时表时,如果一次性插入数据量很大,那么可以使用 select into 代替 create table,避免造成大量 log ,以提高速度;如果数据量不大,为了缓和系统表的资源,应先create table,然后insert。
不太准确,以前确实是这样的,但是insert...select从2008开始,和select...into一样日志最小化了;
24.如果使用到了临时表,在存储过程的最后务必将所有的临时表显式删除,先 truncate table ,然后 drop table ,这样可以避免系统表的较长时间锁定。
未测试,先不说,嘿嘿
30.尽量避免大事务操作,提高系统并发能力。
不太准确,用大事务还是小事务,还是得看,对于单个用户重复N次提交,肯定是用1个大事务更快,因为只有一次commit;对于对个用户并发,一般是希望事务越短小越好。