文章目录
- 一个事务查询范围,另一个事务插入数据,会发生什么
- 最左匹配原则
- explain 语句的关键点以及 ES 分析语句性能的关键字
- Type：表示从表中查询到行所执行的方式
- Key 字段
- Extra字段
- 为什么使用 B+ 树
- bignlog ,dolog,redo log 的区别
- MYSQL(5.6) 索引下推
一个事务查询范围,另一个事务插入数据,会发生什么
mysql 事务不加锁一致性读：当事务隔离级别为可重复读时，事务A进行查询，事务B进行改、删除、插入时，进行查询的事务A不受事务B的影响，仍然为原始数据库中的数据，即使事务A内对数据做了更改会提交，事务A查询到的仍然为事务开始之前数据库中的数据；当事务隔离级别为读提交时，事务A会读取事务A内的最新提交的数据，如果事务B对事务有更改或提交新数据，不会影响事务A的查询数据。
最左匹配原则
MySQL建立联合索引时会遵守最左前缀匹配原则，即最左优先，在检索数据时从联合索引的最左边开始匹配。
可以看到 a 的值是有顺序的，1，1，2，2，3，3，而b的值是没有顺序的1，2，1，4，1，2。但是我们又可发现 a 在等值的情况下，b 值又是按顺序排列的，但是这种顺序是相对的。这是因为MySQL创建联合索引的规则是首先会对联合索引的最左边第一个字段排序，在第一个字段的排序基础上，然后在对第二个字段进行排序。所以b=2这种查询条件没有办法利用索引。
explain 语句的关键点以及 ES 分析语句性能的关键字
MySQL explain 应用详解(吐血整理🤩)
关键点：
- rows：扫描行
- type：访问的类型
- key：实际使用到的索引，如果为 null ，则没有使用索引
Type：表示从表中查询到行所执行的方式
（从左往右，越靠左边的越优秀）
NULL > system > const > eq_ref > ref > ref_or_null > index_merge > range > index > ALL
分别解读一下：
- system：表只有一行记录
-
const表示通过索引一次就找到了，const 用于比较 primary key 或 uique 索引，因为只匹配一行数据，所以很快，如主键置于 where 列表中，MySQL 就能将该查询转换为一个常量。 -
eq_ref：使用唯一索引扫描，常见于多表连接中使用主键和唯一索引作为关联条件。 -
ref：非唯一索引扫描，还可见于唯一索引最左原则匹配扫描。 - range：索引范围扫描，比如，<，>，between 等操作。
-
index：index只遍历索引树，通常比All快。因为，索引文件通常比数据文件小，也就是虽然all和index都是读全表，但index是从索引中读取的，而all是从硬盘读的。 - ALL：如果一个查询的 type 是 All ,并且表的数据量很大，那么请解决它！！！
Key 字段
实际使用的索引，如果为 null,则没有使用索引，否则会显示你使用了哪些索引，查询中若使用了覆盖索引（查询的列刚好是索引），则该索引仅出现在 key 列表。
Extra字段
- using index: Extra 字段里面多了“Using index”，表示的就是使用了覆盖索引, 不需要回表
- using index condition: 索引下推；先条件过滤索引；
- using where: 服务器Server层收到存储引擎返回的数据之后，会再根据 where 条件进行过滤
- using filesort: 排序用到了临时文件
- using temporary: 用到了临时表，这样的查询效率是比外部排序更低的，常见于 order by 和 group by。
为什么使用 B+ 树
树可以有二叉，也可以有多叉。多叉树就是每个节点有多个儿子，儿子之间的大小保证从左到右递增。二叉树是搜索效率最高的，但是实际上大多数的数据库存储却并不使用二叉树。其原因是，索引不止存在内存中，还要写到磁盘上。
你可以想象一下一棵100万节点的平衡二叉树，树高20。一次查询可能需要访问20个数据块。在机械硬盘时代，从磁盘随机读一个数据块需要10 ms左右的寻址时间。也就是说，对于一个100万行的表，如果使用二叉树来存储，单独访问一个行可能需要20个10 ms的时间，这个查询可真够慢的。
为了让一个查询尽量少地读磁盘，就必须让查询过程访问尽量少的数据块。那么，我们就不应该使用二叉树，而是要使用“N叉”树。这里，“N叉”树中的“N”取决于数据块的大小。
[ 数据库索引 ] B树和B+树
bignlog ,dolog,redo log 的区别
MYSQL(5.6) 索引下推
