优化SQL语句的总结笔记

 

个人日常优化SQL语句的总结笔记

目前 DB 承受 日平均 500W PV 左右的站点，数据文件大小在20G左右，表数据量 在 50 - 500 W 左右

仅供参考：

 

1  . 查询的数据行分布情况，决定索引是否用得上，如果查询的数据行在数据表中分布均匀，且所占比重较大，能用上索引；反之，用不上索引

2  . select 的字段数目，特别是 长度较大的字段，对 语句的执行时间影响较大

3  . 语句中有 distinct 时，再在 where 语句中限制日期范围的话，反而会影响性能，无 distinct 时，执行情况是一样的

4  . distinct 一般占到总语句开销的 65 %左右

5  . newid 则视结果集而定，结果集越大，newid 所占语句的总开销比例也就越大

6  . group by 归总时，语句开销和Top 无关，所以，尽量少在大表中group by。

7  . group by 的字段越多，开销越大，且这些字段是用不上索引的，但是 where 中的条件是可以用上索引的。但是不可估量的是，用上索引也不一定能减少开销

8  . 非聚集索引，在 order by 中是用不上的

9  . Row_Number 在IO操作上不是十分的出色，但是在占用CPU资源上，却做的非常好。总体上，还是相当不错的，执行时间较短。

10. 在部分情况下，如果 Or 用好，是和 In 的效率一样的

11. 查询条件过多也会影响性能，且较严重

12. 查询中，UserName='ssssss' 的性能往往会比 UserID=123456 的性能要好

13 . 当语句中出现 in(select id from table1) 时，in里面的表达式一定要加top ，比如 select top 10 * from tables where id in(select top 100 id from table2)，特别是在 in 里面取出来的数据比较多，外表又很大的情况

14 . 聚集索引一定要建在在表中分布均匀的字段、增减规律的字段上，比如日期，而尽量避免将聚集索引建立在UserID等字段上

15 . 当 where 中有 like 条件匹配时，where 中的非聚集索引就会失效，引起全表扫描，但是聚集索引是可以用到的

16.  如过允许，请将 可能 引起全表扫表的 SQL 语句，加上 未提交读 的事物隔离级别设置,即 no lock