业务系统通过一个数据库连接发给MySQL，经过SQL接口、解析器、优化器、执行器，解析SQL语句，生成执行计划，接着由执行器负责执行该计划，调用InnoDB的接口去实际执行。
提交事务的时候，redo日志必须是刷入磁盘文件里的。这样可以严格的保证提交事务之后，数据是绝对不会丢失的，因为有redo日志在磁盘文件里可以恢复你做的所有修改。如果要是选择0的话，可能你提交事务之后，mysql宕机，那么此时redo日志没有刷盘，导致内存里的redo日志丢失，你提交的事务更新的数据就丢失了；如果要是选择2的话，如果机器宕机，虽然之前提交事务的时候，redo日志进入os cache了，但是还没进入磁盘文件，此时机器宕机还是会导致os cache里的redo日志丢失；所以对于数据库这样严格的系统而言，一般建议redo日志刷盘策略设置为1，保证事务提交之后，数据绝对不能丢失。
4.更新操作为什么不直接更新磁盘反而设计这样⼀个复杂的InnoDB存储引擎来完成？
首先，InnoDB会判读缓冲池里是否存在 id = 1 这条数据，如果不存在则从磁盘中加载到缓冲池中，而且还会对这行数据加独占锁，防止多个sql同时修改这行数据。
本文章来源于：https://github.com/Zeb-D/my-review ，请star 强力支持，你的支持，就是我的动力。
是指作为单个逻辑工作单元执行的一系列操作，要么完全地执行，要么完全地不执行。 事务处理可以确保除非事务性单元内的所有操作都成功完成，否则不会永久更新面向数据的资源。通过将一组相关操作组合为一个要么全部成功要么全部失败的单元，可以简化错误恢复并使应用程序更加可靠。一个逻辑工作单元要成为事务，必须满足所谓的ACID（原子性、一致性、隔离性和持久性）属性。事务是数据库运行中的一个逻辑工作单位，由DBMS中的事务管理子系统负责事务的处理。
redo log也叫做重做日志，它是基于磁盘的数据结构，也有内存中的buffer,他的作用是在崩溃恢复期间用于纠正不完整事务写入的数据。
事务是由一系列SQL组成的逻辑处理单元，要么全'部'执行，要么全'不'执行。事务具有四个属性，也就是常说的ACID属性，分别代表原子性，一致性，隔离性和持久性，再重新巩固一下吧：
学习计划的第四天，仍然是对数据库事务方面进行学习。毕竟数据库操作在后端开发中有着举足轻重的作用。 那么，今天的学习内容是：事务丢失更新问题及乐观锁、悲观锁机制。 话不多说，进入正题。 什么是事务的丢失更新问题？ 两个或多个事务更新同一行，但这些事务彼此之间都不知道其它事务进行的修改，因此第二个更改覆盖了第一个修改 。 这样说太抽象，举个例子：在数据库表中存在一条数据
解决并发问题，当然锁最靠谱，所以MySql也提了共享锁、排它锁等。但是一个并发性能良好的系统一旦加锁，不可避免的造成访问的串行化，影响并发性能。所以MySql提供了一种乐观锁的实现：MVCC（多版本并发控制），来解决读-写并发不加锁。
通过上文《MySQL是如何保证数据不丢失的？》可以了解DML的操作流程以及数据的持久化机制。对于一个数据库而言，除了数据的持久性、不丢失之外，一致性也是非常重要的，不然这个数据是没有任何意义的。在使用MySQL时，数据不一致的情况也可能出现，所以，本文就来看看MySQL是如何保证数据一致的。
日志文件中记录的到底是什么呢？mysql支持了两种日志格式，这两种日志格式也体现了各自的复制方式
在现代关系型数据库中，事务机制是非常重要的，假如在多个事务并发操作数据库时，如果没有有效的机制进行避免就会导致出现脏读，不可重复读，幻读。
今天来和大家分享MySQL的三个日志文件，可以说 MySQL 的多数特性都是围绕日志文件实现，而其中最重要的有以下三种：
如果两个事务操作的是不同的数据， 即不存在数据依赖关系， 则它们可以安全地并行执行。但是当出现某个事务修改数据而另一个事务同时要读取该数据， 或者两个事务同时修改相同数据时， 就会出现并发问题。
事务（transaction）是作为一个单元的一组有序的数据库操作。如果组中的所有操作都成功，则认为事务成功，即使只有一个操作失败，事务也不成功。如果所有操作完成，事务则提交，其修改将作用于所有其他数据库进程。如果一个操作失败，则事务将回滚，该事务所有操作的影响都将取消。
这些数据最终会持久化到文件中，那么这些数据在文件中是如何组织的？难道是一行一行追加到文件中的？其实并不是，「数据其实是存到页中的，一页的大小为16k，一个表由很多页组成，这些页组成了B+树」，最终的组织形式如下所示，具体的构建过程我就不详细介绍了，可以看我之前的文章《10张图，搞懂索引为什么会失效？》
一直以来对数据库的事务隔离机制的理解总是停留在表面，其内容也是看一遍忘一边。这两天决定从原理上理解它，整理成自己的知识。查阅资料的过程中发现好多零碎的概念如果串起来足够写一本书，所以在这里给自己梳理一个脉络，具体的内容参考引文或在网上搜一下。由于平时接触最多的是MySQL，所以文章中某些部分是MySQL特有的特性，请读者注意。 数据库并发操作会引发的问题： 多个事务同时访问数据库时候，会发生下列5类问题，包括3类数据读问题（脏读，不可重复读，幻读），2类数据更新问题（第一类丢失更新，第二类丢失更新）： 脏读
我的网站上一直有好多人留言催更 MySQL 日志（undo log、redo log、binlog）的文章。
谁也不能保证计算机系统能够永远无故障的执行下去。网络波动、磁盘损坏等现网高频故障，机房掉电、服务器硬件失效等低频却又致命的故障，时刻考验着我们的系统。
看过我之前文章《一条Update语句的执行过程是怎样的？》的朋友都基本知道【点击文章传送门~🙌】，在整个Update更新语句中会涉及到三种日志，分别是undo log(回滚日志）、redo log (重做日志) 、binlog (归档日志)，也有两阶段提交，没看过的不要紧，可以结合本篇文章一起看，会有1+1>2的效果。
本文探讨innodb如何使用mvcc和各种锁机制，保障mysql的四层隔离等级的。
这是一条很简单的更新SQL，从MySQL服务端接收到SQL到落盘，先后经过了MySQL Server层和InnoDB存储引擎。
我们的系统在和 MySQL 数据库进行通信前，需要先和数据库建立连接，而这个功能就是由MySQL驱动底层帮我们完成的，建立完连接之后，我们只需要发送 SQL 语句就可以执行 CRUD 了。如下图所示：
我： 这个题目太简单的吧，他们两个最大的区别，B+ 树数据存储在叶子节点，B 树的节点在所有的节点上。
在上一篇《面试官：你说说一条查询SQL的执行过程？》中描述了Mysql的架构分层，通过解析器、优化器和执行引擎完成一条SQL查询的过程，那这一篇续上继续说明一条更新SQL的执行过程。
源自星球同学的提问：es如何与hive或mysql结合使用？es不支持事务有什么好的弥补方案吗？
主备复制过程中有很大可能会出现各种问题，接下来我们就讨论一些比较普遍的问题，以及当遇到这些问题时，如何解决或者预防问题发生。
InnoDB 存储引擎是以页为单位来管理存储空间的, 我们的增删改查操作本质上都是在访问页面, 如读取一条数据, 会把这个数据所在的页加载到内存中, 而不仅仅是这条数据本身, 这个页的默认大小是 16KB.
上一篇博文介绍了声明式事务@Transactional的简单使用姿势，最文章的最后给出了这个注解的多个属性，本文将着重放在事务隔离级别的知识点上，并通过实例演示不同的事务隔离级别下，脏读、不可重复读、幻读的具体场景
哈喽，我是狗哥。小伙伴都知道我最近换工作了，薪资、工作内容什么的都是我比较满意的。五月底也面试了有 6、7 家公司，应该拿了有 5 个 offer。这段时间也被问了很多面试题，我打算写一个专题分享出来，希望对你们有所帮助～
他们有一个共同的字段, 叫做xid, 崩溃恢复的时候, 会按照顺序扫描redolog:
MySQL主从复制涉及到三个线程，一个运行在主节点（log dump thread），其余两个(I/O thread, SQL thread)运行在从节点：
1、原子性（Atomicity）：事务开始后所有操作，要么全部做完，要么全部不做，不可能停滞在中间环节。事务执行过程中出错，会回滚到事务开始前的状态，所有的操作就像没有发生一样。也就是说事务是一个不可分割的整体，就像化学中学过的原子，是物质构成的基本单位。
常见的MySQL主要有两种结构：Hash索引和B+ Tree索引，我们使用的是InnoDB引擎，默认的是B+树
RC和快照隔离级别主要都是为解决 只读事务遇到并发写时可以看到什么（虽然中间也涉及脏写），还没触及另一种情况：两个写事务并发，而脏写只是写并发的特例。
我们在平时工作中，使用最多的数据库就是 MySQL 了，随着业务的增加，如果单单靠一台服务器的话，负载过重，就容易造成宕机。
对这个问题的思考起源于一篇文字，文字中针对 MYSQL的隔离级别中的实现的问题进行了说明 MySQL Repeatable-Read 隔离级别一些误解 - 知乎 (zhihu.com) ，里面写的很详细，这里就不在详述了，感兴趣的同学可以去看，很涨知识，例如我，因为读了这篇文字，对于 PG MYSQL 在MVCC 的实现的问题，有了更深的认知。顺便说一句，写这篇文字的同学是阿里云POLARDB 的数据库开发者。https://zhuanlan.zhihu.com/p/402008512
上篇文章我们聊了单机模式下，MySQL是如何保证数据一致性的，但是在实际的生产环境中，很少采用单机模式。现在所有的集群架构都是从MySQL的主从复制演变过来的。MySQL的主从复制是通过将主库的binlog发送至从库，从库重新提交主库的变更来实现主从数据的一致性。MySQL的主从复制主要分为三种：异步复制、半同步复制、组复制（MGR）。
在分析 MVCC 的原理之前，我们先回顾一下 MySQL 的一些内容以及关于 MVCC 的一些简单介绍。（注:下面没有特别说明默认 MySQL 的引擎为 InnoDB ）
我们执行增删改操作的时候，首先会在Buffer Pool中加独占锁更新缓存页，那么缓存页和底层的物理磁盘上的数据页的原理，在更新完Buffer Pool中的缓存页之后，必须要写一条redo log，这样才能记录下来我们对数据库做的修改。redo log可以保证我们事务提交之后，如果事务中的增删改SQL语句更新的缓存页还没刷到磁盘上去，此时MySQL宕机了，那么MySQL重启过后，就可以把redo log重做一遍，恢复出来事务当时更新的缓存页，然后再把缓存页刷到磁盘就可以了redo log本质是保证事务提交之后，修改的数据绝对不会丢失的。
在并发的场景中，为了保证数据的一致性我们会在数据库中使用事务。然而在强一致性与性能上则需要根据具体业务来取舍，所以一般数据库提供了四种事务隔离级别： 读未提交（Read Uncommitted） 读提交（Read Committed） 可重复读（Repeatable Read） 序列化（Serializable） 由于日常工作中使用事务比较频繁，遂在此作一下总结 在了解这四种事务隔离级别之前，需要了解如下概念： 更新丢失（Lost Update）: 两个事务同时修改一行数据，其中一个事务的更新被另外一个事
InnoDB 存储引擎 lock 的对象是事务，用来锁定的是数据库中的对象，如表、页、行，并且一般 lock 的对象仅在事务 commit 或 rollback 后进行释放（不同事务隔离级别释放的时间可能不同）。
数据库事务是指作为单个逻辑工作单元执行的一系列操作，要么完全地执行，要么完全地不执行。 事务处理可以确保除非事务性单元内的所有操作都成功完成，否则不会永久更新面向数据的资源。 通过将一组相关操作组合为一个要么全部成功要么全部失败的单元，可以简化错误恢复并使应用程序更加可靠。
背景 考虑下面两个并发带来的问题： 1、丢失更新：一个事务的更新结果覆盖了其它事务的更新结果，即所谓的更新丢失。 2、脏读：当一个事务读取其它完成一半事务的记录时，就会发生脏读取。 例如： 两个用户同时修改商品库存表，A、B同时进入，看到的库存都是100，A购买一件把库存修改为99(100-1)。此时B购买两件把库存修改为98(100-2)，因为A、B同时读到的库存都是100，B并不能看到A做的库存更新，所以造成B脏读，造成A丢失更新。 所以为了解决这些并发带来的问题。 我们需要引入并发控制机制--锁。
两个用户同时修改商品库存表，A、B同时进入，看到的库存都是100，A购买一件把库存修改为99(100-1)。此时B购买两件把库存修改为98(100-2)，因为A、B同时读到的库存都是100，B并不能看到A做的库存更新，所以造成B脏读，造成A丢失更新。
最近在读 《MySQL 技术内幕 InnoDB 存储引擎》，里面提到的各种概念都很新鲜，以前听说过脏读、幻读、不可重复读，但是对于概念不甚了解，于是查了一下，这里做个笔记。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
腾讯会议
实时音视频
