数据库优化——为什么要建立联合索引

上周的时候一个软件开发10多年的前辈，突然问我他加的数据库索引为啥没用。查询的速度还是那么慢。

我让他把查询语句，以及建立的索引列发来。

他在orderid列建立索引，这个方案是没问题的。关键是他犯了好多人犯过的错误。没有考虑到一个关键因素，回表。

其实我在开发当中很多工作了好多年的前辈，都没有理解回表的重要性。甚至跟我说查聚集索引和联合索引的效果是一样的。

这个误解是跟严重的。要知道数据库的优化做主要的就三点，排序，查询，I/0。回表主要和I/0有关。而I/0是最费资源，时间，cpu,I/O。这还不算有些大量的随机读，在加上数据量再大些。那简直恐怖的要死，我是真的见过有的工作好多年的前辈写得API来一条数据要几分钟往上。

什么叫回表？？？？回表是否可以避免？？

首先回表什么是回表。我正好可以举个简单的例子。

在没有建立索引的情况下，可以看到查询语句也会走索引。这个索引叫做聚集索引，他天生随表而生，他的索引键是主键。也就是说你建表的过程中，建了主键之后就会自动的创建这个聚集索引。他会给全表的数据按主键排个序，放在磁盘里。为什么要有这个主键索引，也就是聚集索引。因为他太重要，关系数据库，没有外键怎么行，有外键没有外键的索引怎么行。还有最基本的排序总要有个排序的标准吧。所以这个聚集索引可以大大的提高数据库的运行效率。

在没有索引的情况下，默认的会扫描这个索引，然后根据索引找到该行的主键，做I/O查找磁盘的数据。

那么回表跟这个聚集索引有什么关系。

首先我们建一个普通索引

这个索引如果我们用查询语句

select *
from core.Material
where MaterialNumber='YJHLH225'

是可以用到这个索引的。但是它解决的问题是查找。也就是说我可以用这个索引，像字典的查询字段一样可以查到这个列。

但是，但是仅仅也是查到。你还没有取啊。还没到磁盘里读取这个数据啊！！！

怎么办？？可以避免去I/0读取这个数据吗？？

也不知道谁想到一个想法，我只想说天才，他把要查找的字段放在索引里！！！！对啊我直接查完索引之后直接返回数据，管你别的干嘛，还去磁盘找数据，找个屁！！天才，真实懒人的天才。但是确实是大大的增强了数据库的查询效率。不得不说简单的道理才是美。

其实在500年前的明朝也有一个人运用了同样的思想拯救了大明王朝，使大明免受宋朝的复劫。他就是于谦，当时瓦剌入侵大明，俘虏明朝皇帝，兵临北京城下。各路勤王部队进京勤王，粮草成了问题，咋办？？？于谦的做法是，为啥不让这些勤王士兵自己从驻地带粮过来，于是这些大头兵，每个身上背一代粮食，从驻地出发到北京勤王。这样既解决了兵慌又解决了粮食危机，可谓一箭双雕。联合索引其实就和这个道理一样，本来需要取的数据，我挂在索引上，就解决了去磁盘读数据的步骤。