注意：[]该系列是关于MySQL容易忽略的一些知识点。通过审查和补充，您还可以根据审查和补充来更系统地学习MySQL，以便更轻松地工作。
在[MySQL检查Dispome演示]系列中，学习了SQL查询语句的执行过程，并引入了执行过程中涉及的处理模块。回头看，查询语句的执行过程通常是通过函数模块（例如）连接器，分析仪，优化器和执行器，最后到达存储引擎。
那么，更新语句的执行过程是什么？
在执行SQL查询语句期间，我们学习了SQL语句的基本执行链接。在这里，我将在这里拍照。您还可以简要介绍一下此图片进行评论。首先，可以确定查询语句的过程也将再次进行。
在执行语句之前，您必须连接数据库，即连接器的工作。
使用数据库的第一步是首先连接到此数据库。目前，由于接收是连接器。连接器负责客户端...连接命令：
失去命令后，您需要在交互式对话中输入密码。尽管密码也可以直接写在命令行中-P后面，但这可能会导致您的密码泄漏。不建议遵循输入。
下图是我的计算机操作（MAC+ MAMP）。
如果输入帐户或密码错误提示（1045）：
回到主题，我们仍然从表的更新语句开始。以下是此表的创建语句。该表具有主密钥ID和字符串类型字段名称和十进制字段分数：
并添加一些测试数据：
结果如下：
如果要添加ID = 4的值，则SQL语句将如下编写：
执行结果如图所示：
当一个表上有更新时，与此表相关的查询缓存将失败，因此该语句将清空表上的所有缓存结果。这就是为什么我们通常不建议使用查询缓存的原因。
分析仪将知道这是通过短语和语法分析的更新声明。
优化器决定使用ID索引。
执行器负责特定的执行，找到此行，然后更新。
与查询过程不同，更新过程还涉及两个重要的日志模块，如果您接触到mySQL，则不得绕过这两个单词。
在谈论日志模块之前，让我们谈谈什么是物理日志和逻辑日志。
物理日志：以流行的方式，只有“我”才能自己使用。其他人无法共享我的“物理格式，私有化。逻辑日志：它可用于所有引擎共享的其他引擎。
重做日志是InnoDB引擎中的独特日志。它也称为重写日志。它用于记录交易操作的变化。它记录数据修改后的值。不管交易是否成功提交，都将被记录下来。
例如，MySQL实例被挂起或挂下来。重新启动时，InnoDB存储引擎将使用重做日志来恢复数据，以确保数据的持久性和完整性。
带有普通的古老小酒馆店主会计会计：
小酒馆的店主有一个黑板。当人数较少时，如果人数更少，如果黑板上的人更多，因为黑板的空间大小有限，他需要准备一本额外的书来记录所有帐户的所有帐户。如果有人想要要获取帐户，有两种老板的方式：（1），打开分类帐，查找分类帐的记录并添加帐户的记录；目前，将其更新到帐户帐户。如果店主使用第一种方法，每当有人想获取帐户时，首先，他需要打开厚实的分类帐，一页地找到客户的名称，然后注册。如果您考虑一下，如果帐户中没有很多人，则店主的记录发现会计师很容易。如果分类帐中有几本书，店主会头疼。
MySQL中也有一个问题。如果每个更新操作都需要写入磁盘，然后磁盘还需要查找相应的记录，然后更新，然后更新，IO的成本并找到整个过程的成本很高为了解决这个问题，MySQL设计师使用酒店店主粉的想法来提高更新效率。
与黑板和分类帐的整个过程实际上是MySQL中经常提到的WAL（）技术。关键是，
当需要更新记录时，InnoDB引擎将首先将记录写入（黑板）并更新内存。此时，更新已完成。在同一时间，InnoDB引擎将在适当的时间更新到磁盘，并且在系统相对免费时通常进行此更新，就像店主在打s时所做的一样。
如果有一天有很多帐户，并且粉末板已经满了，该怎么办？此时，店主不得不把手中的作品放下，将黑板中的分类帐的一部分更新到了分类帐，然后然后从黑板上删除这些记录以制作一个新帐户。
同样，InnoDB的重做日志已固定。例如，可以将其配置为4个文件集。每个文件的大小为1GB，因此此“黑板”可以总共记录4GB操作。从头开始启动写作，然后返回开始在末尾写作，如下图所示。
写入POS是当前记录的位置。写作时写入，然后返回到文件第4号末尾的第一文件的开头。
如果在老板上方的黑板场景中描述了它，那么令状POS是Blackboard中老板的书。对于mysql，写入pos向后移动；检查点是，老板在黑板上写下了分类帐单上的记录。在上面的位置，当老板写在帐户上时，它将删除粉末板上的记录。对于MySQL，请检查检查。
“黑板”的“黑板”部分仍然是空的，可以用来记录新操作。如果写入检查点，则表示“黑板”已满。目前，无法执行新的更新。您必须停下来擦除一些记录并提前检查KPoint。
有了重做日志，InnoDB可以确保即使数据库异常重新启动，提交之前提交的记录也不会丢失。此功能称为崩溃安全。
重做日志的使用方案用于系统抢断恢复。
REDOLOG配置为默认情况下是16MB。查看相关配置SQL：
结果如图所示：
将事物提交给磁盘将根据此配置的策略进行同步。
0提交内容时，您不会将重做日志缓冲区中的数据滑入磁盘中。
1提交内容时，必须将日志刷到磁盘中，以严格确保数据不会丢失（默认和推荐策略）。
2提交内容时，首先将日志滑入与磁盘文件相对应的OS缓存缓存中，然后将数据刷到磁盘中一段时间。
查看相关参数SQL：
就mySQL而言，实际上有两个部分：一个是它主要执行MySQL的功能级别；另一个是它负责存储特定的问题。REDOLOG是InnoDB引擎中的唯一日志，并且服务器层还具有自己的日志，称为Binlog（Archive Log）。
为什么有两个日志？
起初，MySQL没有InnoDB Engine.mysql自己的引擎是Myisam，但Myisam没有碰撞安全的能力。BINLOG日志只能用于归档。InoDB以插件的形式介绍给mySQL。由于它仅依赖Binlog，因此没有崩溃的安全功能，因此InnoDB使用了另一个日志系统，即重做日志以实现崩溃安全功能。
BIN日志是MySQL数据库服务层。这是所有存储引擎共享的日志模块。它用于记录数据库执行的写作操作，也就是说，它记录在提交阶段，该阶段以二进制形式存储在磁盘中。
这两个日志具有以下差异：
1 InnoDB引擎。Binlog由MySQL的服务器层实现，并且可以使用所有引擎。2重做日志是物理日志，它记录了“您在数据页面上做什么”。BINLOG是一个逻辑日志，由MySQL数据库的服务层执行。该语句的原始逻辑已记录，例如“将1添加到1个= 4”的分数字段。，并固定空间。可以添加binlog。您可以通过max_binlog_size参数设置bin日志文件大小。当文件大小达到某个值时，将生成一个新文件以保存日志。与这两个日志的概念理解，让我们在执行此简单更新语句时查看执行器和InnoDB引擎的内部进程。
更新语句的执行流图如下。图片中的黄色框在InnoDB中执行，绿色框代表执行器。
关注最后三个步骤，将重做登录的写入分为两个步骤：和谐，这是“两个阶段提交”。
为什么必须在两个阶段中存在“两个提交阶段”？这是为了。
BINLOG将记录所有逻辑操作并使用“附加写作”的形式。如果您的DBA承诺将在半个月内恢复，那么最后半个月中的所有Binlogs都将保存在备份系统中，并且该系统将定期制作一个库备份。
例如，当您需要返回指定的第二个时，一个下午发现在上午11点有意外删除表，并且您需要检索数据，那么您可以做到：
首先，找到最新的全部备份。如果幸运的话，它可能是昨晚的备份，从这个备份到临时图书馆。然后，从备份时间点开始，将依次取出备份的布格，并将其放回后面，向后向后，向后返回到备份。中午。这样，您的临时库与以前的在线库相同，然后您可以将表数据从临时库中取出，并根据需要将其还原到在线库。
为什么日志需要“提交两个阶段”？
因为重做日志和Binlog是两个独立的逻辑，因此，如果您不需要在两个阶段中提交，则在编写binlog之前将编写重做日志，或者使用反向顺序。LET，请参阅这两种方式有什么问题。
仍以先前的更新语句为示例。请确定当前ID = 4行，字段得分的值为98.00，然后假设在更新语句中写下第一个日志后，第二个日志在此期间没有发生时期。会发生什么？
假设在编写重做日志并且binlog尚未完成后，MySQL过程异常重新启动。正如我们之前所说的那样，在重做日志写作后，即使数据崩溃，系统仍然可以还原数据，因此，因此该系统的值也可以恢复。恢复后的线是99.00。目前，Binlog中没有此语句的记录。因此，当登录后，Binlog中没有此类语句。如果您需要使用此Binlog来还原临时库，因为此语句的Binlog是丢失，这个临时库的更新将减少。还原线的值为98.00，与原始库的值不同。
如果碰撞是在Binlog之后写的，则由于尚未编写重做日志，因此交易在崩溃和恢复后是无效的，因此该行的值为98.00.但是Binlog记录了“从98.00到99.00的更改得分”日志“因此，当用Binlog恢复它时，会有额外的交易。恢复行的这一行的分数值为99.00，与原始库的值不同。
可以看出，如果未使用“两个阶段提交”，则数据库的状态可能与库的状态与其日志还原相反。
问题：此类操作的概率是否很低，当没有恢复时，没有什么可以恢复临时库的？
操作后，您不仅需要使用此过程来恢复数据。当您需要扩展容量时，即，当您需要构建更多库以增加读取系统的能力时，也可以通过完整的备份，并由Binlog应用。这种“不一致”会导致您导致青年在线上是不一致的数据库。
简而言之，重做日志和BINLOG都可以用来表示事务状态，并且两个阶段提交是在逻辑上保持这两个状态。
对于InnoDB引擎，仅当委员会在每笔交易中提交时，才会记录Binlog日志。目前，记录仍在记忆中。因此，它何时存储在磁盘中？mySQL通过Sync_binlog参数控制Binlog板的时间，值范围：0?n：
0：不要强迫它何时由系统编写磁盘；
1：每次交易是提交时，都必须写入磁盘；
N：每年的提交将写给磁盘；
备注：该值的值为0，并且操作系统机制用于缓冲数据同步。建议将设置为1的Sync_binlog参数，以便将每个交易写入磁盘中，这也可以确保bin日志MySQL异常重新启动后，日志不会丢失。
如图所示：
在Binlog的实际情况下，BIN日志有两种主要情况。一个点是主和从副本，另一个是数据恢复。
结尾
如果您有任何疑问，请在下面留言。
或注意我的公共帐户“”（），输入”。寻求进一步的帮助。
原始：https：//juejin.cn/post/7096741487563505678