事务
脏读：一个事务读到了其他事务还没提交的数据
什么是丢失修改：ab事务都读取了数据，a事务先修改了数据，b事务后来也修改了数据，a事务的修改就被覆盖了
不可重复读：一个事务内会多次读取同一条数据，期间可能有其他数据修改了这条数据，导致事务a前后读到的数据不同
幻读：一个事务内多次读取数据返回的结果条数不一样
事务隔离级别：
读未提交
读已提交：解决脏读问题
可重复读：解决脏读、不可重复读问题
串行：解决脏读、不可重复度、幻读
可重复读：一个事务在执行过程中可以看到其他事务已经提交的新插入的记录（读已经提交的，其实是读早于本事务开始且已经提交的），但是不能看到其他事务对已有记录的更新（即晚于本事务开始的），并且，该事务不要求与其他事务是“可串行化”的。
可重复读实现原理：MVCC 多版本并发控制
实现原理：
undo log、
隐藏字段：
1、最后一次修改本行记录的事务id
2、回滚指针：指向之前生成的undo log
形成一个多版本链：如上图。
Read View：实现MVCC时用到的一致性读视图，就是对数据在某一时刻的状态拍成照片记录下来，之后获取数据就还是原来照片上的。
read view在事务第一次执行查询sql时，会先生成一个read view，查询时从undo log中最新的一条记录，一直往前找，找到符合比较条件的查询结果。比较条件就是如果获取到的事务id是已提交的事务就可读。
msql事务的持久性如何实现：
redo log会记录对数据库的所有修改，系统崩溃后可以恢复。redolog实现了事务的持久性，事务提交后会将所有日志都写入redo log进行持久化，如果崩溃时没提交就意味着直接回滚了
表级锁和行级锁有什么区别？
答：在事务隔离级别中串行使用的是表级锁。其他的隔离级别都是行级锁
共享锁：就是读数据时，加锁，可以重复加，此时不能再加排他锁
排他锁：写操作时获得，此时不能再获得任何锁
innodb支持哪几种锁？
行锁（即锁住一条记录）
表锁、
间隙锁（即锁定一个区间，左开右开）
Next-key锁（临键锁）：记录锁+间隙锁锁定的区间
1、唯一索引进行等值查询 & 查询的记录存在，临建锁会退化成行锁
2、唯一索引进行等值查询 & 查询的记录不存在，会退化成间隙锁，就是在这个值左右的，如果id=10不存在，就会锁（8，16），此时无法在8-16之间插入记录。
当前读和快照读的区别？
在锁定读的时候读到的是最新版本的数据，select for update
快照读，就是mvcc下读到的数据快照
用select for update 会让select语句产生一个排它锁(X), 这个锁和update的效果一样，会使两个事务无法同时更新一条记录。
mysql死锁的原因和处理方法：
排查：
1、正在运行的任务
show full processlist; 找到卡主的进程
2、解开死锁
UNLOCK TABLES ；
3、查看当前运行的事务
SELECT * FROM information_schema.INNODB_TRX;
4、当前出现的锁
SELECT * FROM information_schema.INNODB_LOCKS;
5、观察错误日志
6、查看InnoDB锁状态
show status like “innodb_row_lock%”;
索引
MyISAM使用的是B+树，但是叶子节点存储的是数据记录的地址，是非聚集索引。
InnoDB的叶子节点保存了完整的数据记录，这种叫聚集索引，且InnoDB必须有主键。
说一下B+树索引实现原理（数据结构）
非叶子节点记录区间，非叶子节点记录的是主键+页号，叶子节点保存数据记录，
叶子节点之间组成一个双向链表。
聚簇索引和非聚簇索引的区别？
非聚簇索引叶子节点存的是数据记录的地址，且没有双向链表。
聚簇索引叶子节点存的是数据记录，主键作为索引的值，只有是主键时才是聚簇索引。其他的索引都叫非聚簇索引。每页内的数据是按照主键排成一个单向链表。
聚簇索引的优点是查找快，节省了IO
缺点是更新主键的代价高，一般使用一个连续自增的字段做主键
B+树中聚簇索引的查找匹配逻辑：
从根节点的页里开始找，遍历页内的数据，匹配主键id，如果比他大，往右找，比他小往左找，拿到页号，再往下，中间的非叶子节点也是，遍历匹配，找到叶子节点后，直接取出记录
B+树中非聚簇索引的查找匹配逻辑：
从根页面开始，按个遍历页面内的记录，找到在某个区间内（也就是找到两个节点/页），从这两个节点里定位到具体的记录，但是这个非聚簇索引里没有全部的记录，所以要拿着主键id去主键索引中再查找一编。
什么是自适应哈希索引
是innodb的一个特殊功能，当某些索引值被使用地非常频繁，会在内存中，基于B-tree之上再创建一个哈希索引，这是一个完全自动的内部行为，用户无法控制。
索引的优缺点：
索引的优点就是查询快，查询范围时自带顺序，但是索引的创建是需要代价的，每建立一个索引就要建立一颗b+树，需要消耗内存空间。且每次删除、修改、都可能改变索引，需要时间去构建索引，给性能拖后腿。
mysql有个图：
自适应哈希 还有几个buffer的得找一下
日志
mysql有多少种日志
error log
慢查询log：记录超过long_query_time的sql，默认不开，会影响性能。
redo log
undo log
bin log
general log：记录了客户端连接信息以及执行的sql语句信息。
binlog：
记录增删改的sql，用于恢复、主从同步
redolog
数据修改之后的值，基于磁盘的数据结构，用来将mysql宕机时将不完整的事务进行数据纠正，redo log记录事务执行的状态。
undolog
数据修改之前的值，事务失败后的回滚、MVCC访问老版本的数据
binlog刷盘机制
由sync_binlog控制。
1、当sync_binlog=0时，每次提交会先写入page cache，在mysql崩溃时会有丢失日志的风险。
2、sync_binlog=1时，每次提交事务都会写入磁盘。强一致性。
3、sync_binlog>1时，每次提交会先写到page cache，当提交了n个事务时，才会写入磁盘。
redolog刷盘机制
innodb_flush_log_at_trx_commit
1、当等于0时，每秒触发一次缓存日志写入磁盘的操作。
2、当等于1时，有事务提交就立刻刷盘
3、当与等2时，每次事务提交就交给操作系统,每次都把redo log写到系统的page cache中，由操作系统接管什么时候写入磁盘。
时机顺序：
1、开启事务
2、查询数据库中需要更新的字段，加载到内存中形成数据脏页。
3、记录undo log到内存缓冲区，并关联redo log
4、记录redo log 到内存缓冲区，准备提交事务
5、修改内存中的脏页数据
6、提交事务触发redolog 刷盘
7、undo log和脏页刷盘
8、事务成功
