数据库调优积累系列(1):索引

时间:2022-09-18 11:51:57
索引
  1. 复合索引(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秒)注意升序和降序的区别?
  2. 当高选择性的非聚集索引达到5%的选择性时,该索引是非常有用的;
  3. 关于复合索引的属性列位置问题,应该把高选择性的列放到最左边(已前就忽略了这个高选择性的位置),那个通过IP和UrlID的SARG中我们可以创建一个IP和UrlID的复合索引,通过业务来说,我们测试的时候可能是IP的重复量比较大,但是在生成环境中,应该是UrlID的重复量会比较大,所以就IP放到复合索引的最左边;
  4. 对EasyURL跳转功能中,需要通过输入地址来查询目标地址,这个数据库查询可以使用覆盖索引,查询的速度是最快的;
  5. 当返回一个聚集索引列和一个非聚集索引列,并且是使用非聚集索引属性列作为SARG,那么这也是一个索引覆盖查询,因为在非聚集索引中包括聚集索引,所以直接在B-Tree就返回了数据,不用查询数据页;
  6. 在查询Select语句中用Where字句限制返回的行数和列数,避免表扫描,如果返回不必要的数据,浪费了服务器的I/O资源,加重了网络的负担降低性能。
  7. 对长字符列的索引,我们可以使用哈希索引,也就是CHECKSUM函数,具体用法可以看帮助文档;通常情况下我们都没有对长字符列建立索引的,而且我们的业务逻辑中对长字符作为内容的搜索也是不常见的,但是如果有需要,可以考虑哈希索引,有些同学可能会说为什么不用全文索引呢?因为毕竟全文搜索是要花费很多磁盘空间和IO操作的;