Mysql 索引

三大索引结构

哈希表、有序数组和搜索树。
哈希表
如何查找：通过哈希函数算出 N；然后，按顺序遍历，找到 数值
缺点：因为不是有序的，所以哈希索引做区间查询的速度是很慢的
优点：哈希表这种结构适用于只有等值查询的场景，比如 Memcached 及其他一些 NoSQL 引擎

有序数组
如何查找：用二分法就可以快速得到。
缺点：更新数据的时候就麻烦了，你往中间插入一个记录就必须得挪动后面所有的记录，成本太高。
优点：有序数组在等值查询和范围查询场景中，查询效率很高，有序数组索引只适用于静态存储引擎

搜索树
二叉树
如何查找：二叉搜索树的特点是：每个节点的左儿子小于父节点，父节点又小于右儿子
缺点：和磁盘访问相关，多层寻址消耗时间过长
优点：二叉访问查询时间复杂度log(N)，维护二叉时间复杂度log(N)

N叉树
如何查找:了让一个查询尽量少地读磁盘，就必须让查询过程访问尽量少的数据块。那么，我们就不应该使用二叉树，而是要使用“N 叉”树。这里，“N 叉”树中的“N”取决于数据块的大小
缺点:数据库技术发展到今天，跳表、LSM 树等数据结构也被用于引擎设计中
优点:N 叉树由于在读写上的性能优点，以及适配磁盘的访问模式

InnoDB 的索引模型

表都是根据主键顺序以索引的形式存放的，这种存储方式的表称为索引组织表。又因为前面我们提到的，InnoDB 使用了 B+ 树索引模型，所以数据都是存储在 B+ 树中的。

根据叶子节点的内容，索引类型分为主键索引和非主键索引。

主键索引的叶子节点存的是整行数据。在 InnoDB 里，主键索引也被称为聚簇索引（clustered index）。
非主键索引的叶子节点内容是主键的值。在 InnoDB 里，非主键索引也被称为二级索引（secondary index）。

索引维护

	B+ 树为了维护索引有序性，在插入新值的时候需要做必要的维护。
	插入中间数据 会在逻辑上挪动后面的数据，空出位置。
	插入末尾数据 不会做特殊处理
	
	所在的数据页已经满了，根据 B+ 树的算法，这时候需要申请一个新的数据页，然后挪动部分数据过去。这个过程称为页分裂。在这种情况下，性能自然会受影响。
	除了性能外，页分裂操作还影响数据页的利用率。原本放在一个页的数据，现在分到两个页中，整体空间利用率降低大约 50%。
	当然有分裂就有合并。当相邻两个页由于删除了数据，利用率很低之后，会将数据页做合并。合并的过程，可以认为是分裂过程的逆过程。

	自增主键是指自增列上定义的主键，在建表语句中一般是这么定义的： NOT NULL PRIMARY KEY AUTO_INCREMENT。
	插入新记录的时候可以不指定 ID 的值，系统会获取当前 ID 最大值加 1 作为下一条记录的 ID 值。
	也就是说，自增主键的插入数据模式，正符合了我们前面提到的递增插入的场景。每次插入一条新记录，都是追加操作，都不涉及到挪动其他记录，也不会触发叶子节点的分裂。

	而有业务逻辑的字段做主键，则往往不容易保证有序插入，这样写数据成本相对较高。
	除了考虑性能外，我们还可以从存储空间的角度来看。假设你的表中确实有一个唯一字段，比如字符串类型的身份证号，那应该用身份证号做主键，还是用自增字段做主键呢？
	由于每个非主键索引的叶子节点上都是主键的值。如果用身份证号做主键，那么每个二级索引的叶子节点占用约 20 个字节，而如果用整型做主键，则只要 4 个字节，如果是长整型（bigint）则是 8 个字节。
	显然，主键长度越小，普通索引的叶子节点就越小，普通索引占用的空间也就越小。
所以，从性能和存储空间方面考量，自增主键往往是更合理的选择。

	有没有什么场景适合用业务字段直接做主键的呢？还是有的。比如，有些业务的场景需求是这样的：
	只有一个索引；
	该索引必须是唯一索引。
	你一定看出来了，这就是典型的 KV 场景。
	由于没有其他索引，所以也就不用考虑其他索引的叶子节点大小的问题。
	这时候我们就要优先考虑上一段提到的“尽量使用主键查询”原则，直接将这个索引设置为主键，可以避免每次查询需要搜索两棵树。
	InnoDB 采用的 B+ 树结构，以及为什么 InnoDB 要这么选择。B+ 树能够很好地配合磁盘的读写特性，减少单次查询的磁盘访问次数。

	由于 InnoDB 是索引组织表，一般情况下我会建议你创建一个自增主键，这样非主键索引占用的空间最小。但事无绝对，我也跟你讨论了使用业务逻辑字段做主键的应用场景。

查询中的回表问题

	在非主键上查询，非主键首先会在非主键索引树结构中找到主键的ID，然后再在主键索引树中找到和主键对应的数据
	由于查询结果所需要的数据只在主键索引上有，所以不得不回表。那么，有没有可能经过索引优化，避免回表过程呢

解决回表的覆盖索引

	如果查询的数值是主键，那这时候在非主键索引树上面可以直接通过非主键和主键的对应关系，直接找到主键。
	同理，如果需要查找的数值已经在索引树上了，就不需要回表，直接通过查询非主键索引树就可以，可以直接提供结果，不需要回表。索引覆盖了查询需求，我们称之为覆盖索引

	需要注意的是，在引擎内部使用覆盖索引在非主键索引上其实读了多个记录，对应的索引 k 上的记录项，但是对于 MySQL 的 Server 层来说，它就是找引擎拿到了符合搜索条件的记录，因此 MySQL 认为扫描行数和实际不同

	如果现在有一个高频请求，要根据条件1查询条件2，这个联合索引就有意义了。它可以在这个高频请求上用到覆盖索引，不再需要回表查整行记录，减少语句的执行时间。

最左前缀原则

	看到这里你一定有一个疑问，如果为每一种查询都设计一个索引，索引是不是太多了。某些查询需求在业务中出现的概率不高，但总不能让它走全表扫描吧？反过来说，单独为一个不频繁的请求创建一个的索引又感觉有点浪费。应该怎么做呢？

	这里，我先和你说结论吧。B+ 树这种索引结构，可以利用索引的“最左前缀”，来定位记录。
	可以看到，索引项是按照索引定义里面出现的字段顺序排序的。
	可以看到，不只是索引的全部定义，只要满足最左前缀，就可以利用索引来加速检索。这个最左前缀可以是联合索引的最左 N 个字段，也可以是字符串索引的最左 M 个字符。

	基于上面对最左前缀索引的说明，我们来讨论一个问题：在建立联合索引的时候，如何安排索引内的字段顺序。
	这里我们的评估标准是，索引的复用能力。因为可以支持最左前缀，所以当已经有了 (a,b) 这个联合索引后，一般就不需要单独在 a 上建立索引了。因此，第一原则是，如果通过调整顺序，可以少维护一个索引，那么这个顺序往往就是需要优先考虑采用的。

索引下推

	在 MySQL 5.6 之前，只能从 ID3 开始一个个回表。到主键索引上找出数据行，再对比字段值。
	而 MySQL 5.6 引入的索引下推优化（index condition pushdown)， 可以在索引遍历过程中，对索引中包含的字段先做判断，直接过滤掉不满足条件的记录，减少回表次数。
	在使用ICP的情况下，如果存在某些被索引的列的判断条件时，MySQL服务器将这一部分判断条件传递给存储引擎，然后由存储引擎通过判断索引是否符合MySQL服务器传递的条件，只有当索引符合条件时才会将数据检索出来返回给MySQL服务器 。
	在不使用ICP的情况下，在使用非主键索引（又叫普通索引或者二级索引）进行查询时，存储引擎通过索引检索到数据，然后返回给MySQL服务器，服务器然后判断数据是否符合条件 。

	在 (字段1,字段2) 索引里面我特意去掉了 一个字段 的值，这个过程 InnoDB 并不会去看 查询条件 的值，只是按顺序把 字段一符合条件的 记录一条条取出来回表。因此，需要回表 多次。
	
	InnoDB 在 (字段1,字段2) 索引内部就判断了 字段2的条件，对于不满足条件的记录，直接判断并跳过。在我们的这个例子中，只需要对符合记录的数据回表取数据判断，就只需要回表的次数较少。

小结

问题

基于主键索引和普通索引的查询有什么区别？

	如果语句是主键查询方式，则只需要搜索 ID 这棵 B+ 树；
	如果语句是普通索引查询方式，则需要先搜索 k 索引树，得到 ID 的值为 500，再到 ID 索引树搜索一次。这个过程称为回表。
	基于非主键索引的查询需要多扫描一棵索引树。因此，我们在应用中应该尽量使用主键查询

	对高频请求创建联合索引，并且用这个索引支持需求
	

如何避免长事务对业务的影响

从应用开发端：
	确认是否使用了 set autocommit=0。这个确认工作可以在测试环境中开展，把 MySQL 的 general_log 开起来，然后随便跑一个业务逻辑，通过 general_log 的日志来确认。一般框架如果会设置这个值，也就会提供参数来控制行为，你的目标就是把它改成 1。
	确认是否有不必要的只读事务。有些框架会习惯不管什么语句先用 begin/commit 框起来。我见过有些是业务并没有这个需要，但是也把好几个 select 语句放到了事务中。这种只读事务可以去掉。
	业务连接数据库的时候，根据业务本身的预估，通过 SET MAX_EXECUTION_TIME 命令，来控制每个语句执行的最长时间，避免单个语句意外执行太长时间。（为什么会意外？在后续的文章中会提到这类案例）

其次，从数据库端来看：
	监控 information_schema.Innodb_trx 表，设置长事务阈值，超过就报警 / 或者 kill；
	Percona 的 pt-kill 这个工具不错，推荐使用；
	在业务功能测试阶段要求输出所有的 general_log，分析日志行为提前发现问题；
	如果使用的是 MySQL 5.6 或者更新版本，把 innodb_undo_tablespaces 设置成 2（或更大的值）。如果真的出现大事务导致回滚段过大，这样设置后清理起来更方便。
	用于设定创建的undo表空间的个数，在mysql_install_db时初始化后，就再也不能被改动了，修改该值会导致MySQL无法启动。

	默认值为0，表示不独立设置undo的tablespace，默认记录到ibdata中；否则，则在undo目录下创建这么多个undo文件(每个文件的默认大小为10M)。最多可以设置到126。
	例如假定设置该值为4，那么就会在mysql的data目录下创建命名为undo001~undo004的undo tablespace文件。（不支持后期修改）

既有联合查询又有各自查询

	那么，如果既有联合查询，又有基于 a、b 各自的查询呢？
	查询条件里面只有 b 的语句，是无法使用 (a,b) 这个联合索引的，这时候你不得不维护另外一个索引，也就是说你需要同时维护 (a,b)、(b) 这两个索引。

	这时候，我们要考虑的原则就是空间了。比如上面这个市民表的情况，字段1是比字段2大的 ，那我就建议你创建一个（字段1，字段2) 的联合索引和一个 (字段2) 的单字段索引。