1.主要是考虑到查询的数据，直接从索引中取，不需要再通过查询表的数据，也就不需要通过书签查找，就能找到所有的数据，这样的话需要的IO就少，效率自然就提升了，所以可以把select中的字段，写到include中。2.这个得看你具体的语句，如果你的select子句中的列较少，比如2-3列，那么可以把这2-3个字段作为include中的列，建立覆盖这个查询的索引。如果列较多，那么不建议用include，因为这样的性能可能还没有，通过索引+书签查找的性能来的好。
1.主要是考虑到查询的数据，直接从索引中取，不需要再通过查询表的数据，也就不需要通过书签查找，就能找到所有的数据，这样的话需要的IO就少，效率自然就提升了，所以可以把select中的字段，写到include中。2.这个得看你具体的语句，如果你的select子句中的列较少，比如2-3列，那么可以把这2-3个字段作为include中的列，建立覆盖这个查询的索引。如果列较多，那么不建议用include，因为这样的性能可能还没有，通过索引+书签查找的性能来的好。
3.我这里就可以通过图形界面的方法来设置include列的：
SELECT A,B,C
FROM TB
WHERE A=10 AND B<8这时如果只加A,B的索引，在查找时就还是要根据找到的键值到表的数据页中去取C。
如果建的是A,B包含C的索引，就不用再去找表了，少了一步键值查找，减少开销，这就是包含索引的意义。另外，建索引干嘛还要用窗口，直接用语句不就好了吗，像上面那个包含索引
CREATE INDEX INX_TB_A_B ON TB(A,B) INCLUDE(C)
不就好的吗，还要点来点去的多麻烦。
上面的例子，请问把列C做为索引的包含列与直接把列C与列A、B一起做索引有什么区别？哪一种会好些？
上面的例子，请问把列C做为索引的包含列与直接把列C与列A、B一起做索引有什么区别？哪一种会好些？
区别是把列C加到键值列里能支持A AND B AND C这样的查询，代价是索引变大。没有优劣，按查询需要建索引。
include中列是不排序的，和一般的复合索引不完全一样，比如：(a) include(b)
和(a,b)是不一样的，一般如果是这样select b from tb where a = xxx
那么就用(a) include(b)如果是select b from tb where a = xxx order by b
那么就用(a,b)
这个相对于没有覆盖索引而言，有覆盖索引的话，就不一定比覆盖索引还高效。假设没有覆盖索引，你查询的列可能不在非聚集索引中，这是要借助聚集索引来获得那些额外的数据，造成额外的I/O，如果有包含索引，可以预先把数据也包含在索引中，所以减少这部分额外的i/o。
2.建立non-clustered index时，什么时候需要建立带有包含列的索引，什么时候不需要建立带有包含列的索引？
这个要看你的用法了，如果一个表你永远就用到那么1、2个列，直接在上面创建非聚集索引即可，没必要创建包含列，如果列不定，但是大部分查询都有某些列是相同的，而且列数很多，可以考虑使用包含列。
3.为什么在表的设计式下，在其索引建立窗口中include column是disble的? 但是可以通过脚本建立包含列的索引?怎样才可以索引建立窗口中include column是可以设置的？
估计你点错了
谢谢！
从底层看，两者都是B树的数据结构，只是由于include中的列不排序，而普通的索引中的列是排序的，所以可能会是这样,：而(a,b)：
1 a
1 b
1 c
2 a
2 b
2 c(a) include(b)那么叶子节点的数据：
1 b
1 c
1 a
2 c
2 a
2 b