mysql学习笔记图

描述：将128M的buffer pool按照每页16kb生成的一个空闲链表，
链表的每页通过指针指向buffer pool的空闲页，当有数据查到对应的buffer pool，
对应的空闲链表就会删除

头结点：链表的个数，最大个数128M/16KB

每次查询数据时，存到buffer pool的同时，也存到lru链表，
当buffer pool满了，通过lru中最近最少使用淘汰数据，淘汰链表最后的数据

前5/8热点数据：经常使用的数据，页的第一次查询与第二次查询大于1秒的数据

后3/8冷数据：不经常使用的数据

头结点：链表的个数

当buffer poll的数据页被更新后，这页的数据放入这个缓存区域

mysql后台有个定时任务到这个链表的脏页数据持久化

产生原因：如果并发很多，多个事务执行，每个事务都去修改buffer pool，每个事务对应的脏页都要去持久化，但是数据在磁盘的零散的，到处移动性能很差，速度慢，通过redolog存日志可以顺序IO执行，暂时不用去持久化，保证数据不丢失

innodb存储引擎拥有的回滚日志，数据页中的每个sql数据更新都会生成一个redolog，事务提交的时候才去持久化

logbuffer缓冲区

持久化策略（innodb_flush_log_at_trx_commit）

如何保证数据不丢：重启mysql时会去读取redolog日志，然后配合之前的老数据去恢复，恢复之后放入buffer pool，然后等待后台定时任务去执行持久化

两个日志文件：磁盘对应两个48M的磁盘区域，redolog最终都顺序IO持久化到这个空间

主要用于主从数据同步

持久化策略sync_binlog

主要用于回滚MVCC视图

Read Uncommitted（读取未提交内容）：在该隔离级别，所有事务都可以看到其他未提交事务的执行结果。本隔离级别很少用于实际应用，因为它的性能也不比其他级别好多少。读取未提交的数据，也被称之为脏读（Dirty Read）。

Read Committed（读取提交内容）：个事务只能看见已经提交事务所做的改变。这种隔离级别 也支持所谓的不可重复读（Nonrepeatable Read），因为同一事务的其他实例在该实例处理其间可能会有新的commit，所以同一select可能返回不同结果

Repeatable Read（可重读）：这是MySQL的默认事务隔离级别，它确保同一事务的多个实例在并发读取数据时，会看到同样的数据行。不过理论上，这会导致另一个棘手的问题：幻读 （Phantom Read）。简单的说，幻读指当用户读取某一范围的数据行时，另一个事务又在该范围内插入了新行，当用户再读取该范围的数据行时，会发现有新的“幻影” 行。InnoDB和Falcon存储引擎通过多版本并发控制（MVCC，Multiversion Concurrency Control）机制解决了该问题。

Serializable（可串行化）：这是最高的隔离级别，它通过强制事务排序，使之不可能相互冲突，从而解决幻读问题。简言之，它是在每个读的数据行上加上共享锁。在这个级别，可能导致大量的超时现象和锁竞争。

Propagation.REQUIRED：如果当前没有事务，就创建一个新事务，如果当前存在事务，就加入该事务，该设置是最常用的设置

Propagation.REQUIRES_NEW：创建新事务，无论当前存不存在事务，都创建新事务

Propagation.SUPPORTS：支持当前事务，如果当前存在事务，就加入该事务，如果当前不存在事务，就以非事务执行

Propagation.NOT_SUPPORTED：以非事务方式执行操作，如果当前存在事务，就把当前事务挂起

Propagation.MANDATORY：支持当前事务，如果当前存在事务，就加入该事务，如果当前不存在事务，就抛出异常

Propagation.NEVER：以非事务方式执行，如果当前存在事务，则抛出异常。

Propagation.NESTED：如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，则执行与PROPAGATION_REQUIRED类似的操作

row_id：行ID，MySQL的B+树索引特性要求每个表必须要有一个主键。如果没有设置的话，会自动寻找第一个不包含NULL的唯一索引列作为主键。如果还是找不到，就会在这个DB_ROW_ID上自动生成一个唯一值，以此来当作主键

trx_id：事务ID，记录的是当前事务在做INSERT或UPDATE语句操作时的事务ID（DELETE语句被当做是UPDATE语句的特殊情况）

roll_pointer：回滚指针，通过它可以将不同的版本串联起来，形成版本链。相当于链表的next指针

判断版本链中哪些版本对当前事务可见

版本链访问记录逻辑

MVCC只在读取已提交（Read Committed）和可重复读（Repeatable Read）两个事务级别下有效

所有未提交事务的ID数组和已经创建的最大事务ID组成，例如：[100,200],300。事务100和200是当前未提交的事务，而事务300是当前创建的最大事务（已经提交了）

读取已提交：每执行一次SELECT语句就会重新生成一份ReadView

可重复读：只会在第一次SELECT语句执行的时候会生成一份，后续的SELECT语句会沿用之前生成的ReadView（即使后面有更新语句的话，也会继续沿用）

DB_TRX_ID < min_id：这个版本比min_id还小（事务ID是从小往大顺序生成的），说明这个版本在SELECT之前就已经提交了，所以这个数据是可见的

DB_TRX_ID > max_id：表示这个版本是由将来启动的事务来生成的，当前还未开始，那么是不可见的

min_id <= DB_TRX_ID <= max_id

insert：事务提交后立即删除

update：需要支持MVCC，不会立即删除

delete：记录打删除标记（逻辑删除）

共享锁(S锁)：假设事务T1对数据A加上共享锁，那么事务T2可以读数据A，不能修改数据A；lock in share mode

排他锁(X锁): 假设事务T1对数据A加上排他锁，那么事务T2不能读数据A，不能修改数据A；for update

意向共享锁(IS锁): 一个事务在获取（任何一行/或者全表）S锁之前，一定会先在所在的表上加IS锁

意向排他锁(IX锁): 一个事务在获取（任何一行/或者全表）X锁之前，一定会先在所在的表上加IX锁

Record Locks：该锁是对索引记录进行加锁！锁是加在索引上而不是行上的。注意了，innodb一定存在聚簇索引，因此行锁最终都会落到聚簇索引上

Gap Locks：间隙锁，是对索引的间隙加锁，其目的只有一个，防止其他事物插入数据

Next-Key Locks：Record Lock+Gap Lock，锁住的是索引前面的间隙，实现锁表的操作

只有通过索引条件检索数据，InnoDB才使用行级锁，否则，InnoDB将使用表锁！

只在RR和Serializable中是成立的。如果隔离级别为RU和RC，无论条件列上是否有索引，都不会锁表，只锁行

两个或两个以上的进程在执行过程中,因争夺资源而造成的一种互相等待的现象,若无外力作用，它们都将无法推进下去.此时称系统处于死锁状态或系统产生了死锁

mysql自带的策略

人为的解决办法

lock table read/write

MDL(metadata lock)

myisan引擎不支持表级锁

全库备份时使用

B+树索引

HASH索引

FULL TEXT索引

聚族索引

非聚族索引

主键索引

唯一索引

单列索引

多列索引

binlog dump thread线程

I/O thread线程

SQL thread线程：当检测到中继日志有更新，就将更新的内容同步到slava数据库中

同步策略：master等所有的slave都回应后才提交，这个主从同步性能会严重受影响

半同步策略：master至少等待一个slave响应后才提交

异步策略：master不用等待slave响应就提交

延迟策略：slave要落后于master指定的时间

页作为磁盘和内存的交互单位

5.5版本后，mysql的默认存储引擎

应用场景：事务性，安全性操作较多的情况

不支持事务

不支持行级锁

不支持外键

应用场景：执行大量的select

数据存储在内存，表结构存储在磁盘，访问效率高

服务关闭，表中的数据会丢失