mysql基础问题
mysql 事务隔离级别
- 读未提交
- 读已提交
- 可重复度
- 串行化（每个读操作都加锁）
为什么要用可重复读
废话，我如果在一个事务中，两次查询的结果不一致，那我到底以哪个结果作为基准来执行我的程序
mysql知识进阶
什么是当前读
当前读，顾名思义 读当前最新的数据
比如说我们平时用到的 【update,delete,insert,for update,lock in share mode】都是当前读
读取的时候还会对当前的数据进行加锁，防止别的事务对当前数据进行修改。
（其实不光会对当前数据进行加锁处理，有时候还会将某个间隙进行加锁，也就是间隙锁，下面再讲）
什么是 快照读
快照，快照，这个名字多熟悉，故名思义，就是对某个时刻的某些数据的缓存。
mysql 中不加锁的select就是快照读 比如 select * from tab where name = '小二'
mysql中 快照读代表着 事务只能看到当前事务可以看到的数据，并不一定能看到最新的数据。
mysql 的快照读实现了 读已提交和可重复度两种模式
为什么要用快照读
因为他快啊 。
想比较与加锁的操作，快照读是 不加锁的非阻塞读，能够有效的提高并发性能。
不加锁====降低开销
快照读是怎么实现的
mysql实现了mvcc（多版本并发控制），在查询的时候会生成一个readview，
readview中包含当前活跃的事物和一些其他数据，mysql 会通过对比来查询出当前事务可以看到的数据。
简单来说是通过乐观锁的方式来实现的，因为 除了悲观锁 剩下的都是乐观锁实现
一句话概括就是这么简单
具体如何实现，下面再讲
mvcc的实现原理
MVCC原理
这个文章写的太好了，就没必要写了。
可重复度和读已提交在mvcc中的区别是什么
其实mvcc的实现原理已经看明白的话 这个问题很简单
两者的区别其实就是 readview的生成规则不一样
想想一下如果 readview是每一次查询的时候都生成一次，那不就是读已提交
间隙锁是干嘛的
想象这么一个场景：
#表结构：
CREATE TABLE `user` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`age` int(2) DEFAULT NULL,
`sex` int(1) NOT NULL DEFAULT '0',
PRIMARY KEY (`id`),
KEY `age` (`b`)
) ENGINE=InnoDB;
#数据
INSERT INTO `user` (`id`, `age`, `sex`) VALUES ('1', '18', '0');
INSERT INTO `user` (`id`, `age`, `sex`) VALUES ('1', '20', '0');
INSERT INTO `user` (`id`, `age`, `sex`) VALUES ('1', '22', '0');
INSERT INTO `user` (`id`, `age`, `sex`) VALUES ('1', '30', '0');
INSERT INTO `user` (`id`, `age`, `sex`) VALUES ('1', '31', '0');
INSERT INTO `user` (`id`, `age`, `sex`) VALUES ('1', '32', '0');
#索引树
在一个事务中（可重复读场景下）有以下两个sql
select * from user where age = 22 for update;(name有索引)
中间隔了5s
select * from user where age = 22 for update;(name有索引)
中所周知，mysql会锁定age = 22的数据
在只有行级锁的情况下能保证我第二次查询的时候也只有1条数据吗
答案是不能！！！
因为 我可能将其他数据的age修改为22
这样不就违背了 可重复读的初衷了
间隙锁就是来解决这个事情的
间隙锁会锁住name的索引树 小二的两侧的间隙（见下图）
这样别的update/insert/delete操作就无法进行，
这样就保证了 可重复读
mysql 优化
前述：mysql的优化建立在对索引结构B+树了解的前提下
自己找资料吧
什么是回表
了解回表就必须了解
聚集索引（主键索引）B+树叶子结点储存的是 行数据
非聚集索引（普通索引）B+树叶子结点存储的是 主键id
比如说 select b from tab where a = '123';(b 有索引)
那么这个查询就会设计到回表
查询过程：
第一步：
去b的索引树查找符合a=‘123’的数据，最终查找到，但是查到的是一个主键id
第二步：
拿着主键id去主键索引树 查询该id的数据
这就是回表，总共进行了两次索引树的查询
回表怎么处理
回表的解决办法就是 建立组合索引
建立 a和b的组合索引
这样在查询的时候在第一次搜索索引树的过程中也有b的信息，自然就不需要第二次查询了
范围查询必然会不走索引吗（between and，in 。。。）
不一定
如果范围较小 会走索引
范围较大，mysql分析器 分析出来该sql走索引的代价比全表代价还大，就直接不走索引了。
说说对最左前缀原则的理解
通过索引树就比较好理解了 组合索引 a和b和c的话在索引树中是这样的结构
在是先通过a来排序的，如果你先用b是无法来进行操作的。
什么是索引下推
索引下推index condition pushdown（ICP）
比如说一个sql
SELECT * from tab where a like '123%' and b=1
a和b是组合索引
根据最左匹配原则 遇到非等值判断时匹配会停止
那所以：
就只有 a可以用上索引
这样的索引查询步骤是：
第一步：
现在索引树查找到 like 123%的所有的数据的 主键id
第二部：
拿着主键id 去主键索引树查询相应数据
最后对比age
到此结束
but····························
上面的那个匹配原则其实都是5.5或者5.5之前版本的问题
5.6之后的版本没有这样的问题，就是通过索引下推解决的
有了索引下推之后就只查询一次索引树：
第一步：
现在索引树查找到 like 123%的数据 并对比 age的值
到此结束