首页 / 日志 / 日志系统:一条SQL更新语句是如何执行的
日志系统:一条SQL更新语句是如何执行的
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了日志系统:一条SQL更新语句是如何执行的,小编现在分享给大家,供广大互联网技能从业者学习和参考。文章包含1781字,纯文字阅读大概需要3分钟。
内容图文
一条查询语句一般经过连接器、分析器、优化器、执行器等模块,最后到达存储引擎。一条更新语句也需要经连接器连接数据库、分析器会通过词法和语法解析知道这是一条更新语句、优化器决定要使用的索引、然后执行器执行负责具体执行,找到这一行,然后更新。
更新语句和查询语句不一样的是,更新流程还涉及两个重要的日志模块,redo log(重做日志) 和 binlog (归档日志)。
MySQL 写 redo log 使用的是 WAL (Write-Ahead Logging)先写日志再写磁盘。
一条记录需要更新的时候,InnoDB 引擎会先把记录写到 redo log 里面,并更新内存,这个更新就完成了,同时,InnoDB 引擎会在适当的时候将操作记录更新到磁盘里面。这个更新往往实在系统比较空闲的时候,redo log 写满的时候也会更新到磁盘里面。
Innodb 的 redo log 是固定大小的,从头开始写,写到末尾就又回到开头循环写。
redo log 和 binlog 不同点
1,redo log 是 InnoDB 引擎特有的;binlog 是 MySQL 的 Server 层实现的,所有引擎都可以使用。
2,redo log 是窝里日志,记录的是 “在某个数据页上做了什么修改” ;binlog 是逻辑日志,记录的是这个语句的原始逻辑
3,redo log 是循环写的,空间固定会用完;binlog 是可以追加写的。
执行器和 InnoDB 引擎在执行简单 Update 语句时的内部流程(实例和执行流程图)
binlog 和 redo log 使用的是两阶段提交
不是用两阶段提交的后果
redo log 用于保证 crash-safe 能力, innodb_fiush_log_at_trx_commit 这个参数设置成 1 的时候,表示每次事务的 redo log 都直接持久化到硬盘,这个值设置成 1 ,可以保证 MySQL 异常重启之后数据不丢失
sync_binlog 这个参数设置成 1 的时候,表示每次事务 binlog 都持久化到硬盘,可以保证 MySQL 异常重启之后 binlog 不丢失。
两阶段提交是跨系统维持数据逻辑一致性时常用的一个方案
日志系统:一条SQL更新语句是如何执行的
标签:操作记录 nlog 日志 更新 update 模块 mit wal binlog
本文系统来源:https://blog.51cto.com/1681189/2495480
内容总结
以上是互联网集市为您收集整理的日志系统:一条SQL更新语句是如何执行的全部内容,希望文章能够帮你解决日志系统:一条SQL更新语句是如何执行的所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错,欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 gblab@vip.qq.com 举报,一经查实,本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。