数据库是多用户共享的资源，当出现并发访问时，通过锁这一数据结构来实现访问规则。
数据库的锁大致分为全局锁/表级锁和行锁。
全局锁
对整个数据库实例加锁。当需要整个库处于只读状态时，可使用Flush tables with read lock (FTWRL)，之后数据更新与居家（增删）、数据定义语句（建表、修改结构等）和更新类事务的提交语句会被阻塞。
典型应用场景是全库逻辑备份。把整个库select存成文档。
但是整个库处于只读很不方便：
- 主库备份期间无法执行更新，业务停摆
- 从库备份备份期间无法执行主库的同步
binlog，导致出现主从延迟
表级锁
表级锁有两种，一种是表锁，另一种是元数据锁（meta data lock，MDL)。
表锁语法是lock tables … read/write。 lock tables 语法除了会限制别的线程的读写外，也限定了本线程接下来的操作对象。
举个例子, 如果在某个线程 A 中执行 lock tables t1 read, t2 write; 这个语句，则其他线程写 t1、读写 t2 的语句都会被阻塞。同时，线程 A 在执行 unlock tables 之前，也只能执行读 t1、读写 t2 的操作。
如果一个查询正在遍历一个表中的数据，而执行期间另一个线程对这个表结构做变更，删了一列，那么查询线程拿到的结果跟表结构对不上，肯定是不行的。使用MDL在对一个表进行增删改查操作的时候，加MDL读锁；对结构进行变换时加MDL写锁。
行锁
行锁就是针对数据表中行记录的锁。 比如事务 A 更新了一行，而这时候事务 B 也要更新同一行，则必须等事务 A 的操作完成后才能进行更新。MyISAM不支持行锁，意味着并发控制只能使用表锁，对于这种引擎的表，同一张表上任何时刻只能有一个更新在执行，这就会影响到业务并发度。InnoDB 是支持行锁的，这也是 MyISAM 被 InnoDB 替代的重要原因之一。在 InnoDB 事务中，行锁是在需要的时候才加上的，但并不是不需要了就立刻释放，而是要等到事务结束时才释放。这个就是两阶段锁协议。
死锁和死锁检测
当并发系统中不同线程出现循环资源依赖，涉及的线程都在等待别的线程释放资源时，就会导致这几个线程都进入无限等待的状态，称为死锁。
出现死锁一般有两种策略：
- 一种策略是，直接进入等待，直到超时。这个超时时间可以通过参数
innodb_lock_wait_timeout来设置。这个值在InnoDB中默认为50s，对于在线服务来说，这个等待时间往往是无法接受的。又不可能直接把这个时间设置成一个很小的值，比如 1s。这样当出现死锁的时候，确实很快就可以解开，但如果不是死锁，而是简单的锁等待呢？所以，超时时间设置太短的话，会出现很多误伤。所以一般采用下述的第二种策略。 - 发起
死锁检测，发现死锁后，主动回滚死锁链条中的某一个事务，让其他事务得以继续执行。将参数innodb_deadlock_detect设置为on，表示开启这个逻辑。然而每个新来的被堵住的线程，都要判断会不会由于自己的加入导致了死锁，这是一个时间复杂度是 O(n) 的操作。这期间要消耗大量的 CPU 资源。因此，就会看到 CPU 利用率很高，但是每秒却执行不了几个事务。
因此，这个并发控制要做在数据库服务端。如果有中间件，可以考虑在中间件实现；如果你的团队有能修改 MySQL 源码的人，也可以做在 MySQL 里面。基本思路就是，对于相同行的更新，在进入引擎之前排队。这样在 InnoDB 内部就不会有大量的死锁检测工作了。
也可以考虑通过将一行改成逻辑上的多行来减少锁冲突。以影院账户为例，可以考虑放在多条记录上，比如 10 个记录，影院的账户总额等于这 10 个记录的值的总和。这样每次要给影院账户加金额的时候，随机选其中一条记录来加。这样每次冲突概率变成原来的 1/10，可以减少锁等待个数，也就减少了死锁检测的 CPU 消耗。这个方案看上去是无损的，但其实这类方案需要根据业务逻辑做详细设计。如果账户余额可能会减少，比如退票逻辑，那么这时候就需要考虑当一部分行记录变成 0 的时候，代码要有特殊处理。
小结
- 全局锁主要用在
逻辑备份过程中。对于全部是 InnoDB 引擎的库，建议选择使用–single-transaction参数，对应用会更友好 - 表锁一般是在
数据库引擎不支持行锁的时候才会被用到的。如果你发现应用程序里有lock tables这样的语句，你需要追查一下，比较可能的情况是：要么是系统现在还在用MyISAM这类不支持事务的引擎，那要安排升级换引擎；要么是引擎升级了，但是代码还没升级 - MDL 会直到
事务提交才释放，在做表结构变更的时候，你一定要小心不要导致锁住线上查询和更新。 - 如果事务中需要锁多个行，要把最可能造成锁冲突、最可能影响并发度的锁的申请时机
尽量往后放。 - 调整语句顺序并不能完全避免死锁。所以我们引入了死锁和死锁检测的概念，以及提供了三个方案，来减少死锁对数据库的影响。减少死锁的主要方向，就是控制访问相同资源的并发事务量。
