做租赁的行业网站,腾讯云服务器用什么做网站,用ps做网站的首页,四川建设信息共享网站前一篇讲完了查询流程#xff0c;我们是不是再讲讲更新流程、插入流程和删除流程#xff1f;在数据库里面#xff0c;我们说的update操作其实包括了更新、插入和删除。如果大家有看过MyBatis的源码#xff0c;应该知道Executor里面也只有doQuery()和doUpdate()的方法#…前一篇讲完了查询流程我们是不是再讲讲更新流程、插入流程和删除流程在数据库里面我们说的update操作其实包括了更新、插入和删除。如果大家有看过MyBatis的源码应该知道Executor里面也只有doQuery()和doUpdate()的方法没有doDelete()和doInsert()。
更新流程和查询流程有什么不同呢基本流程也是一致的也就是说它也要经过解析器、优化器的处理最后交给执行器。区别就在于拿到符合条件的数据之后的操作。
缓冲池 Buffer Pool
首先InnnoDB的数据都是放在磁盘上的InnoDB操作数据有一个最小的逻辑单位叫做页索引页和数据页。我们对于数据的操作不是每次都直接操作磁盘因为磁盘的速度太慢了。 InnoDB使用了一种缓冲池的技术也就是把磁盘读到的页放到一块内存区域里面。这个内存区域就叫Buffer Pool。 下一次读取相同的页先判断是不是在缓冲池里面如果是就直接读取不用再次访问磁盘。
修改数据的时候先修改缓冲池里面的页。内存的数据页和磁盘数据不一致的时候我们把它叫做脏页。InnoDB里面有专门的后台线程把Buffer Pool的数据写入到磁盘每隔一段时间就一次性地把多个修改写入磁盘这个动作就叫做刷脏。 BufferPool是InnoDB里面非常重要的一个结构它的内部又分成几块区域。这里我们趁机到官网来认识一下InnoDB的内存结构和磁盘结构。 1.Innodb 内存结构
Innodb的内存结构主要分为 3 个部分 Buffer Pool、Change Buffer、Adaptive HashIndex另外还有一个redolog buffer。
1.1 Buffer Pool
Buffer Pool缓存的是页面信息包括数据页、索引页。
SHOW STATUS LIKE %innodb_buffer_pool%; -- 查看服务器状态中 Buffer Pool 相关信息
SHOW VARIABLES like %innodb_buffer_pool%; -- 查看参数系统变量这些状态都可以在官网查到详细的含义用搜索功能。 Buffer Pool默认大小是128M134217728字节可以调整。
内存的缓冲池写满了怎么办Redis 设置的内存满了怎么办InnoDB 用 LRU算法来管理缓冲池链表实现不是传统的LRU分成了young和old经过淘汰的数据就是热点数据。
内存缓冲区对于提升读写性能有很大的作用。思考一个问题当需要更新一个数据页时如果数据页在BufferPool中存在那么就直接更新好了。否则的话就需要从磁盘加载到内存再对内存的数据页进行操作。也就是说如果没有命中缓冲池至少要产生一次磁盘IO有没有优化的方式呢
1.2 Change Buffer写缓冲
如果这个数据页不是唯一索引注唯一索引就是在同一字段下不能有相同值也就不需要从磁盘加载索引页判断数据是不是重复唯一性检查。这种情况下可以先把修改记录在内存的缓冲池中从而提升更新语句Insert、Delete、Update的执行速度。这一块区域就是 Change Buffer。5.5 之前叫Insert Buffer 插入缓冲现在也能支持delete和update。最后把 Change Buffer 记录到数据页的操作叫做 merge。
什么时候发生 merge有几种情况在访问这个数据页的时候或者通过后台线程、或者数据库shut down、redo log写满时触发。
如果数据库大部分索引都是非唯一索引并且业务是写多读少不会在写数据后立刻读取就可以使用Change Buffer写缓冲。写多读少的业务调大这个值
SHOW VARIABLES LIKE innodb_change_buffer_max_size;max_size 代表Change Buffer占Buffer Pool的比例默认25%。
1.3 Adaptive Hash Index
索引应该是放在磁盘的为什么要专门把一种哈希的索引放到内存这里就不说了把问题的答案放在详谈索引存储结构推演过程…
1.4 Log BufferRedo log
MySQL 在更新数据时为了减少磁盘的随机 IO因此并不会直接更新磁盘上的数据而是先更新 Buffer Pool 中缓存页的数据等到合适的时间点再将这个缓存页持久化到磁盘。而 Buffer Pool 中所有缓存页都是处于内存当中的当 MySQL 宕机或者机器断电内存中的数据就会丢失因此 MySQL 为了防止缓存页中的数据在更新后出现数据丢失的现象引入了 redo log 机制。
当进行增删改操作时MySQL 会在更新 Buffer Pool 中的缓存页数据时会记录一条对应操作的 redo log 日志这样如果出现 MySQL 宕机或者断电时如果有缓存页的数据还没来得及刷入磁盘那么当 MySQL 重新启动时可以根据 redo log 日志文件进行数据重做将数据恢复到宕机或者断电前的状态保证了更新的数据不丢失因此 redo log 又叫做重做日志。它的本质是保证事务提交后更新的数据不丢失。——用它来实现事务的持久性。 这种日志和磁盘配合的整个过程其实就是 MySQL 里的 WAL 技术Write-Ahead Logging它的关键点就是先写日志再写磁盘。
同样是写磁盘为什么不直接写db file而是先写日志
我们先来了解一下随机I/O和顺序I/O的概念。磁盘的最小组成单元是扇区通常是512个字节。操作系统和内存打交道最小的单位是页Page。操作系统和磁盘打交道读写磁盘最小的单位是块Block。 如果我们所需要的数据是随机分散在不同页的不同扇区中那么找到相应的数据需要等到磁臂旋转到指定的页然后盘片寻找到对应的扇区才能找到我们所需要的一块数据一次进行此过程直到找完所有数据这个就是随机IO读取数据速度较慢。
假设我们已经找到了第一块数据并且其他所需的数据就在这一块数据后边那么就不需要重新寻址可以依次拿到我们所需的数据这个就叫顺序IO。
刷盘是随机I/O而记录日志是顺序I/O顺序I/O效率更高。所以先不断把内存中bufferpool的数据修改写入日志保证不会丢失然后等到一个适当的时机系统比较空闲将操作记录更新到磁盘里面。达到延迟刷盘时机的目的进而提升系统吞吐。redo log存在的意义主要就是降低对数据页刷盘的要求。
redo log重做日志有什么特点 redo log是InnoDB存储引擎实现的并不是所有存储引擎都有。 不是记录数据页更新之后的状态某一行或某几行修改成怎样怎样而是记录当前页做了什么改动属于物理日志。它用来恢复提交后的物理数据页(恢复数据页且只能恢复到最后一次提交的位置) 日志分为物理日志和逻辑日志。 物理日志就是直接记录数据记录被修改的page的偏移量优点就是不依赖原page的内容用日志的内容可以直接覆盖到磁盘上面而缺点就是占用的空间太多比如新增一个btree索引或者一个update操作。逻辑日志只是记录关系表上面的元操作比如update一行数据delete一行数据等优点就是比较简洁而且占用的空间要小缺点就是需要依赖原page内容而且会有部分执行和操作一致性的问题。 redo log 分成内存和磁盘两部分 内存部分Log Buffer存在刷盘操作。磁盘部分对应于 /var/lib/mysql/目录下的ib_logfile0和ib_logfile1每个48M。 因为redo log 实际上记录数据页的变更而这种变更记录是没必要全部保存所以 redo log 的大小是固定的前面的内容会被覆盖。如下图所示 再强调一次redo log的内容主要是用于崩溃恢复。磁盘的数据文件数据来自 buffer pool。redo log 写入磁盘不是写入数据文件。
redo log 的内存部分Log Buffer
当然redo log也不是每一次都直接写入磁盘在Buffer Pool里面有一块内存区域Log Buffer专门用来保存即将要写入日志文件的数据Innodb_log_buffer默认大小为8M它一样可以节省磁盘IO。
SHOW VARIABLES LIKE innodb_log_buffer_size;那么Log Buffer什么时候写入log file或者说什么日志什么时候刷盘
在我们写入数据到磁盘的时候操作系统本身是有缓存的。flush就是把操作系统缓冲区写入到磁盘。log buffer写入磁盘的时机由一个参数控制默认是1。
值含义0延迟写logbuffer 将每秒一次地写入 logfile 中并且 logfile 的 flush 操作同时进行。 该模式下在事务提交的时候不会主动触发写入磁盘的操作。1默认实时写实时刷每次事务提交时 MySQL 都会把 logbuffer 的数据写入 logfile并且刷到磁盘中去。2实时写延迟刷每次事务提交时 MySQL 都会把 logbuffer 的数据写入 logfile。但是 flush 操作并不会同时进行。该模式下MySQL 会每秒执行一次 flush 操作。SHOW VARIABLES LIKE innodb_flush_log_at_trx_commit;以上就是MySQL的内存结构。总结一下分为Buffer pool、change buffer、Adaptive Hash Index、 log buffer。
2.Innodb 磁盘结构表空间
磁盘结构里面主要是各种各样的表空间叫做Table space。表空间可以看做是 InnoDB 存储引擎逻辑结构的最高层所有的数据都存放在表空间中。InnoDB的表空间分为5大类。
2.1 system tablespace系统表空间
在默认情况下 InnoDB 存储引擎有一个共享表空间对应文件/var/lib/mysql/ibdata1也叫系统表空间。 InnoDB系统表空间包含InnoDB数据字典和双写缓冲区ChangeBuffer和UndoLogs如果没有指定file-per-table也包含用户创建的表和索引数据。
undo在后面介绍因为有独立的表空间。数据字典由内部系统表组成存储表和索引的元数据定义信息。双写缓冲InnoDB的一大特性InnoDB的页和操作系统的页大小不一致InnoDB页大小一般为16K操作系统页大小为4KInnoDB的页写入到磁盘时一个页需要分4次写。如果存储引擎正在写入页的数据到磁盘时发生了宕机可能出现页只写了一部分的情况比如只写了4K就宕机了这种情况叫做部分写失效partial page write可能会导致数据丢失。
show variables like innodb_doublewrite;我们不是有 redo log 吗但是有个问题如果这个页本身已经损坏了用它来做崩溃恢复是没有意义的。所以在对于应用redo log之前需要一个页的副本。如果出现了写入失效就用页的副本来还原这个页然后再应用redo log。这个页的副本就是 double writeInnoDB的双写技术。通过它实现了数据页的可靠性。
跟 redo log 一样double write 由两部分组成一部分是内存的double write一个部分是磁盘上的double write。因为double write是顺序写入的不会带来很大的开销。在默认情况下所有的表共享一个系统表空间这个文件会越来越大而且它的空间不会收缩。
2.2 file-per-table tablespaces独占表空间
我们可以让每张表独占一个表空间。这个开关通过innodb_file_per_table设置默认开启。
SHOW VARIABLES LIKE innodb_file_per_table;开启后则每张表会开辟一个表空间这个文件就是数据目录下的 ibd文件例如 /var/lib/mysql/forum/user_innodb.ibd存放表的索引和数据。
但是其他类的数据如回滚undo信息插入缓冲索引页、系统事务信息二次写缓冲Double write buffer等还是存放在原来的共享表空间内。
2.3 general tablespaces通用表空间
通用表空间也是一种共享的表空间跟ibdata1类似。可以创建一个通用的表空间用来存储不同数据库的表数据路径和文件可以自定义。语法
create table space ts2673 add datafile /var/lib/mysql/ts2673.ibd file_block_size16K engineinnodb;在创建表的时候可以指定表空间用ALTER修改表空间可以转移表空间。
create table t2673(idinteger) tablespace ts2673;不同表空间的数据是可以移动的。删除表空间需要先删除里面的所有表
drop table t2673;
drop tablespace ts2673;2.4 temporary tablespaces临时表空间
存储临时表的数据包括用户创建的临时表和磁盘的内部临时表。对应数据目录下的ibtmp1文件。当数据服务器正常关闭时该表空间被删除下次重新产生。
2.5 undo log tablespace
undo log撤销日志或回滚日志记录了事务发生之前的数据状态不包括select 。用来保证在必要时实现回滚如果另一个事务需要在一致性读操作中查看原始数据则从undo日志记录中检索未修改的数据也就是说MVCC机制也依赖于undo log来实现。在执行 undo 的时候仅仅是将数据从逻辑上恢复至事务之前的状态而不是从物理页面上操作实现的属于逻辑格式的日志。
redo Log 和 undo Log 与事务密切相关统称为事务日志。但与redo log不同的是
redo log 是存储的是物理日志undo log存储的是逻辑日志redo log 是重做日志提供 前滚 操作undo log 是回退日志提供 回滚 操作。undo 是在事务开始之前保存的被修改数据的一个版本产生undo日志的时候同样会伴随类似于保护事务持久化机制的 redo log 的产生。 Redo 记录某 数据块 被修改 后 的值可以用来恢复未写入 data file 的已成功事务更新的数据。-- 保证事务持久性Undo 记录某 数据 被修改 前 的值可以用来在事务失败时进行 rollback-- 保证事务原子性 比如某一时刻数据库 DOWN 机了有两个事务一个事务已经提交另一个事务正在处理。数据库重启的时候就要根据日志进行前滚及回滚把已提交事务的更改写到数据文件未提交事务的更改恢复到事务开始前的状态。 当数据 crash-recovery 时通过 redo log 将所有已经在存储引擎内部提交的事务应用 redo log 恢复所有已经 prepared 但是没有 commit 的 transactions 将会应用 undo log 做 roll backundo Log 的数据默认在系统表空间ibdata1 文件中因为共享表空间不会自动收缩也可以单独创建一个undo表空间。 update过程分析
有了这些日志之后我们来总结一下一个更新操作的流程这是一个简化的过程name原值是zhangsan。
update user set namepenyuyan where id1;1. 事务开始从内存或磁盘取到这条数据返回给Server 的执行器
2. 执行器修改这一行数据的值为penyuyan
3. 记录 namezhangsan 到 undo log
4. 记录 namepenyuyan 到 redo log
5. 调用存储引擎接口在内存Buffer Pool中修改 namezhangsan
6. 事务提交另外内存和磁盘之间工作着很多后台线程。后台线程的主要作用是负责刷新内存池中的数据和把修改的数据页刷新到磁盘。后台线程分为master threadIO threadpurge threadpage cleaner thread。 master thread负责刷新缓存数据到磁盘并协调调度其它后台进程IO thread分为 insert buffer、 log、 read、 write进程。分别用来处理 insert buffer、重做日志、读写请求的IO回调purge thread用来回收undo 页page cleaner thread用来刷新脏页除了 InnoDB 架构中的日志文件MySQL 的 Server 层也有一个日志文件叫做binlog它可以被所有的存储引擎使用。 binlog 以事件的形式记录了所有的DDL和DML语句因为它记录的是操作而不是数据值属于逻辑日志可以用来做主从复制和数据恢复。跟redo log不一样它的文件内容是可以追加的没有固定大小限制。 在开启了binlog功能的情况下我们可以把binlog导出成SQL语句把所有的操作重放一遍来实现数据的恢复。binlog的另一个功能就是用来实现主从复制它的原理就是从服务器读取主服务器的binlog然后执行一遍。 参考链接对比总结三大日志重做日志redo log回滚日志undo log二进制日志binlog 有了这两个日志之后我们来看一下一条更新语句是怎么执行的
update teacher set name盆鱼宴 where id11. 先查询到这条数据如果有缓存也会用到缓存。
2. 把name改成盆鱼宴然后调用引擎的API接口写入这一行数据到内存同时记录redo log。这时 redo log 进入prepare 状态然后告诉执行器执行完成了可以随时提交。
3. 执行器收到通知后记录binlog然后调用存储引擎接口 设置redolog为commit状态。
4. 更新完成。需要特别注意的几点
先记录到内存再写日志文件。记录redo log分为两个阶段。存储引擎和Server记录不同的日志先记录redo再记录binlog。总结脑图
