数据库数据更新：从内存到磁盘，一步步揭开数据的神秘面纱！

大家好，我是小米！今天我要和大家分享一下数据库数据更新的流程。作为一名热衷于技术分享的小伙伴，我希望通过本篇文章，帮助大家更好地理解数据库数据更新的过程。废话不多说，让我们开始吧！

获取数据

在数据库的数据更新过程中，首先，执行器会从引擎中查找需要更新的数据。如果这些数据在内存中已经存在，那么执行器会直接返回它们。这是因为内存的读取速度非常快，可以快速响应查询请求，提高数据访问效率。但是，如果数据不在内存中，执行器就需要进行查询操作，从磁盘或其他存储介质中读取数据，然后将查询结果返回给执行器。

更改数据写入新数据

在拿到数据后，执行器会先对数据进行修改。例如，可以更新数据的某个字段、添加新的记录或者删除现有的记录。修改完成后，执行器会调用引擎接口，将修改后的数据重新写入数据库中。引擎接口会负责将数据写入对应的存储介质，如磁盘或者固态硬盘，以保证数据的持久性。

prepare阶段

当执行器调用引擎接口后，引擎会将数据更新到内存中，以提供更快的数据访问速度。同时，引擎还会将数据写入 redo log（重做日志）中。redo log 记录了数据库发生的每个修改操作，包括插入、更新和删除等，它起到了数据恢复的关键作用。在这个阶段，数据处于 prepare（准备）阶段，引擎会通知执行器操作已完成，可以随时对数据进行操作。

生成binlog

在数据更新过程中，执行器会生成 binlog（二进制日志）。binlog 记录了数据库的逻辑操作，如增删改等，它可以用于数据恢复、主从复制以及故障恢复等场景。执行器生成 binlog 的目的是为了保留数据修改的历史记录，以便后续需要进行数据恢复或者复制操作时使用。

commit阶段

当所有操作都执行完毕后，执行器会调用引擎的事务提交接口。引擎接收到提交请求后，将之前写入 redo log 的数据状态从 prepare 改成 commit，表示数据更新已完成。这个过程保证了数据的一致性和持久性，确保了事务的原子性。

二阶段提交

二阶段提交是一种保证分布式事务的一致性的协议。在分布式环境中，事务涉及多个节点，为了保证所有节点的数据操作能够一致地提交或者回滚，需要引入二阶段提交。它分为两个阶段：准备阶段和提交阶段。

• 在准备阶段，各个参与者节点准备好提交的数据，并向协调者节点发送准备就绪的消息。
• 在提交阶段，协调者节点向各个参与者节点发送提交请求，并等待参与者节点的响应。只有当所有参与者节点都准备就绪并响应提交请求时，协调者节点才会发出最终的提交指令。

redo log 的二阶段提交

在数据库数据更新过程中，redo log 也遵循二阶段提交的原则。

• 为了保证数据的一致性和持久性，redo log 的写入操作先于 binlog。这样做的好处是，即使系统在写入 binlog 时出现异常，通过 redo log 的回滚操作，可以将数据库恢复到更新前的状态，避免数据丢失或损坏。redo log 的先写操作可以提供更高的事务安全性。
• 与上述情况相反，有时也会先写入 binlog，再写入 redo log。这种方式可以在数据恢复和备份过程中提供更多的灵活性和选择性，但需要特别小心，确保在写入 binlog 后能够正确地将数据同步到 redo log，以保持数据的一致性。

总结

通过今天的分享，我们对数据库数据更新的流程有了更深入的了解。这个过程中涉及到执行器、引擎、redo log、binlog 等多个环节，每个环节都承担着重要的责任，保证数据的正确性和一致性。希望这篇文章对你有所帮助，如果有任何问题或者想法，欢迎在下方留言与我讨论。

END

如有疑问或者更多的技术分享，欢迎关注我的微信公众号“知其然亦知其所以然”