首页 > 数据库> 文章详细

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

2019-10-23 22:00:57 阅读：285 来源： 互联网

标签：1000W 数据库 id 索引全表 num where MSSQL select

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

标签：1000W,数据库,id,索引,全表,num,where,MSSQL,select
来源： https://www.cnblogs.com/wxbug/p/8125872.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

ICode9

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