sql误区

1、 表上不管用得着用不着，都加个聚集索引。
表以两种方式组织物理存储：有聚集索引的“聚集表”；没有聚集索引的“堆”。在聚集表中，数据行按照聚集索引的顺序存储
（这也是为啥一张表最多只能有一个聚集索引的原因）；堆中，数据行的存储可以认为是不确定的。

2、 primary key就是聚集索引。
3、 Log类的表，有事没事加个自增的Id列。
4、 是个表就给加个primary key约束
5、 在where条件里对同一个表中的列做运算或比较，以为创建某种类型的索引可以提高效率。
（这种情况下，任何索引都无法提升性能。解决办法见偶前面的“写有效率的sql查询”）

6、 在表上创建了col1、col2顺序的涵盖索引（聚集的或非聚集的），但是where条件里就一个col2 > XXX。
这种情况下，就不如分别在col1、col2上创建索引。


7、 存储过程中使用局部变量而不使用参数变量（就是存储过程输入参数）做where条件
存储过程中，能不使用本地变量就不使用，尽可能的使用参数变量（也就是输入参数）。如果不得不使用本地变量，
那也得只用在分布密度足够小的索引上使用。

8、 查询条件中类型不匹配
写查询条件时，应该尽可能的使类型匹配。使用诸如SqlCommand执行DB指令时，一定要让输入参数从类型到长度严格匹配相应的列。
尽管DB端不是所有的隐式转换都会引起性能损耗。

9、拼SQL。拼SQL要浪费大量的cpu进行编译，浪费大量缓存空间来存储只用一次的查询计划。

10、参数化SQL，和存储过程基本一样，只要是相同的查询，也都是只编译一次，以后重用（当然，指定了option(recompile)的除外）。
指定参数的长度。

11、存储过程，伊只编译一遍（如果没有指定with recompile选项的话，如果指定了，根本就不会生成计划缓存）。建议
DB中的所有操作都尽可能的使用存储过程，哪怕只是一句简单的select。