一方面要最大程度地利用数据库的并发访问
另外一方面还要确保每个用户能以一致的方式读取和修改数据。
什么是锁
锁是数据库系统区别于文件系统的一个关键特性。锁机制用于管理对共享资源的 并发访问
lock 与 latch
lock的对象是事务，用来锁定的是数据库中的对象，如表、页、行。并且一般lock的对象仅在事务commit或rollback后进行释放（不同事务隔离级别释放的时间可能不同）。此外，lock，正如在大多数数据库中一样，是有死锁机制的。
latch一般称为闩锁（轻量级的锁），因为其要求锁定的时间必须非常短。若持续的时间长，则应用的性能会非常差。在InnoDB存储引擎中，latch又可以分为mutex（互斥量）和rwlock（读写锁）。其目的是用来保证并发线程操作临界资源的正确性，并且通常没有死锁检测的机制。
InnoDB 存储引擎中的锁
InnoDB存储引擎实现了如下两种标准的行级锁：
❑共享锁（S Lock），允许事务读一行数据。
❑排他锁（X Lock），允许事务删除或更新一行数据。
InnoDB存储引擎支持多粒度（granular）锁定，这种锁定允许事务在行级上的锁和表级上的锁同时存在。
两种意向锁：
1）意向共享锁（IS Lock），事务想要获得一张表中某几行的共享锁
2）意向排他锁（IX Lock），事务想要获得一张表中某几行的排他锁
INFORMATION_SCHEMA架构下添加了表
- INNODB_TRX
- INNODB_LOCKS
- INNODB_LOCK_WAITS
通过这三张表，用户可以更简单地监控当前事务并分析可能存在的锁问题。
一致性非锁定读
一致性的非锁定读（consistent nonlocking read）是指InnoDB存储引擎通过行多版本控制（multi versioning）的方式来读取当前执行时间数据库中行的数据。如果读取的行正在执行DELETE或UPDATE操作，这时读取操作不会因此去等待行上锁的释放。相反地，InnoDB存储引擎会去读取行的一个快照数据。
锁的算法
InnoDB存储引擎有3种行锁的算法，其分别是：
❑Record Lock：单个行记录上的锁
❑Gap Lock：间隙锁，锁定一个范围，但不包含记录本身
❑Next-Key Lock∶Gap Lock+Record Lock，锁定一个范围，并且锁定记录本身
锁的问题
transaction_characteristic:
ISOLATION LEVEL level
| READ WRITE
| READ ONLY
level:
| REPEATABLE READ
| READ COMMITTED
| READ UNCOMMITTED
| SERIALIZABLE
脏读 dirty ready
事务对缓冲池中行记录的修改，并且还没有被提交（commit）。
脏读指的就是在不同的事务下，当前事务可以读到另外事务未提交的数据，简单来说就是可以读到脏数据。
不可重复读 nonrepeatable read
不可重复读是指在一个事务内多次读取同一数据集合。在这个事务还没有结束时，另外一个事务也访问该同一数据集合，并做了一些DML操作。因此，在第一个事务中的两次读数据之间，由于第二个事务的修改，那么第一个事务两次读到的数据可能是不一样的。这样就发生了在一个事务内两次读到的数据是不一样的情况，这种情况称为不可重复读。
丢失更新
丢失更新是另一个锁导致的问题，简单来说其就是一个事务的更新操作会被另一个事务的更新操作所覆盖，从而导致数据的不一致。例如：
1）事务T1将行记录r更新为v1，但是事务T1并未提交。
2）与此同时，事务T2将行记录r更新为v2，事务T2未提交。
3）事务T1提交。
4）事务T2提交。
两个事务可以同时修改同一条记录？
阻塞
因为不同锁之间的兼容性关系，在有些时刻一个事务中的锁需要等待另一个事务中的锁释放它所占用的资源，这就是阻塞。阻塞并不是一件坏事，其是为了确保事务可以并发且正常地运行。
死锁
死锁是指两个或两个以上的事务在执行过程中，因争夺锁资源而造成的一种互相等待的现象。若无外力作用，事务都将无法推进下去。解决死锁问题最简单的方式是不要有等待，将任何的等待都转化为回滚，并且事务重新开始。毫无疑问，这的确可以避免死锁问题的产生。然而在线上环境中，这可能导致并发性能的下降，甚至任何一个事务都不能进行。而这所带来的问题远比死锁问题更为严重，因为这很难被发现并且浪费资源。
解决死锁问题最简单的一种方法是超时，即当两个事务互相等待时，当一个等待时间超过设置的某一阈值时，其中一个事务进行回滚，另一个等待的事务就能继续进行。在InnoDB存储引擎中，参数innodb_lock_wait_timeout用来设置超时的时间。
wait-for graph要求数据库保存以下两种信息：
❑锁的信息链表
❑事务等待链表
锁升级 Lock Escalation
将当前锁的粒度降低
InnoDB存储引擎不存在锁升级的问题。因为其不是根据每个记录来产生行锁的，相反，其根据每个事务访问的每个页对锁进行管理的，采用的是位图的方式。因此不管一个事务锁住页中一个记录还是多个记录，其开销通常都是一致的。
假设一张表有3 000 000个数据页，每个页大约有100条记录，那么总共有300 000 000条记录。若有一个事务执行全表更新的SQL语句，则需要对所有记录加X锁。若根据每行记录产生锁对象进行加锁，并且每个锁占用10字节，则仅对锁管理就需要差不多需要3GB的内存。而InnoDB存储引擎根据页进行加锁，并采用位图方式，假设每个页存储的锁信息占用30个字节，则锁对象仅需90MB的内存。
20170719 锁章节，第一遍看完，概念还是浆糊，有些模糊，需要看博客梳理下。
