filed like 'M%'substr(filed,1,1) = 'M' 上下功能相同，下面效率好
substr(filed,-2,2) 表示后面开始
where str = '@@@' and id >2000where 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分页效率是一样的。
