牛商网营销型网站多少钱,wordpress小说网站模板,天眼网查个人,济南网站制作案例typora-copy-images-to: imgs
了解 MVCC 吗#xff1f;
答#xff1a;
MVCC#xff08;Multi-Version Concurrency Control#xff09; 是用来保证 MySQL 的事务隔离性的#xff0c;对一行数据的读和写两个操作默认是不会通过加锁互斥来保证隔离性#xff0c;避免了频…
typora-copy-images-to: imgs
了解 MVCC 吗
答
MVCCMulti-Version Concurrency Control 是用来保证 MySQL 的事务隔离性的对一行数据的读和写两个操作默认是不会通过加锁互斥来保证隔离性避免了频繁加锁互斥而在串行化隔离级别为了保证较高的隔离性是通过将所有操作加锁互斥来实现的。
MySQL 在读已提交和可重复读隔离级别下都实现了 MVCC 机制ReadView 生成规则为
在读已提交隔离级别下ReadView 生成的时机是每个 Select 生成一个 ReadView在可重复读隔离级别下ReadView 生成的时机是每个事务生成一个 ReadView
MVCC 是基于 undolog、版本链、readview 实现的。
在每次更新或者删除数据时都会将操作记录在 undo 日志中每条 undo 日志 通过 roll_pointer 进行关联构成了数据的版本链
ReadView 中包含以下参数
m_ids表示生成 ReadView 时当前系统中活跃未提交的事务 id 数组min_trx_id表示生成 ReadView 时当前系统中活跃的事务中最小的事务 id也就是 m_ids 中的最小值max_trx_id表示生成 ReadView 时已经创建的最大事务 id事务创建时事务 id 是自增的creator_trx_id表示生成 ReadView 的事务的事务 id
那么在事务里的 sql 查询会和 ReadView 进行对比来判断是否取该行的数据
如果 row 的 trx_id min_trx_id表示这一行数据的事务 id 比 ReadView 中活跃事务的最小 id 还要小表示这行数据是已提交事务生成的因此该行数据可见如果 row 的 trx_id max_id表示这一行数据是由将来启动的事务生成的不可见如果 row 的 trx_id 就是当前事务自己的 id则可见如果 row 的 min_id trx_id max_id则有两种情况 如果 trx_id 在 ReadView 的活跃事务 id 数组m_ids中则表明该事务还未提交则该行数据不可见如果不在则表明该事务已经提交可见
注意
执行 start transaction 之后并不会立即生成事务 id而是在该事务中第一次修改 InnoDB 时才会为该事务生成事务 idMVCC 机制就是通过 ReadView 和 undo 日志进行对比拿到当前事务可见的数据
了解 BufferPool 缓存机制吗
参考:
https://blog.csdn.net/mingyuli/article/details/120347093
https://www.processon.com/view/6080de691e08534b2ef0218b
答
Buffer Pool 本质就是数据库的一个内存组件Buffer Pool 的大小在 /etc/my.cnf 中进行配置
为什么不直接更新磁盘上的数据而是需要设置一套复杂的机制来执行 SQL 呢
因为针对数据库数据的读写其实是随机的读写而对于日志文件的读写是顺序的读写而顺序读写和随机读写速度差距在 2~3 个数量级磁盘的顺序 IO 几乎可以和操作内存相媲美。
通过 BufferPool 可以保证每个更新请求都是更新内存 BufferPool然后顺序写日志文件同时可以保证各种异常情况下的数据一致性正是通过这套配置才能让我们的 MySQL 数据库在较高配置的机器上每秒可以抗下几千的读写请求
为什么数据库数据的读写是随机 IO 呢
因为数据库存储在磁盘中的数据是会被删除的我们在写的时候就算一直顺序写但是如果后边删除了中间的一些数据那么在之后读就不能顺序读了因为中间有一些数据已经不存在了
InnoDB SQL 执行流程 加载数据页把需要修改数据所在的数据页缓存到 BufferPoolBufferPool 中缓存的其实就是一个个的数据页 修改前记录写 undo 日志记录更改前数据如果事务执行失败使用 undo 日志进行数据回滚 更新 Buffer Pool 中的数据 准备提交事务写 redo 日志保存操作记录。redo 日志用来恢复 BufferPool 中的数据 准备提交事务写 bin-log 日志保存操作记录。bin-log 日志用来恢复磁盘数据 事务提交完成此时 bin-log 日志写入成功并在 redo 日志中记录 commit 标记 redo 日志作用恢复 BufferPool 中的数据bin-log 日志是用于恢复磁盘中的数据其中 redo 日志和 undo 日志是 InnoDB 引擎特有的而 bin-log 是属于 Server 层的与引擎无关 在 redo 日志中记录 commit 标记是为了保证事务提交之后redo 与 binlog 数据一致那么想一下如果 BufferPool 缓存中数据更新完毕但是在数据库将修改后的数据刷到磁盘之前数据库宕机了会不会造成 BufferPool 和磁盘的数据不一致呢 其实不会因此当数据库宕机恢复之后会使用 redo 日志中的数据恢复 BufferPool 中的数据那么 BufferPool 的数据就是更新后的数据了等待刷回磁盘即可 数据持久化IO 线程不定期把 Buffer Pool 中的数据随机写入到磁盘完成持久化
MySQL 的预读机制
当从磁盘上加载一个数据页时MySQL 可能会连带着把这个数据页相邻的其他数据页也加载到缓存里去。
触发 MySQL 的预读机制的场景 线性预读参数 innodb_read_ahead_threshold 默认值是 56表示如果顺序的访问了一个区里的多个数据页访问的数据页的数量超过了这个阈值就会触发预读机制把下一个相邻区中的所有数据页都加载到缓存里去 查看默认值show variables like innodb_read_ahead_threshold 随机预读如果 Buffer Pool 里缓存了一个区里的 13 个连续的数据页而且这些数据页都是比较频繁会被访问的此时就会直接触发预读机制把这个区里的其他的数据页都加载到缓存里去。性能不稳定在 5.5 中已经被废弃默认是 OFF show variables like innodb_random_read_ahead
LRU 优化——冷热分离 MySQL 通过使用 LRU 来判断哪些缓存页经常访问哪些缓存页不常访问来判断当 BufferPool 缓存被占满之后去淘汰哪些缓存页。
在 MySQL 的 LRU 链表中采取了 冷热数据分离的思想 LRU 链表被拆为了两部分一部分是热数据一部分是冷数据冷数据默认占比 37%由 innodb_old_blocks_pct 参数控制 查看参数show variables like innodb_old_blocks_pct默认是37 原理数据页第一次被加载到缓存页之后这个缓存页被放在 LRU 链表的冷数据区域的头部在 1s可配置 之后如果这个缓存页再次配访问该缓存页才会被移动到热数据区域的头部。 查看参数show variables like innodb_old_blocks_time 默认是 1000 毫秒配置多长时间之后访问该缓存页才将该缓存页加入热数据区域头部 为什么 LRU 要进行冷热分离
如果不这样优化在 LRU 只使用一个链表那么在预读机制中多加载的一些缓存页可能就在刚加载进缓存时使用一下之后就不再使用了如果被放在 LRU 链表头部了会将频繁访问的缓存页挤在 LRU 链表尾部最后被淘汰。预读机制和全表扫描加载进来的一大堆缓存页此时都在冷数据区域里跟热数据区域里的频繁访问的缓存页时没有关系的。
LRU 中热数据区域访问的一些优化
一般在热数据区域头部的缓存页可能是经常被访问的所以频繁移动性能不太好所以 MySQL 对于热数据区域的访问优化了一下只有在热数据区域的后 3/4 部分的缓存页被访问了才会被移动到链表头部去这样就
不会出现链表头部数据频繁交替访问导致频繁移动链表头部数据。
什么时间将缓存页刷入磁盘呢
会有一个后台线程运行定时任务定时将 LRU 链表的冷数据区域尾部的一些缓存页刷入磁盘里去清空这几个缓存页将他们加入到 free 链表中free 链表存放的就是 BufferPool 中的空缓存页的地址
并且这个后台线程也会在 MySQL 空闲时将 flush 链表flush 链表存放的是 BufferPool 中被修改过的缓存页也称为脏页脏页都是需要刷回磁盘的中的缓存页都刷入磁盘中
