index seek和index scan 提高sql 效率
解释解释index seek和index scan：
索引是一颗B树，
index seek是查找从B树的根节点开始，一级一级找到目标行。
index scan则是从左到右，把整个B树遍历一遍。
假设唯一的目标行位于索引树最右的叶节点上（假设是非聚集索引，树深度2，叶节点占用k页物理存储）。
index seek引起的IO是4，而index scan引起的IO是K，性能差别巨大。
关于索引，可以仔细读读联机文档关于物理数据库体系结构部分
  查询条件中不要包含运算
这些运算包括字符串连接（如：select * from Users where UserName + ‘pig’ = ‘张三pig’），通配符在前面的Like运算（如：select * from tb1 where col4 like ‘%aa’），使用其他用户自定义函数、系统内置函数、标量函数等等（如：select * from UserLog where datepart(dd, LogTime) = 3）。
  SQLServer在处理以上语句时，一样没办法估算开销。最终结果当然是clustered index scan或者table scan了。

  查询条件中不要包含同一张表内不同列之间的运算
所谓的“运算”包括加减乘除或通过一些function（如：select * from tb where col1 – col2 = 1997），也包括比较运算（如：select * from tb where col1 > col2）。这种情况下，SQLServer一样没办法估算开销。不论col1、col2上都有索引还是创建了col1、col2上的覆盖索引还是创建了col1 include col2的索引。
但是这种查询有解决办法，可以在表上多创建一个计算字段，其值设置为你的“运算”结果，再在该字段上创建一个索引，就Ok了。
（结果集/总行数）被称为选择性，比值越大，选择性就越高。
你得到了它，本文的重点就是选择性。
统计信息，说白了，就是表中某个字段取某个值时有多少行结果集。统计信息可以说是一种选择性的度量，SQLServer就是根据它来估算不同查询计划的优劣。 
若表中总行数为1w，采样行数为1w。provider_no值为21的只有1行，而值为500的行则有4824行。

我们知道，SQLServer会缓存查询计划，假如有这么一个存储过程：
create proc myproc
(
  @pno int
)
as
select * from charge where provider_no = @pno
第一次我们传进来一个21，OK，它会缓存该存储过程的执行计划为nonclustered index seek那个。后来我们又传进来一个500，完蛋了，服务器发现它有一个myproc的缓存，so，又通过nonclustered index seek执行，接着你的同伙看到你的查询花费了巨量的IO，于是，你被鄙视了。
这说明了啥？说明如果你的查询选择性变动剧烈，你应该告诉SQLServer不要缓存查询计划，每次都应该重新评估、编译。实现方法很简单，查询的尾巴上加一个option（recompile）好了。而且SQL2k5还有一个nb的feature，可以每次只重新编译存储过程的一部分（当然，你也可以选择重新编译整个存储过程，这取决于你的需求。详见联机文档。）


------解决方案--------------------
于是，我被鄙视了。
------解决方案--------------------
于是，我也被鄙视了。
------解决方案--------------------
楼上的冒用七哥id。
于是我也被鄙视了,我接分来着。
------解决方案--------------------
这么高深的东西还真不适应