为提高查询效率而创建的一种分散存储的数据结构，需要额外消耗一些空间来存储索引，表中索引不是越多越好，冗余的索引会影响增、删、改的效率

索引分类

普通索引：主要是提高查询速度，索引列的值可以重复、可以为空
唯一索引：索引列的值全局唯一、可以为空
主键索引：不允许为空的唯一索引
复合索引：多个字段组合而创建的索引，需要遵循最左前缀原则
全文索引：只能在CHAR，VARCHAR，TEXT文本类型字段上使用

索引的数据结构

• Hash

对Key进行哈希运算，再根据运算值映射到指定的物理地址即可，查询速度非常快
如果Hash发生碰撞，还需要通过链表来存储碰撞的数据
如果按照范围进行查找，则需要把所有的数据先加载到内存中再进行过滤，这样查询的效率特别低

• 二叉树（每个节点的度最多不超过2个）
  

二叉树采用的是二分查找，查找的时间复杂度为O(lgn)
根据主键查询7的数据，只需要比较3次即可完成
按照范围查询大于5的数据，只需要查询出节点为6以及其右子树即可，相比于Hash的范围查找要快很多
二叉树在数据库id自增的情况下（从1-7依次插入数据），会退化成线性链表，查找的时间复杂度为O(n)

• 红黑树
  

当二叉树处于一个不平衡状态时，红黑树就会自动左旋右旋节点以及节点变色来调整树的形态使其保持基本的平衡状态，查找的时间复杂度为O(lgn)
红黑树在数据库id自增的情况下（从1-7依次插入数据），会出现右倾现象，数据量非常大的情况下查询成本还是比较高的

• 平衡二叉树
  

平衡二叉树解决了红黑树右倾的问题，查找的时间复杂度为O(lgn)
平衡二叉树中的每一个节点只存储（1关键字+1数据区+1左节点引用+1右节点引用），每次IO操作时操作系统都会为其分配4K的内存空间用于加载当前节点，然而实际每一个节点所消耗的内存空间不足4K，这就造成单次IO操作加载节点不饱和的现象

• B Tree
  

B树中每个节点最多存储（2个关键字、2个数据区、3个节点引用），一个节点如果超过2个关键字就会自动分裂
B树查找的时间复杂度为O(h * lgn)，h为树高，n 为每个节点存储关键字的数量
B树相对于平衡二叉树，在数据量相同的情况下，B数据的高度要低于平衡二叉树，减少了查询次数

• B+TREE

B+树的根节点、支节点存储的是（关键字、节点引用），相比于B树单位节点要存储更多的关键字，在数据量相同的情况下，B+树的高度要远远低于B树，减少了查询次数
B+树的叶子节点存储的是（关键字、数据区），叶子节点是顺序排列的并且相邻叶子节点具有相互引用的关系，非常适合排序

创建索引的原则

频繁作为查询条件出现的字段需要为其创建索引 (where、order by)
唯一性太差的字段不适合为其单独创建索引，即使该字段频繁作为查询条件。（数据高度重复的列的索引会失效）
更新非常频繁的字段不适合创建索引
#
Innodb引擎在创建表时一定要设置主键（推荐使用自增）
创建表时不要设置列的默认值为空，避免查询出现is null、is not null
在满足业务需求的情况下，索引长度能少则少（数字类型要设置成整型，不要设置成字符型，否则作为条件查询时还是会隐士转化成整型）
IN可以使用索引，NOT IN 无法使用索引
like 9%， like %9%， like%9这三种方式都用不到索引。后两种方式对于索引是无效的，第一种9%是不确定的，决定于列的离散程度
查询条件中不要使用函数，否则索引将会失效
联合索引必须按照最左前匹配原则进行查询

存储引擎

MySql5.5之前默认采用的是MyISAM，5.5之后默认采用的是innodb
MyISAM 虽然数据查找性能极佳，但是不支持事务处理
Innodb 支持了 ACID 兼容的事务功能，而且支持行级锁

• MyISAM（表锁）
  读、写锁调度为写优先，因为写锁后其他线程不能做任何操作，所以不适合用做以写为主业务场景

对于SELECT语句，会自动给涉及的所有表加读锁，会阻塞其它线程对同一表的写操作
对于UPDATE、DELETE和INSERT语句，会自动给涉及的表加写锁，会阻塞其它线程对同一表的读和写

• MyISAM（行锁）

对于普通SELECT语句，不会加任何锁
对于UPDATE、DELETE和INSERT语句，会自动给涉及到的数据加排他锁