优化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