数据库锁的设计，目的是为了处理并发问题。作为多用户共享的资源，当出现并发问题的时候，数据库需要合理地控制资源的访问规则。而锁就是用来实现这些访问规则的重要数据结构。
根据加锁的范围，MySQL里面的锁大致可以分成全局锁、表级锁和行锁三类。
全局锁
全局锁，就是对整个数据库实例加锁。MySQL提供了一个加全局读锁的方法，命令就是FTWRL，即Flush tables with read lock。当需要让整个数据库处于只读状态的时候，可以使用这个命令，之后其他线程的数据更新语句（数据的增删改）、数据定义语句（建表、修改表结构等）和更新类事务的提交语句都会被阻塞。
全局锁的典型使用场景，做全库逻辑备份。也就是把整个库每个表都select出来存成文本。以前的做法就是通过FTWRL确保不会有其他线程对数据库更新，然后对整个库做备份。在备份过程中整个库完全处于只读状态，如果在主库上做备份，则在备份期间不能执行更新，业务基本上就得停摆；如果在从库上备份，则在备份期间从库不能执行主库同步过来的binlog，会导致主从延迟。也就是说，如果不加锁的话，备份系统备份得到的库不是一个逻辑时间点，这个视图是逻辑不一致的。解决该问题的方法，就是在可重复读隔离级别下开启一个事务。
官方自带的逻辑备份工具是mysqldump。当mysqldump使用参数-single-transction的时候，导数据之前就会启动一个事务，来确保拿到一致性视图。而由于MVCC的支持，这个过程中是可以正常更新的。该功能虽好，但有前提，前提就是引擎要支持这个隔离级别，例如：对于MyISAM这种不支持事务的引擎来说，就需要使用FTWRL命令，不然在备份过程中有更新，总是能取到最新的数据，那么就破坏了备份的一致性。这也是DBA要求业务开发人员使用InnoDB替代MyISAM的原因之一。
其实，让全库处于只读状态还有一种方法：使用set global readonly=true。但是还是建议使用FTWRL方式。原因如下：
- 在某些系统中，readonly的值会被用来做其他逻辑，比如用来判断一个库是主库还是备库。因此，修改global变量的方式影响面更大，故不建议用。
- 在异常处理机制上有差异。如果执行FTWRL命令之后，由于客户端发生异常断开，那么mysql会自动释放这个全局锁，这个库回到可以正常更新的状态。而将这个库设置为readonly之后，如果客户端发生异常，则数据库就会一直保持readonly状态，这样会导致整个库长时间处于不可写状态，风险较高。
表级锁
MySQL里面表级别的锁有两种：表锁和元数据锁。
表锁
表锁的语法是lock tables ... read/write。可以用unlock tables主动释放锁，也可以在客户端断开的时候自动释放。但注意lock tables语法除了会限制别的线程的读写外，也限定了本线程接下来的操作对象。例如：线程A中执行lock tables t1 read，t2 write;这个语句，则其他线程写t1、读写t2的语句都会被阻塞。同时，线程A在执行unlock tables之前，也只能执行读t1、读写t2的操作。连写t1都不允许，自然也不能访问其他表。
元数据锁（MDL，metadata lock）
MDL不需要显式使用，在访问一个表的时候会被自动加上。MDL的作用是保证读写的正确性。可以想象一下，如果一个查询正在遍历一个表中的数据，而执行期间另一个线程对这个表结构做变更，删了一列，那么查询线程拿到的结果跟表结构对不上，肯定是不行的。因此，在MySQL5.5版本中引入了MDL，当对一个表做增删改查操作的时候，加MDL读锁；当要对表做结构变更操作的时候，加MDL写锁。
- 读锁之间不互斥，因此可以有多个线程同时对一张表增删改查；
- 读写锁之间、写锁之间是互斥的，用来保证变更表结构操作的安全性。因此，如果有两个线程要同时给一个表加字段，其中一个要等另一个执行完才能开始执行。
行锁
MySQL的行锁是在引擎层由各个引擎自己实现的，但并不是所有的引擎都支持行锁，例如：MyISAM引擎就不支持行锁。不支持行锁意味着并发控制只能使用表锁，对于这种引擎的表，同一张表上任何时刻只能有一个更新在执行，这就会影响到业务并发度。InnoDB是支持行锁的，这是MyISAM被InnoDB替代的重要原因之一。
行锁，顾名思义，就是针对数据表中行记录的锁。这也很好理解，比如事务A更新了一行，而这时候事务B也要更新同一行，则必须等事务A的操作完成后才能进行更新。
两阶段锁
在InnoDB事务中，行锁是在需要的时候才加上的，但并不是不需要了就立刻释放，而是要等到事务结束才释放。这就是两阶段锁协议。在这个协议下，如果事务中需要锁多行，要把最可能造成锁冲突、最可能影响并发度的锁尽量往后放。这样做可以最大程度地减少了事务之间的锁等待，提升了并发度。
死锁和死锁检测
当并发系统中不同线程出现循环资源依赖，涉及的线程都在等待别的线程释放资源时，就会导致这几个线程都进入无限等待的状态，称为死锁。当出现死锁以后，有两种策略：
- 直接进入等待，直到超时。这个超时时间可以通过参数innodb_lock_wait_timeout来设置。
- 发起死锁检测，发现死锁后，主动回滚死锁链条中的某个事务，让其他事务得以继续执行。将参数inndb_deadlock_detect设置为on，表示开启这个逻辑。
在InnoDB中，innodb_lock_wait_timeout的默认值是50s，意味着如果采用第一个策略,当出现死锁以后，第一个被锁住的线程要过50才会超时退出，然后其他线程才有可能继续执行。对于在线服务来说，这个等待时间往往是无法接受的。但是，如果我们把这个值设得特别的小，当出现死锁的时候，确实很快就可以解开，但是如果不是死锁，而是简单的锁等待，那就“误伤”了这个线程。
如果采用的是第二种策略，即：主动死锁检测，而且innodb_deadlock_detect的默认值本身就是on。主动死锁检测在发死锁的时候，是能够快速发现并进行处理的，但是这个策略也有额外的负担。因为这个过程是这样的，每当一个事务被锁住的时候，就要看看它所依赖的线程有没有被别人锁住，如此循环，最后判断是否出现了循环等待，也就是死锁。
我们可以想想，每个新来的被堵住的线程，都要判断会不会由于自己的加入导致了死锁，这是一个时间复杂度是O(n)的操作。假设有1000个并发线程要同时更新同一行，那么死锁检测操作就是100万这个量级的。虽然最终检测结果是没有死锁，但是这个期间要消耗大量的CPU资源。因此，就会出现cpu利用率很高，但是每秒却执行不了几个事务。
接下来讨论如何去解决由这种热点行更新导致的性能问题，这个问题的症结在于，死锁检测要消耗大量的CPU资源。解决方法如下： - 若能确保这个业务一定不会出现死锁，可以临时把死锁检测关掉。但是这种操作本身带有一定的风险，因为业务设计的时候一般不会把死锁当作一个严重错误，毕竟出现死锁了，就回滚，然后通过业务重试一般就没问题了，这是业务无损的。而关掉死锁检测意味着可能会出现大量的超时，这是业务有损的。
- 控制并发度。如果并发能够控制住，比如用一行同时最多只有10个线程在更新，那么死锁检测的成本很低，就不会出现这个问题一个直接的想法就是，在客户端做并发控制，但是这个方法不可行，因为客户端很多。做并发控制要做在数据库服务器，可以使用中间件，也可以修改mysql的源码，基本思路就是，对于相同行的更新，在进入引擎之前排队。
