复合索引（where A And B）如果没有对A和B做单一索引，查询的时间为a；如果对A做单一索引，查询时间为b；如果对B做单一索引，查询时间为c；如果对A、B做复合索引，查询的时间为d，那时间的比较就应该是a>b=c>d；（比如spMsgReader_Distribute中使用WHERE InfoID=@infoID AND UserID=@userID，插入7000次的时候就很明显地看到性能了；（8秒比1：50秒）注意升序和降序的区别？

　　当高选择性的非聚集索引达到5%的选择性时，该索引是非常有用的；

　　关于复合索引的属性列位置问题，应该把高选择性的列放到最左边（已前就忽略了这个高选择性的位置），那个通过IP和UrlID的SARG中我们可以创建一个 IP和UrlID的复合索引，通过业务来说，我们测试的时候可能是IP的重复量比较大，但是在生成环境中，应该是UrlID的重复量会比较大，所以就IP 放到复合索引的最左边；

　　对EasyURL跳转功能中，需要通过输入地址来查询目标地址，这个数据库查询可以使用覆盖索引，查询的速度是最快的；

　　当返回一个聚集索引列和一个非聚集索引列，并且是使用非聚集索引属性列作为SARG，那么这也是一个索引覆盖查询，因为在非聚集索引中包括聚集索引，所以直接在B-Tree就返回了数据，不用查询数据页；

　　在查询Select语句中用Where字句限制返回的行数和列数,避免表扫描,如果返回不必要的数据，浪费了服务器的I/O资源，加重了网络的负担降低性能。

　　对长字符列的索引，我们可以使用哈希索引，也就是CHECKSUM函数，具体用法可以看帮助文档；通常情况下我们都没有对长字符列建立索引的，而且我们的业务逻辑中对长字符作为内容的搜索也是不常见的，但是如果有需要，可以考虑哈希索引，有些同学可能会说为什么不用全文索引呢？因为毕竟全文搜索是要花费很多磁盘空间和IO操作的；