Sql Server之旅——第九站 看公司这些DBA们设计的这些复合索引

这一篇再说下索引的最后一个主题，索引覆盖，当然学习比较好的捷径是看看那些大师们设计的索引，看从中能提取些什么营养的东西，下面我们看

看数据库中一个核心的Orders表。

一：查看表的架构

1 先查看这个表的大概架构信息

1 --查看表的架构信息

2 SELECT c.column_id,c.name,t.name FROM sys.columns AS c 

3 JOIN sys.types t

4 ON c.system_type_id=t.system_type_id

5 WHERE c.object_id=object_id(O_Orders) 

6 ORDER BY c.column_id

 

从这个订单表来看大概有89个字段。。。还是蛮多的，可能有太多的历史原因吧，下面就有一个疑问来了，针对这么多的字段加上五花八门的类型，如何规划

好单列索引和复合索引。。。下面我们来看看这些专家们怎么设计的。

 

2 复合索引

首先声明一下，由于我的权限有限，不能进行DBCC IND，PAGE等命令，所以我没有能力判断下面的索引是include索引还是复合索引，所以这里统一叫成

复合索引吧。

1 SELECT name,type_desc FROM sys.indexes WHERE object_id=object_id(O_Orders)

从上面可以看到，有9个非聚集索引，1个聚集索引，然后可以通过 SHOW_STATISTICS 抽查几个索引看看到底关联了哪些字段，找到其中的二个索引，

覆盖多达6列，如索引"idx_order_status_2","IX_O_OrdersUID"。

DBCC SHOW_STATISTICS(O_Orders,idx_order_status_2)

DBCC SHOW_STATISTICS(O_Orders,IX_O_OrdersUID)

 

从这两个索引中关联的字段大概可以看出两点信息：

①：这些字段都比较小，为char(1)，smallint，bit这样的，自然表示的状态会比较少。

②：将表中多个状态少的字段挑选几个按照访问频率组合在一起做一个索引。

 

但是仔细想想，虽然原则上说状态少的字段不合适建索引，但是类似“订单状态(OrderStatus”这种字段，肯定是一个被频繁查询的列。。。既然是频繁的列，

肯定就要想办法优化，方法就是建复合索引，这样在复杂的sql中更加容易被撞上索引覆盖。

比如下面这样：

1 SET STATISTICS IO ON 

2 SELECT OrderStatus, ProcessStatus, SendTicketCity, FlightAgency, Eticket, OrderID

3 FROM dbo.Orders WHERE OrderStatus=P AND ProcessStatus=1 AND SendTicketCity=1

然后继续挑选几个索引瞄一瞄。。。一般来说，覆盖1到2个列的索引都叫小索引。

1 DBCC SHOW_STATISTICS(O_Orders,idx_eid_orderdate)

2 DBCC SHOW_STATISTICS(O_Orders,IX_O_Order_FinishDate)

通过上面的索引大概可以看到，Eid和FinishDate这两列，一眼扫过就知道应该是一个唯一性比较高的列了，至于为什么要覆盖2列，那这个就是根据业务

和生产的滚动数据来决定了，那这样的索引有什么好处呢？同样更容易会撞到索引链接，也就是多条件中会走到多个索引，每个索引中贡献一些列刚好可以

满足select中的所有列。。。比如下面这样。

1 -- 可以看到，select中的所有列都是有idx_eid_orderdate 和 IX_O_Order_FinishDate 贡献

2 SELECT OrderID,FinishDate,PrepayType,Eid,OrderDate

3 FROM dbo.O_Orders WHERE Eid=cctv1 AND FinishDate 2015-1-1

 

好了，就像园友说的，索引就是拆东墙补西墙，每建一个索引都需要评估它的利弊。

没有索引也能用SQL ？深度解析 SLS Schema-on-Read 分析原理与应用 为了能够更灵活的挖掘日志数据背后的价值，SLS提出了一种不需要事先建立索引就能对数据进行分析的模式。本文对SLS Schema-on-Read分析的提出背景、设计思路、实现过程、使用方式、适用场景进行了全面的介绍。
SQL语句命中索引，但还是执行很慢 MySQL的慢查询日志是MySQL提供的一种日志记录，用来记录在MySQL中响应时间超过阀值的语句，具体指运行时间超过long_query_time值（默认值10s）的SQL，则会被记录到慢查询日志中。
霜皮剥落紫龙鳞，下里巴人再谈数据库SQL优化，索引(一级/二级/聚簇/非聚簇)原理 举凡后端面试，面试官不言数据库则已，言则必称SQL优化，说起SQL优化，网络上各种“指南”和“圣经”难以枚举，不一而足，仿佛SQL优化已然是妇孺皆知的理论常识，然后根据多数无知（Pluralistic ignorance）理论，人们印象里觉得多数人会怎么想怎么做，但这种印象往往是不准确的。那SQL优化到底应该怎么做？本次让我们褪去SQL华丽的躯壳，以最浅显，最粗俗，最下里巴人的方式讲解一下SQL优化的前因后果，前世今生。
sql调优之：字符集不一致导致的索引失效案例 生产上有一段sql，大概几百行，做的是inser into …select ;的操作，但是执行了一个多小时都出不来，正常情况下不会这么久，通过一步步定位，最后发现是其中某一段的join 特别慢导致的，后面对这段sql重点分析发现，这里的表竟然没有走索引，对于几十万以上的表之间的连接，若是没有索引那就是灾难性的，加不加索引就好比一个人力三轮与超跑的区别。
第十二届 BigData NoSQL Meetup — 基于hbase的New sql落地实践 立即下载