Sql优化

filed like 'M%'
substr(filed,1,1) = 'M' 上下功能相同，下面效率好

substr(filed,-2,2)  表示后面开始

where str = '@@@' and id >2000
where id > 2000 and str = '@@@'  下面比上面效率高

count(*)不比count(字段)慢

filed内容越多，count时间越长，
count（*）可能自动查找filed内容最少的进行计算

下转：

1、Like语句是否属于SARG取决于所使用的通配符的类型 
没意见，%开头的话会走索引扫描或表扫描

2、or 会引起全表扫描 
错了，OR只是不能使用左右两边谓语的联合索引，对于类似于"A=1 OR B=2"这样的条件，应该在A和B上单独建索引

3、非操作符、函数引起的不满足SARG形式的语句
没什么意见，极少数情况下MSSQL会神奇的走索引查找。

4、IN 的作用相当与OR 
IN和OR的作用不同，这里说的“相当”应该只是批双方作用的交集，也就是"A IN (1,2,3)"和"A=1 OR A=2 OR A=3"这样的

5、尽量少用NOT 
该用还是要用。。。。。

6、exists 和 in 的执行效率是一样的
你可以用你们公司的大表试试，至少我的经验是绝对不一样。

7、用函数charindex()和前面加通配符%的LIKE执行效率一样 
没意见

8、union并不绝对比or的执行效率高
不是UNION而是UNION ALL。UNION有排序和去重，慢的要死。

9、字段提取要按照“需多少、提多少”的原则，避免“select *”
没意见，只有几种极端情况需要考虑用*，比如某天才设计出的一个所有列名长度都超过200的表。。。。。

10、count(*)不比count(字段)慢 
意义不同，字段不是非空的话可能结果不同。

11、order by按聚集索引列排序效率最高
非聚集索引如果包含所有查询需要的列和聚集索引效率一样。

12、高效的TOP
没什么意见，不过最新一样实验证明，ROW_NUMBER分页和TOP分页效率是一样的。