​ 索引的建立必须慎重，对每个索引的必要性都应该经过仔细分析，要有建立的依据。因为太多的索引与不充分、不正确的索引对性能都毫无益处：在表上建立的每个索引都会增加存储开销，索引对于插入、删除、更新操作也会增加处理上的开销。另外，过多的复合索引，在有单字段索引的情况下，一般都是没有存在价值的；相反，还会降低数据增加删除时的性能，特别是对频繁更新的表来说，负面影响更大。

表的主键、外键必须有索引（默认就有）；

数据量大的表应该有索引；

经常与其他表进行连接的表，在连接字段上应该建立索引

经常出现在Where子句中的字段，特别是大表的字段，应该建立索引；

索引应该建在选择性高的字段上；

索引应该建在小字段上，对于大的文本字段甚至超长字段，不要建索引；

复合索引的建立需要进行仔细分析；尽量考虑用单字段索引代替：

A、正确选择复合索引中的主列字段，一般是选择性较好的字段；

B、复合索引的几个字段是否经常同时以AND方式出现在Where子句中？单字段查询是否极少甚至没有？如果是，则可以建立复合索引；否则考虑单字段索引；

C、如果复合索引中包含的字段经常单独出现在Where子句中，则分解为多个单字段索引；

D、如果复合索引所包含的字段超过3个，那么仔细考虑其必要性，考虑减少复合的字段；

E、如果既有单字段索引，又有这几个字段上的复合索引，一般可以删除复合索引；

频繁进行数据操作的表，不要建立太多的索引；

删除无用的索引，避免对执行计划造成负面影响； 以上是一些普遍的建立索引时的判断依据。

1、创建复合索引

2、满足复合索引的最左特性，哪怕只是部分，复合索引生效

3、没有出现左边的字段，则不满足最左特性，索引失效

4、复合索引全使用，按左侧顺序出现 name,salary，索引生效

5、虽然违背了最左特性，但MySQL执行SQL时会进行优化，底层进行颠倒优化

6、复合索引也称为联合索引，当我们创建一个联合索引的时候，如(k1,k2,k3)，相当于创建了（k1）、(k1,k2)和(k1,k2,k3)三个索引，这就是最左匹配原则。

Normal 普通索引

​ 普通索引

Unique 唯一索引 表示唯一的，不允许重复的索引，如果该字段信息保证不会重复例如身份证号用作索引时，可设置为unique

FullText 全文索引 即为全文索引，目前只有MyISAM引擎支持。其可以在CREATE TABLE ，ALTER TABLE ，CREATE INDEX 使用，不过目前只有 CHAR、VARCHAR ，TEXT 列上可以创建全文索引 全文索引并不是和MyISAM一起诞生的，它的出现是为了解决WHERE name LIKE “%word%"这类针对文本的模糊查询效率较低的问题。 一般 用于搜索很长一篇文章的时候，效果最好。用在比较短的文本，如果就一两行字的，普通的 INDEX 也可以。

HASH 由于HASH的唯一（几乎100%的唯一）及类似键值对的形式，很适合作为索引。 HASH索引可以一次定位，不需要像树形索引那样逐层查找,因此具有极高的效率。但是，这种高效是有条件的，即只在“=”和“in”条件下高效， 对于范围查询、排序及组合索引仍然效率不高。

B+TREE

​ B+TREE索引就是一种将索引值按一定的算法，存入一个树形的数据结构中（二叉树），每次查询都是从树的入口root开始，依次遍历node，获取leaf。这是MySQL里默认和最常用的索引类型。 ​ B+Tree索引是最常用的mysql数据库索引算法，因为它不仅可以被用在=,>,>=, info； 创建索引SQL -- 查询索引 show index from cms_appendixpicinfo; -- 附件表 ALTER TABLE `jwcms`.`cms_appendixinfo` ADD INDEX `ix_cms_appendixinfo_appdocid`(`APPDOCID`) USING BTREE COMMENT '文档ID 索引'; -- 附图表 ALTER TABLE `jwcms`.`cms_appendixpicinfo` ADD INDEX `ix_cms_appendixpicinfo_appdocid`(`APPDOCID`) USING BTREE COMMENT '文档ID 索引'; 索引失效原因 like子查询，%放前面；非空判断 is not null；or语句前后没有同时使用索引。当or左右查询字段只有一个是索引，该索引失效，只有当or左右查询字段均为索引时，才会生效；or语句（前后都有索引才行，SQL优化要避免写or语句）；数据类型出现隐式转化。如varchar不加单引号的话可能会自动转换为int型，使索引无效，产生全表扫描