个人学习MySQL的总结学习笔记，参考资料都在文末给出，建议阅读
一、读写锁
- 互斥锁（Exclusive），简写为 X 锁，又称写锁。
- 共享锁（Shared），简写为 S 锁，又称读锁。
有以下两个规定：
- 一个事务对数据对象 A 加了 X 锁，就可以对 A 进行读取和更新。加锁期间其它事务不能对 A 加任何锁。
- 一个事务对数据对象 A 加了 S 锁，可以对 A 进行读取操作，但是不能进行更新操作。加锁期间其它事务能对 A 加 S 锁，但是不能加 X 锁。
锁的兼容关系如下：
二、锁粒度
一种提高共享资源并发性的方式就是让锁定对象更具有选择性。
应该尽量只锁定需要修改的那部分数据，而不是所有的资源。在给定的资源上，锁定的数据量越少，发生锁争用的可能性就越小，因而可以提高系统的并发程度。
但是加锁需要消耗资源，锁的各种操作（包括获得锁、释放锁、检查锁是否已经解除）都会增加系统开销。因此封锁粒度越小，系统开销就越大。
所谓的锁策略，就是在锁的开销和数据的安全性之间寻求平衡。MySQL 中提供了两种封锁粒度：行级锁以及表级锁。
一般都是在表上施加行级锁，并以各种复杂的方式来实现，以便锁在比较多的情况下尽可能地提供更好的性能。
每种MySQL存储引擎都可以实现自己的锁策略和锁粒度，所以可以根据应用场景选择不同的方案。
表锁
锁定整张表，是MySQL中最基本的锁策略，并且是开销最小的策略。
READ_LOCAL表锁支持某些类型的并发操作。在表锁中，写锁比读锁具有更高的优先级，因此写锁可以插入到锁队列中读锁的前面，反之则不能。
MySQL服务器会为诸如ALTER_TABLE之类的语句使用表锁，而忽略存储引擎的锁机制。
行锁
最大程度地支持并发处理，同时带来了最大的锁开销。
行级锁只在存储引擎层面实现，MySQL服务器层完全不了解存储引擎的锁实现。
三、事务
概念
事务指的是满足 ACID 特性的一组操作，事务内的语句要么全部执行成功，要么全部执行失败，可以通过 Commit 提交一个事务，也可以使用 Rollback 进行回滚。
可以使用START TRANSACTION显式地开启一个事务，然后使用COMMIT提交事务将修改的数据持久保留，或者使用ROOLBACK撤销所有的修改（回滚）。
MySQL 默认采用自动提交模式。也就是说，如果不显式START TRANSACTION使用语句来开始一个事务，那么每个查询操作都会被当做一个事务并自动提交。
ACID
原子性（Atomicity）
一个事务被视为一个不可分割的最小工作单元，整个事务中的所有操作要么全部提交成功，要么全部失败回滚。
回滚可以用回滚日志（Undo Log）来实现，回滚日志记录着事务所执行的修改操作，在回滚时反向执行这些修改操作即可。
一致性（Consistency）
数据库总是从一个一致性状态转换到另一个一致性状态。事务如果最终没有提交，那么事务的修改也不会保存到数据库中。在一致性状态下，所有事务对同一个数据的读取结果都是相同的。
隔离性（Isolation）
一个事务所做的修改在最终提交以前，对其它事务是不可见的。
持久性（durability）
一旦事务提交，则其所做的修改将会永远保存到数据库中。即使系统发生崩溃，事务执行的结果也不能丢失。持久性策略有多种级别，但不可能做到100%的持久性保证。
系统发生奔溃可以用重做日志（Redo Log）进行恢复，从而实现持久性。与回滚日志记录数据的逻辑修改不同，重做日志记录的是数据页的物理修改。
事务的 ACID 特性概念简单，但不是很好理解，主要是因为这几个特性不是一种平级关系：
- 只有满足一致性，事务的执行结果才是正确的。
- 在无并发的情况下，事务串行执行，隔离性一定能够满足。此时只要能满足原子性，就一定能满足一致性。
- 在并发的情况下，多个事务并行执行，事务不仅要满足原子性，还需要满足隔离性，才能满足一致性。
- 事务满足持久化是为了能应对系统崩溃的情况。
对于一些不需要事务的查询类应用，选择一个非事务型的存储引擎（如MyISAM），可以获得更高的性能。即使存储引擎不支持事务，也可以通过使用LOCK TABLES为应用提供保护。
四、隔离级别
未提交读（READ UNCOMMITTED)
事务中的修改即使没有提交，对其他事务也都是可见的，事务可以读取未提交的数据，叫做脏读。
未提交读的性能不会比其他级别好太多，但却缺乏其他级别的很多优点，在实际应用中很少使用。
提交读（READ COMMITTED)
大多数据库系统的默认隔离级别都是提交读，但MySQL不是。也可叫做不可重复度级别，因为执行两次相同的查询，可能会得到不一样的结果。
一个事务开始时，只能读取到已经被提交的修改。换句话说，一个事务所做的修改在提交之前对其它事务是不可见的。
可重复读（REPEATABLE READ)
可重复读是MySQL的默认事务隔离级别。
解决了未提交读级别中的脏读问题。该级别保证在同一个事务中多次读取同一数据的结果是一样的。
可重复读无法解决幻读问题。所谓幻读，指的是，T1 读取某个范围的数据，T2 在这个范围内插入新的数据，T1 再次读取这个范围的数据，此时读取的结果和和第一次读取的结果不同。
可串行化（SERIALIZABLE)
通过强制事务串行执行，在读取的每一行数据上都加锁，解决了幻读的问题，但是可能会导致超时和锁争用问题。
产生并发不一致性问题的主要原因是破坏了事务的隔离性，解决方法是通过并发控制来保证隔离性。并发控制可以通过封锁来实现，但是封锁操作需要用户自己控制，相当复杂。数据库管理系统提供了事务的隔离级别，让用户以一种更轻松的方式处理并发一致性问题。
五、封锁协议
1. 三级封锁协议
一级封锁协议
事务 T 要修改数据 A 时必须加 X 锁，直到 T 结束才释放锁。
可以解决丢失修改问题，因为不能同时有两个事务对同一个数据进行修改，那么事务的修改就不会被覆盖。
二级封锁协议
在一级的基础上，要求读取数据 A 时必须加 S 锁，读取完马上释放 S 锁。
可以解决读脏数据问题，因为如果一个事务在对数据 A 进行修改，根据 1 级封锁协议，会加 X 锁，那么就不能再加 S 锁了，也就是不会读入数据。
三级封锁协议
在二级的基础上，要求读取数据 A 时必须加 S 锁，直到事务结束了才能释放 S 锁。
可以解决不可重复读的问题，因为读 A 时，其它事务不能对 A 加 X 锁，从而避免了在读的期间数据发生改变。
2. 隐式锁定与显示锁定
隐式锁定
InnoDB采用两阶段锁定协议，也叫两段锁协议。
在事务执行过程中，随时都可以执行锁定，锁只有在执行提交或者回滚时才会同时释放。InnoDB会根据隔离级别在需要的时候自动加锁
显示锁定
* SELECT ... LOCK IN SHARE MODE
* SELECT ... FOR UPDATEMySQL也可以在服务器层面实现 LOCK TABLES 和 UNLOCK TABLES。
3. 两段锁协议
加锁阶段
在该阶段可以进行加锁操作。在对任何数据进行读操作之前要申请并获得共享锁锁，在进行写操作之前要申请并获得排他锁。加锁不成功，则事务进入等待状态，直到加锁成功才继续执行。
解锁阶段
当事务释放了一个封锁以后，事务进入解锁阶段，在该阶段只能进行解锁操作不能再进行加锁操作。
六、多版本并发控制
多版本并发控制（Multi-Version Concurrency Control, MVCC）是 MySQL 的 InnoDB 存储引擎实现隔离级别的一种具体方式，用于实现提交读和可重复读这两种隔离级别。而未提交读隔离级别总是读取最新的数据行，要求很低，无需使用 MVCC。可串行化隔离级别需要对所有读取的行都加锁，单纯使用 MVCC 无法实现。
实现原理
MVCC是通过保存数据在某个时间点的快照来实现的，不同的存储引擎的MVCC实现是不同的，典型的有乐观并发控制和悲观并发控制。
InnoDB的MVCC通过在每行记录后面保存两个隐藏的列来实现。一个列保存创建时的系统版本号，一个列保存行的过期时（删除时间）的系统版本号。
每开始一个新的事务，系统版本号都会自动递增。事务开始时刻系统的版本号会作为事务的版本号，用来和查询到的每行记录的版本号进行比较。
具体实现
SELECT
InnoDB会根据两个条件检查每行记录，只有符合以下两个条件的记录才会被作为结果返回
- 只查找行的系统版本号小于或等于事务的系统版本号。可确保读取到的记录要么在本事务之前已存在，要么是本事务进行的修改。
- 行的版本号要么未定义，要么大于当前事务的版本号。可以确保事务读取的行在事务开始之前未被删除。
INSERT
InnoDB为新插入的每一行保存当前系统版本号作为行版本号。
DELETE
InnoDB为删除的每一行保存当前系统版本号作为删除标识。
UPDATE
InnoDB新插入一条纪录，保存当前系统版本号为行版本号，同时保存当前系统版本号到原来的行作为行删除标识。
优缺点
使用系统版本号，在大多数情况下的读操作都可以不用加锁，使得读数据变得更简单，提供系统性能，并且保证读取到的记录符合标准。
但是每一行都需要额外使用存储空间，且需要做更多的检查以及维护。
参考资料
《高性能MySQL》
cyc2018
美团技术团队——InnoDB中的事务隔离级别和锁的关系