mysql原理（十） 当前读与快照读

首先我们做一个模拟，执行以下的sql，其中有如下图数据：

我把执行结果按照表格如下展示：

分析：

在会话1当中，只有当会话1的事务提交后，才能查到最终会话2更改的数据。

在会话2当中，开启事务后更新数据，之后查询发现数据变成了17。

针对上面的现象我们进行个原理分析:

实际上产生上述显现是因为InnoDB采用的MVCC（多版本并发控制），其中针对每条数据会有它自己的事务id，以及一个最大事务id。针对事务中数据每次修改，会产生不同的版本。

1）假设开始id = 2的数据，其事务txid = 1000；

2）当会话1开始，此时txid变成了1001，而会话2开启，txid又变成了1002，同理会话3会变成1003，此时都生成了不同版本的快照。

3）会话1在事务当中去读取时候，采用了快照读的方式，即拿到一个1001的事务id，此时只会读取小于等于自己版本的数据，所以在事务中最终只能拿到值为17的数据。

4）会话2在更新数据的时候，采用的当前读的方式，即对数据增加X锁，获取最新的事务id，读取最新的版本数据。所以在更新之前，就读取到了age的年龄是16，之后在进行+1，得到17.

总结一下：

快照读 解决了幻读的问题，即多次读取数据不一致的问题。

update、insert、delete都会执行 当前读 ，防止并发更新数据导致数据错误，此过程或添加X锁。

MySQL 前缀索引能有效减小索引文件的大小，提高索引的速度。但是前缀索引也有它的坏处：MySQL 不能在 ORDER BY 或 GROUP BY 中使用前缀索引，也不能把它们用作覆盖索引(Covering Index)。

集一个索引包含多个列（最左前缀匹配原则）

索引列的值必须唯一，但允许有空值

全文索引为FUllText，在定义索引的列上支持值的全文查找，允许在这些索引列中插入重复值和空值，全文索引可以在CHAR,VARCHAR,TEXT类型列上创建

设定主键后数据会自动建立索引，InnoDB为聚簇索引

即一个索引只包含单个列，一个表可以有多个单列索引

覆盖索引是指一个查询语句的执行只用从所有就能够得到，不必从数据表中读取，覆盖索引不是索引树，是一个结果，当一条查询语句符合覆盖索引条件时候，MySQL只需要通过索引就可以返回查询所需要的数据，这样避免了查到索引后的回表 *** 作，减少了I/O效率

查看索引

列名解析：

删除索引

查看：

删除前:

删除后：

普通的索引，没有什么介绍

查看:（注意和前缀索引Sub_part的区别）

当索引的列是unique的时候，会生成唯一索引，唯一索引关于null有下列两种情况

SQLSERVER 下的唯一索引的列，允许null值，但最多允许有一个空值

MYSQL下的唯一索引的列，允许null值，并且允许多个空值

查看:

会建立两个索引，一个非聚簇索引，一个是唯一索引

结果:

可以插入两个空值（明人不说暗话，我喜欢MySQL）

一方面，它不会索引所有字段所有字符，会减小索引树的大小.

另外一方面，索引只是为了区别出值，对于某些列，可能前几位区别很大，我们就可以使用前缀索引。

一般情况下某个前缀的选择性也是足够高的，足以满足查询性能。对于BLOB，TEXT，或者很长的VARCHAR类型的列，必须使用前缀索引，因为MySQL不允许索引这些列的完整长度。

查看：

查看：

复合索引的最左前缀匹配原则 ：

对于复合索引，查询在一定条件才会使用该索引

减少开销。 建一个联合索引(col1,col2,col3)，实际相当于建了(col1),(col1,col2),(col1,col2,col3)三个索引。每多一个索引，都会增加写 *** 作的开销和磁盘空间的开销。对于大量数据的表，使用联合索引会大大的减少开销！

覆盖索引。 对联合索引(col1,col2,col3)，如果有如下的sql: select col1,col2,col3 from test where col1=1 and col2=2。那么MySQL可以直接通过遍历索引取得数据，而无需回表，这减少了很多的随机io *** 作。减少io *** 作，特别的随机io其实是dba主要的优化策略。所以，在真正的实际应用中，覆盖索引是主要的提升性能的优化手段之一。

效率高。 索引列越多，通过索引筛选出的数据越少。有1000W条数据的表，有如下sql:select from table where col1=1 and col2=2 and col3=3,假设假设每个条件可以筛选出10%的数据，如果只有单值索引，那么通过该索引能筛选出1000W10%=100w条数据，然后再回表从100w条数据中找到符合col2=2 and col3= 3的数据，然后再排序，再分页；如果是联合索引，通过索引筛选出1000w10% 10% *10%=1w。

在模糊搜索中很有效，搜索全文中的某一个字段，可以参考这篇博文

: https://zhuanlan.zhihu.com/p/88275060

我们先进行下面一个实验看看InnoDB下的主键索引的一个现象。

查看:

我们插入进去的时候，数据的id都是乱序的，为什么这里最后select查询出来的结果都是进行了排序？

这是因为InnoDB索引底层实现的是B+tree，B+tree具有下列的特点：

所以上面的排序是为了使用B+tree的结构 ，B+tree为了范围搜索，将主键按照从小到大排序后，拆分成节点。后续还有新的节点进入的时候，和B-tree相同的 *** 作，会进行分裂。

一般来说，聚簇索引的B+tree都是三层

InnoDB中主键索引一定是聚簇索引，聚簇索引一定是主键索引。

为什么这里辅助索引叶子结点不直接存储数据呢？

MYISAM只有非聚簇索引，索引最终指向的都是物理地址。

Q:既然有回表的存在，那么聚簇索引的优势在哪里？

Q:主键索引作为聚簇索引需要注意什么

在查询语句中使用LIke关键字进行查询时，如果匹配字符串的第一个字符为"%"，索引不会使用。如果“%”不是在第一位，索引就会使用

多列索引是在表的多个字段上创建的索引，满足最左前缀匹配原则，索引才会被使用

查询语句只有Or关键字时候，如果OR前后的两个条件都是索引，这这次查询将会使用索引，否则Or前后有一个条件的列不是索引，那么查询中将不使用索引

LRU机制在实际运行过程中，是会存在巨大的隐患的：

MySQL的预读机制带来的隐患：所谓的预读机制，就是当你从磁盘加载一个数据页的时候，可能会连带着把这个数据页相邻的其它数据页也加载到缓存里去。

例如，现在有两个空闲的缓存页，然后在加载一个数据页的时候，连带着把他的一个相邻的数据页也加载到缓存里了，正好每个数据页放入一个空闲的缓存页。但是实际上只有一个缓存页被访问了，另外一个通过预读机制被加载进来的缓存页，其实并没有人访问，但是此时这两个缓存页都是放在LRU链表的前面。这个时候没有空闲的缓存页，如果要加载新的数据，就要把LRU链表队尾的缓存页刷入磁盘，而不是无人访问的那个缓存页。

会触发预读机制的场景：

为了解决简单的LRU链表的问题，MySQL在设计LRU链表的时候，实际上采取的是冷热数据分离的思想；之前的问题都是因为所有缓存页都混在了一个LRU链表中导致的。

真正的LRU链表，会被拆分成热数据和冷数据两个部分，冷热数据的比例是由innodb_old_blocks_pct参数控制的，默认是37，也就是说冷数据占比为37%。这个时候，LRU链表实际上看起来是下面这个样子的：

数据页第一次被加载到缓存的时候，其实是被放在冷数据链表的头部，后面1秒之后，如果你再次访问这个缓存页，那这个缓存页会被移动到热数据链表的头部，这个时间是有innodb_old_blocks_time这个参数控制的，默认1000ms。

也就是说，必须是一个数据页被加载到缓存页之后，在1s之后，你访问这个缓存页，他才会被挪动到热数据区域的链表头部去。

因为假设你加载了一个数据页到缓存去，然后过了1s之后你还访问了这个缓存页，说明你后续很可能会经常访问它，这个时间限制就是1s，因此只有1s后你访问了这个缓存页，他才会给你把缓存页放到热数据区域链表的头部去。

预读机制以及全表扫描加载进来的一大堆缓存页，他们会放在哪里？肯定是放在LRU链表的冷数据区域的前面，假设这个时候热数据区域已经有很多被频繁访问的缓存页了，你会发现热数据区域还是存放被频繁访问的缓存页的，只要热数据区域有缓存页被访问，他还是会被移动到热数据区域的链表头部去。

所以此时预读机制和全表扫描加载进来的一大堆缓存页，此时都在冷数据区域里，跟热数据区域里的频繁访问的缓存页，没有关系。

如果仅仅是全表扫描的查询，此时你肯定是在1s内就把一大堆缓存页加载进来，然后访问了这些缓存页一下，通常这些 *** 作1s内就结束了，所以基于目前的一个机制，可以确定的是，那些缓存页是不会从冷数据区域转移到热数据区域的。

除非在冷数据区域的缓存页，在1s之后还被访问了，那么此时他们就会判定为未来可能会被频繁访问的缓存页，然后移动到热数据区域的链表头部去。

假设此时缓存页不够用了，需要淘汰一些缓存页，此时会怎样？

直接就是可以找到LRU链表中的冷数据区域的尾部的缓存页，他们肯定是之前被加载进来的，而且加载进来1s过后都没人访问过，说明这个缓存页压根儿就没人愿意去访问他，他就是冷数据。所以此时就直接淘汰冷数据区域的尾部的缓存页，刷入磁盘就可以了。

之前提到如果一个缓存页被访问了，就会把他移动到LRU链表的热数据区域首位，这么频繁的移动会导致性能不是很好。所以MySQL对LRU链表热数据区域的访问规则做了优化，只有在热数据区域的后3/4部分的缓存页被访问了，才会被移动到链表头部；链表前面1/4的缓冲页被访问，是不会被移动的。

首先，并不是在缓存页满的时候，才会挑选LRU冷数据区域尾部的几个缓存页刷入磁盘，而是有一个后台线程，每隔一段时间就会把LRU链表的冷数据区域尾部的一些缓存页刷入磁盘，然后清空这几个缓存页，并把他们加入到free链表中。

所以大家会发现，只要有这个后台线程定时运行，可能你的缓存页都还没有用完呢，就给你把一批冷数据的缓存页刷入磁盘，清空出来一批缓存页，那么你就多了一批可以使用的空闲缓存页了。

如果仅仅只是把LRU链表中的冷数据区域的缓存页刷入磁盘，明显是不够的；

LRU链表中的热数据区域里的很多缓存页可能会被频繁的修改，这些数据不可能永远放在内存中，后台线程会在MySQL不繁忙的时候，把flush链表中的缓存页都刷入磁盘中，这样，被修改过的数据就被刷入到磁盘文件中了。

只要flush链表中的一些缓存页被刷入磁盘，那这些缓存页也会从flush链表和lru链表中移除，然后加入到free链表中。

所以，一边不停的加载数据到缓存页中，不停的查询和修改缓存数据，然后free链表中的缓存页不停的在减少，flush链表中的缓存页不停的在增加，lru链表中的缓存页不停的在增加和移动。

另外一边，后台线程不停的把LRU链表的冷数据区域的缓存页及flush链表的缓存页刷入到磁盘，来清空缓存页，然后flush链表和LRU链表中的缓存页不停的在减少，free链表中的缓存页在不停的增加。

如果实在没有空闲的缓存页，那就会把LRU链表冷数据区域尾部的缓存页刷入磁盘，然后清空。

---