2019-08-08binlog + redo log 两阶段提交保证持久性
事务的回滚机制 保证原子性 要么全部提交成功 要么回滚
undo log + MVCC 保证一致性 事务开始和结束的过程不会其它事务看到 为了并发可以适当破坏一致性作者回复: 数据库基础非常扎实，赞
1 24
2019-08-08默认transaction用的是数据库默认的隔离级别不是一定是RR，只是用MySQL默认是RR作者回复: 对的
8
2019-08-08老师能否重点讲一下record lock、gap lock 以及 next-key lock？作者回复: 好的，后面安排
1 5
2019-10-21一个问题困扰我挺久希望解答，spring的事务隔离和db的事务隔离机制有什么关系，这么问吧比如db里默认是RR的隔离级别（默认也肯定会有一个隔离级别），我spring的事务里就不用配置隔离级别了？如果spring的事务里的代码并没有db操作我也能设置spring的事务隔离级别？
其次就是设置db级别的事务隔离的话，那如果业务不一样的话是不是理论上可以把库拆开来？因为肯定有一些库用到了不需要的更高隔离级别影响性能。作者回复: 文中解释了怎么实现了数据库的事务隔离级别，那就是通过锁来实现的，Spring的封装只是使用了 MySQL提供的标准接口，只要在设置transaction的时候设置事务隔离级别。
如果不想影响不同业务相互之间的性能，可以通过拆库实现。 2
2019-08-28老师，您这些数据库的相关知识是从官网还是某些书籍中获取的？我的数据库进阶的知识比较浅，看官网觉得有点费劲，不知道从哪入手去看去学作者回复: 可以阅读一些基础入门的书籍，也是作者已经消化梳理过了的，会比较通俗易懂。
1
2019-08-14老师，对于可重复读(Repeatable Read)的事务级别可以避免不可重复读的现象有个疑问：
对于事务A来说，它在获得共享锁期间修改了数据，比如把A改为B，修改完成后释放共享锁。在A获得共享锁期间，事务B看到的数据是A，释放共享锁后，事务B才获得排他锁，然后看到的数据是B。两次的数据不一样啊，还是没有避免不可重复读。。。。不知道我理解的哪里不对，望老师指点。。。🙏作者回复: 粗略看好像没什么问题，但仔细看就能看出问题了。
事务A存在读和改两个操作，事务B也同样存在读和改两个操作。事务A在读时，由于是共享锁，事务B也能读到该数据，当事务A进行修改就需要上排他锁了，此时事务B由于已经对该数据加了共享锁，事务A需要等待事务B释放共享锁才能获取排他锁来修改数据。同样事务B也在等待事务A释放共享锁。这种操作会导致死锁的出现。
我们一般用一个读的事务操作和一个读写事务操作来理解RR事务隔离级别。 1 1
2020-01-11老是有个问题，希望得到解答：InnoDB引擎下，select语句是不加锁的啊，那在文章中 避免行锁升级表锁一节中，讲到 如果不通过索引条件检索数据，行锁将会升级到表锁，应该不成立啊？作者回复: 这里的索引在update也会使用到
- 2020-01-11在结合业务场景，使用低级别事务隔离中，所举的用户、积分的例子中，使用不同的隔离级别，但是隔离级别不能单独给表设置吧。
作者回复: 可以设置全局，也可以对当前session设置，不能对单个表进行设置。
2019-12-20您好 对于可重复读的描述：事务 A 在读取数据时，事务 B 只能读取数据，不能修改。当事务 A 读取到数据后，事务 B 才能修改。 经试验 事务A在读取但是事务并未结束的时候 事务B是可以修改数据并提交的 不知道是我哪里理解有问题？作者回复: 先通过SELECT @@tx_isolation;查询下数据库的隔离级别是否为REPEATABLE-READ，然后再按照以下步骤操作：
1、分表开启A、B两个客户端，并在两个客户端开启事务：
mysql> start transaction;
2、并在两个客户端执行以下sql：
mysql> select * from `order` where id=1；
3、在B客户端执行以下sql,但不提交事务
mysql> update `order` set status = 2 where id =1;
4、此时在A客户端查询该值，此时你会发现值没有变
mysql> select * from `order` where id = 1;
5、提交事务客户端B的事务，再次查询A中的值，此时你会发现仍然没有变
mysql>commit；
mysql> select * from `order` where id = 1;
6、提交客户端A中的事务，再次查询A，B的值，此时发生了变更
mysql>commit；
mysql> select * from `order` where id = 1;
mysql> select * from `order` where id = 1;
可以按照以上步骤理解。 1
2019-12-17最后减库存例子中，如果要避免长时间持有锁，不应该先减库存，选择执行顺序2吗？作者回复: 这里是针对库存表的锁资源
- 2019-12-04老师，您说MVCC 对普通的 Select 不加锁，那RC和RR级别不一样了吗？这两个不就是select加锁不一样吗？还有既然RC select也是快照读，那是不是也解决了不可重复读问题？
望解答，研究了一晚上Mvcc搞晕了作者回复: 这对于普通的select操作是不加锁的，不论事务隔离级别。
2019-12-03老师，您好，我在可重复读里面，事务A没有结束，不做修改操作，但是事务B也可以修改数据作者回复: 检查下自己的代码以及隔离级别
- 2019-10-11有个问题请教下，我看到说 redolog 为了提升持久化的IO效率而产生，把每次事务写数据文件改成写redoLog然后再批量写redoLog到数据文件。我就有个问题了，redoLog和数据文件不都是磁盘读么？并且写redolog也需要在事务中同步写，因为异步写不能保证redolog必定写成功。。。求教
作者回复: 在40讲中，讲到了redo log的工作原理，redo log 又包括了内存中的日志缓冲（redo log buffer）以及保存在磁盘的重做日志文件（redo log file），前者存储在内存中，容易丢失，后者持久化在磁盘中，不会丢失。
MySQL支持用户自定义在commit时如何将log buffer中的日志刷log file中。这种控制通过变量 innodb_flush_log_at_trx_commit 的值来决定。该变量有3种值：0、1、2，默认为1，即每提交一次事务都写到磁盘中，而设置为0时，为每秒将事务写到磁盘中。 1 
2019-10-10Serializable 翻译为 可串行化 会更合理一些。作者回复: 收到建议
2019-10-04未提交读（Read Uncommitted）：在事务 A 读取数据时，事务 B 读取和修改数据加了共享锁。这种隔离级别，会导致脏读、不可重复读以及幻读。
这句话怎么理解呢？事务B读取和修改数据加了共享锁？修改数据不是只能加排它锁么？作者回复: 事务B读取数据加了共享锁，修改数据时加了排它锁
2019-09-22老师，对数据库锁不是很熟悉。以下结构是正确的吗？
数据库锁=乐观锁 + 悲观锁[共享锁、排它锁[行锁、表锁]]
这些是数据库所有的锁吗?作者回复: 是的
2019-09-14请问老师数据库的事务本质是不是都是利用单库的事务机制实现的?分布式数据库事务，只是将控制事务提交或回滚的动作往上层提升啦?作者回复: 是的
2019-09-10老师update语句是行锁，那insert语句是什么锁呢作者回复: 也是行锁
2019-08-29老师好，有个问题请教下。文章中说：“可重复读（Repeatable Read）可以避免脏读、不可重复读，但依然存在幻读的问题。”
我之前了解的是，SQL标准不要求RR解决幻读，但InnoDB的 RR下 是不会产生幻读的。
而且自己实验也是InnoDB在RR下没有幻读的现象。操作如下：
sessionA: begin;
sessionA: select * from t where id>1;(2条记录)
sessionB: insert into t(id,a) values(5,5);
sessionA: select * from t where id>1;(还是2条看不到5,5。没有产生幻读)展开作者回复: 这是RR下使用的间隙锁，所以不会出现幻读
3
2019-08-23老师数据库的事务和Spring的事务是一回事吗？写业务代码的时候，两种不同的事务分别起什么作用呢？或者说控制范围有何不同呢？作者回复: 两者实际上是一回事，Spring的事务也是基于数据库事务封装的方法。