1.对于MYSQL索引好处是什么?

　　我相信了解过索引的同学都知道，好的索引可以帮助我们很大提高QUERY的执行效率 以及服务器IO能力。

　　在数据库中个表的某个字段创建索引，所带来的最大益处就是将该字段作为检索条件的 时候，极大的提高检索效率，加快扫描时间，降低检索过程中所需要读取的数据量。

　　但是索引所给我们带来的好处难道仅仅是提高数据的检索效率吗?答案是否定的。NO

　　索引还有一个VERY GOOD的好处就是降低了数据的排序成本。

　　我们知道，每个索引中索引数据都是按照索引键键值进行排序后存放的，所以，当我们 的 SQLQuery 语句中包含排序分组操作的时候，如果我们的排序字段和索引键字段刚好 一致，MySQL Query Optimizer(优化器)就会告诉mysqld 在取得数据之后不用排序了， 因为根据索引取得的数据已经是满足客户的排序要求。(其实在GROUP BY ,ORDER BY 很 明显的).其实分组主要是消耗资源的是CPU和内存罢了。

　　坏处我就不仔细说了。我想和大家都知道，读写变慢了。占用空间变大了。(所以一个表千万别建立太多的索引啊!一定要采取合适方式，下面我会介绍下我的总结)

　　2.我们怎么判定这个字段是否需要建立索引?

　　由于大家面对项目差异也很大，情况也大不相同。我只能介绍下基本的策略吧!

　　@频繁的作为查询条件的字段应该建立索引的:因为提高数据查询检索效率的最有效的方式，是减少数据 量，如果这里用到的索引的话。可以有效的减少IO。一般情况下：这样都建立索引。

　　@ 惟一性太差的字段不要单独建立索引了。

　　唯一性这里指的是重复性高的字段。例如：表的状态。类型等字段。肯能有很多不同的值。这样的话没必要做索引了。一般情况下。这样的索引，MYSQL优化器基本不会应用到的。

　　这主要是由于数据基于索引扫描的特点所引起的。当我们通过索引访问表中的数据的时 候，MySQL 会按照索引键的键值的顺序来依序进行访问。一般来说每个数据页中大都会 存放多条记录，但是这些记录可能大多数都不会是和你所使用的索引键的键值顺序一致。其实主要涉及到了重复查找的问题。重复浪费大量的IO。数据量小的话。还可以要是百万，千万。那就不合适的。

　　举一个例子吧!

　　一个索引为status 我们需要找到status 属性值为0，1的数据。我们首先找0的值。发现在M页面找到了一个符合条件的值。在往下查找发现在N页面找到了也符合这个数据。那么就丢弃M页。去N页面。等所有数据都找完之后那，开始找值为1的数据。发现在M页面有这个数据。

　　由于刚才M页已经丢弃了。那么我们还得继续读取M页面符合数据的页面。这样的话。我们发现重复了。而且可能还会有很多重复啊!这给我们的存储引擎带来很大的IO访问量啊!所以他不适合单独建立索引。

　　当一条Query 所返回的数据超过了全表的15% 的时候，就不应该再使用索引扫描来完成这个Query 了。对于“15%”这个数字我们并不能判定是否很准确，但是之少侧面证明了唯一性太差的字段并不适合创建索引。

　　@更新非常频繁的字段不适合创建索引

　　当索引的数据更新时候。不仅仅更新表中数据还要更新索引的数据。这样IO访问量增大了。加大负载。建议尽量不要建立索引。

　　3.谈一下为什么复合索引比单列索引好那。

　　@复合索引就是多列索引。

　　在大概了解了一下MySQL 各种类型的索引以及索引本身的利弊与判断一个字段是否需要创建索引之后，我们就需要着手创建索引来优化我们的Query 了。在很多时候，我们的WHERE 子句中的过滤条件并不只是针对于单一的某个字段，而是经常会有多个字段一起作为查询过滤条件存在于WHERE 子句中。在这种时候，我们就必须要作出判断，是该仅仅为过滤性最好的字段建立索引还是该在所有字段(过滤条件中的)上面建立一个组合索引呢?

　　对于这种问题，很难有一个绝对的定论，我们需要从多方面来分析考虑，平衡两种方案各自的优劣，然后选择一种最佳的方案来解决。因为从上一节中我们了解到了索引在提高某些查询的性能的同时，也会让某些更新的效率下降。而组合索引中因为有多个字段的存在，理论上被更新的可能性肯定比单键索引要大很多，这样可能带来的附加成本也就比单键索引要高。但是，当我们的WHERE 子句中的查询条件含有多个字段的时候，通过这多个字段共同组成的组合索引的查询效率肯定比仅仅只用过滤条件中的某一个字段创建的索引要高。因为通过单键索引所能过滤的数据并不完整，和通过组合索引相比，存储引擎需要访问更多的记录数，自然就会访问更多的数据量，也就是说需要更高的IO 成本。

　　可能有的同学会说。我建立多个单列索引那。一般情况下，MYSQL只会找出那个让QUERY更好的索引。另外几个则不使用。

　　在一般的应用场景中，只要不是其中某个过滤字段在大多数场景下都能过滤出90%以上的数据，而且其他的过滤字段会存在频繁的更新，我一般更倾向于创建组合索引。其实有环境朋友可以测试下。联合索引还是比较好的啊!

　　其实大家在简历联合索引的时候尽量要让这个索引应用到不同的SQL-QUERY中。尽量减少同一个表上面索引的数量，减少因为数据更新所带来的索引更新资源，同时还可以减少因为索引所消耗的存储空间。何乐而不为那!