where条件顺序与建索引顺序

查询时，如果数据量很大，where 后面的条件与建索引的顺序相同，也没有什么多少差别，聚集索引稍微快点; 但where 后面的条件与建索引顺序不同，速度会慢下来，到底慢多少，不同的机器会不一样，没有绝对的说法。

MSSQL引擎首先对条件进行优化，优化以后再查询。
1，还是那句，先看执行计划。
2.2008的话，对where的顺序它会自己优化，测试过，顺序对执行计划没有影响，不过2005好像有。所以从规范化来说，还是把筛选性高的放在where的前面，而不是考虑是否聚集索引
3.对于建立索引，就有讲究了，统计信息只看索引的第一列，所以创建索引时，筛选性高的那列应该放到索引定义的第一位。

#1.WHERE后面的条件只要一模一样，写在哪儿都是无所谓的。相同环境下，生成的执行计划也是一样的。
#2.至于建立索引的顺序，就有讲究了：1.复合索引的第一个字段最重要，SQL SERVER只生成复合索引第一个字段的统计信息，那么优化器也只能根据复合索引的第一个字段的统计信息来优化查询。2.当你自己从业务上了解了数据分布后，怎样写SQL和怎样建立索引就是一门学问了。有时候要根据SQL语句建立索引，有时候要根据已有索引更改SQL语句（用临时表等方法）。
#3.要想学会创建适合业务的索引，除了业务中的数据分布，你要了解索引的结构（聚集和非聚集），高选择性的概念，数据在页上的存储方式，及看得懂执行计划。

sp_help '表名'，拉到最下，有索引的定义

--指的fieldA,fieldB的顺序,也就是说：把fieldA这个字段排在第一位,是要考虑考虑的
CREATE INDEX IX_tablename_fieldA_fieldB ON dbo.tablename
(
FieldB
)
GO

索引顺序有讲究，where一般没有，不过2005及以下版本听说是有的，不过我没环境，你最好试一下

1、那个是符合索引。
2、所谓的索引顺序，其实是复合索引的顺序，两个索引之间没啥顺序可言，具体由sql查询优化器去根据统计信息及查询语句，和当前资源，选择使用哪个索引而已。

1、程序端的sql语句中，mssql对where的顺序会优化。不存在“ 1=1 ”的问题；也不存在“聚集 and 非聚集”的顺序问题。
2、mssql表中的索引顺序，对查询效率有影响，具体的需要结合实际业务——能够将查询结果最小化的索引放置在前面。
（个人见解——其实大多数业务中，应该是主键—聚集索引—非聚集索引）
3、符合索引的“字段A、字段B”——不说了，这个清楚。

主键仅仅为了确保业务上的数据可标识性，实际上可以没有聚集索引（我就改过很多表，把主键上的聚集索引移到别的字段上，效果不错），但是很多业务又真的需要经常使用主键做一些适合聚集索引特性的操作，所以可能这也是微软默认把主键带有聚集索引的理由之一，而且聚集索引能组织数据。对性能和维护来说很重要