下面我们来谈谈SQL在MySQL数据库中是如何执行的。我相信我们的朋友应该很关心这个话题。现在让我们为朋友们讲讲SQL是如何在MySQL数据库中执行的。边肖还收集了关于SQL如何在MySQL数据库中执行的相关信息。我希望你看到后会喜欢。

今天，让我们看看mysql视频教程专栏是如何执行update语句的。

查询语句的一组执行流更新语句也将一步一步来。下面，让我们简单看一下上一篇文章中的图：

首先，在执行语句之前连接到数据库，这是第一步中连接器的工作。前面我们也说过，当一个表更新的时候，与这个表相关的查询缓存会失效，所以我们一般不推荐十月查询缓存。

接下来，分析器将通过语法分析和词法分析知道这是一条update语句，然后优化器将决定使用哪个索引，然后执行器将负责具体的执行，首先找到这一行，然后进行更新。

与查询语句更新不同，更新过程还涉及到两个重要的日志，我们在上一篇文章中已经专门介绍过了。有兴趣的话可以找上周的文章《MySQL的两个日志系统》，这里就不介绍了。

这里有一个简单的例子来分析更新操作的流程。

让我们创建一个带有主键标识和整数字段C的表：

mysql创建表演示T (ID int primarty，c int)；复制代码，然后在ID=2的这一行的值上加上1。

mysql更新表演示集c=c 1其中ID=2；复制代码接下来，让我们看看update语句的执行流程图。浅色框表示存储引擎中的执行，而外观框表示执行器中的执行。

我们可以看到在最后写redolog的时候有两个准备和提交的步骤，也就是我们常说的“两阶段提交”。

为什么日志需要“两阶段提交”

由于重做日志和binlog分别是存储引擎和执行器的日志，是两个独立的逻辑，所以不经过两阶段提交，无论先提交哪个再提交哪个都会出现一些问题。在这里，借助上面的例子，让我们看看如果当前ID=2的行的值为0会发生什么。在更新过程中写入第一个日志后，在写入第二个日志之前会发生崩溃。

先写重做日志，然后写binlog。让我们假设在redolog写完binlog之前，MySQL进程异常重启。我们知道重做日志写入后，系统即使崩溃也能恢复数据，所以MySQL重启后这一行会恢复到1。因为binlog没有写完，崩溃了。此时，binlog中没有这样的语句。因此，在以后备份日志时保存的binlog日志中没有这样的语句。当我们需要通过binlog恢复数据时，由于binlog丢失了这个语句，恢复行的值为0，与原库的值不同。在重做日志之前写入binlog。如果崩溃发生在写入错误日志之后，但在写入重做日志之前，如果此时数据库崩溃，并且恢复后事务无效，则此行的值仍然为0，但此update语句的日志已记录在binlog中。将来需要使用binlog还原数据时，会多一个事务来执行此update语句，将值从0更新为1，这与原始库中的0不同。我们可以看到，如果不使用“两阶段提交”，数据库的状态将与日志恢复的库不一致。虽然在平时用日志还原数据的概率比较低，但是在日志使用最频繁的时候会用到完全备份和binlog，可能会导致在线主从数据库不一致。

相关免费学习推荐：mysql视频教程

以上就是在MySQL数据库中如何执行SQL的细节！

来源：php中文网站