事务 锁 索引 日志文件 数据文件 各种buffer flush等概念的串起来

能够解释常见场景下 单个事务和多事务并发场景下，MySQL内部处理机制

在MySQL中，按照锁定的范围，可以分为全局锁、表级锁、行级锁。

全局锁

对MySQL进程中的某个库上锁，上锁的命令FLUSH TABLES WITH READ LOCK;,这是当前数据库处于只读状态，所有会改变数据、表结构等写操作都会被阻塞。试验在只读状态下执行insert操作，返回’Can't execute the query because you have a conflicting read lock‘。（为什么是读锁冲突？）

全局锁的使用场景是备份库,解锁操作UNLOCK TABLES;

当然备份过程中，肯定是要保证数据不会变更的，不然会导致，课程中说的加入一个购买流程，包括添加课程和扣款两个操作，如果不加全局锁，在备份的时候就可能出现只会读到其中一个操作的数据，这就导致了数据错乱？

你可能会问，这两个操作不应该是在同一个事务中的吗，如果只执行了一个动作，说明事务还未提交，你肯定还看不到更新呀。这个逻辑我觉得有一定的道理，但假如这是由两个服务操作的，也就是分布式事务的场景下，当前表的操作肯定先提交了。所以就能读到了。

在备份数据时使用全局锁，不能再写入了，那服务就得停摆，并且作为从库时，也不能及时同步主库过来的binlog了。所以这种方式的成本很高。基于这个原因，我们可以选用另一种方案，将dump操作放在一个可重复读的事务中，利用innodb的mvvc机制，就保证了不会读到中间状态的数据了。

表级锁

表级锁有两种，一是表锁，二是元数据锁（Meta Data Lock）。

表锁的语法：lock tables xxx read;或者lock tables xxx write;。解锁的语法unlock tables;。

关于MDL，从级别来讲也是表级的，锁住的当前标的结构定义，MDL是系统自动添加和释放的，DML也分读和写两种。只有读读是共享的，当加了MDL锁（读或者写），DDL会被阻塞。

行锁

行锁是InnoDB特有的，能实现更细粒度的并发控制，这也是InnoDB取代MySQL原生存储引擎MyISAM 的一个原因。在InnoDB事务中，行锁是在需要的时候才加上的，但并不是不需要了就立刻释 放，而是要等到事务结束时才释放。这个就是两阶段锁协议 。

关于锁的问题，因为锁的释放是在事务结束后才会释放的，如果一个事务获得了锁A，执行完毕后，需要再次获得锁B，同时另一个事务，已经获得了锁B，执行完后，想要获得锁A。这时就会出现死锁。

当然死锁对业务来说是无损的，因为MySQL定义了获取锁的超时时间，默认是50s。如果超时，事务立即回滚，对业务无损。但是这个时间太长，并且也没有什么依据来计算一个合理的超时时间。所以在业务开发过程中，可以考虑将需要被频繁获取锁的操作尽量放在事务的最后执行，这样可以尽量减少当前事务对这个锁的持有时间。

另外一种方案，将热点行分成多条数据。

问题：当事务执行更新操作时，MySQL到底选择是行锁还是表锁。其实结合MySQL查找数据的机制来看，当定位数据走了索引，就会对这一行或多行添加行锁，否则，因为指定在主键索引中从头遍历，所以只能用表锁。

所谓的行锁，本质上在锁什么 在锁索引？

意向锁 intention lock

“加锁”操作，本质上也会存在并发操作，怎么保证一个锁完整地被某个事务获取呢，在redis中，setnx

间隙锁 gap lock

next row lock

乐观锁与悲观锁

是在使用锁控制资源竞争的前提下，再次提高并发能力。

所谓的悲观锁，则认为从”我“读到我再写的过程中，一定会有其他事务读写，所以从读到写整个过程我都加锁。

所谓乐观锁，则认为从”我“读到我再写的过程中，大部分情况下并没有其他事务读写，所以读的时候不再加锁，等写的时候，校验一把数据是否还是我当时读出来的样子，如果是，则表示是真没有其他事务在读写，那我就愉快滴把新数据写入。这样我的读写过程遍享受到了不加锁的顺滑。但假如在我写的时候真有其他事务已经谢过了，那我再重新读一遍并重新计算要写入的数据，一直重复这个过程，直至写入数据成功。

按照实际使用场景，真正存在并发的时刻确实不是100%，所以乐观锁的优势就体现出来了。

延伸：

悲观锁、乐观锁其实根据实际场景提出的一种锁优化思想，这个思想在其他地方也有运用，比如Java中的自旋+CAS，就是乐观锁的一种实现。比不管三七二十一，进来先通过synchronized获取锁要高效多。本质思想，尽可能减少不必要的加锁操作