MSSQL数据库 1000W数据优化整理

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；对于对个用户并发，一般是希望事务越短小越好。