根据加锁的范围，MySQL 里面的锁大致可以分为全局锁，表级锁和行锁三类。
全局锁
全局锁是指对整个数据库实例加锁。
通过命令 ：Flush tables with read lock (FTWRL) ；可以给数据库加一个全局读锁，使整个库处于只读状态。此时其他线程的以下语句会被堵塞：数据更新语句（数据的增删改查）、数据定义语句（包括建表、修改表结构等）和更新类事务的提交语句。
全局锁的典型使用场景是：做全库逻辑备份。但是在做备份时整个库完全处于只读状态，比较危险。
官方自带的逻辑备份工具是mysqldump。使用参数 -single-transaction的时候，导数据之前就会启动一个事务，来确保拿到一致性视图。参数 -single-transaction只适用于支持事务的数据库引擎，对于不支持事务的引擎，只能通过FTWRL方式。
命令：mysqldump -h127.0.0.1 -uroot -p123456 --single-transaction --default-character-set=utf8 accounting_global zg_tenant_entity > /tmp/ccc.sql
表级锁
MySQL 中表级别的锁有两种：一种是表锁，一种是元数据锁（meta data lock，MDL）。
- 表锁
表锁一般是在数据库引擎不支持行锁的时候才会被用到的。
语法：lock tables... read/write。
解锁：unlock tables此命令可以主动释放锁,也可以在客户端断开连接的时候自动释放。
需要注意的是：写锁是排他锁，写锁意味着其他线程不能读也不能写。读锁是共享锁，加上后其他锁只能读不能写，本线程也不能写。 例子：如果在某个线程 A 中执行 lock tables t1 read, t2 write; 这个语句，则其他线程写 t1、读写 t2 的语句都会被阻塞。同时，线程 A 在执行 unlock tables 之前，也只能执行读 t1、读写 t2 的操作。连写 t1 都不允许，自然也不能访问其他表。
- MDL（metadata lock） MDL作用是防止DDL和DML并发的冲突
MySQL 5.5 版本中引入了 MDL，当对一个表做增删改查操作DML的时候，加 MDL 读锁；当要对表做结构变更操作DDL的时候，加 MDL 写锁。
- 读锁之间不互斥，因此你可以有多个线程同时对一张表增删改查。
- 读写锁之间、写锁之间是互斥的，用来保证变更表结构操作的安全性。 因此，如果有两个线程要同时给一个表加字段，其中一个要等另一个执行完才能开始执行。
- 如果对线上一个频繁DML操作的表做DDL如添加字段等操作，可能会导致死锁，使数据库连接资源被消耗完，导致数据库宕机。安全的解决方式是对表做DDL如添加字段时，设置执行语句的超时时间，写锁超时自动释放，不影响读锁。
行锁
行锁是指对数据表中行记录的锁。
两阶段锁
在 InnoDB 事务中，行锁是在需要的时候才加上的，但并不是不需要了就立刻释放，而是要等到事务结束时才释放。这个就是两阶段锁协议。
根据两阶段锁协议，我们在实际业务中可以参考：如果事务中需要锁多个行，要把最可能造成锁冲突、最可能影响并发度的锁尽量往后放。
死锁和死锁检测
当并发系统总不同线程出现循环资源依赖，涉及的线程都在等待别的线程释放资源时，就会导致这几个线程都进入无限等待状态，称为死锁。
当出现死锁后，有两种策略：
-
一种策略是，直接进入等待，直到超时。这个超时时间可以通过
innodb_lock_wait_timeout来设置。- 超时时间的设置很难控制，时间长了，某些业务无法接受，时间短了会误伤锁等待。一般不推荐使用
-
另一种策略是，发起死锁检测，发现死锁后，主动回滚死锁链条中的某一个事务，让其他事务得以继续执行，这个就叫主动死锁检测。将参数
innodb_deadlock_detect设置为on，表示开启这个逻辑，默认就是开启。
主动死锁检测
这种策略是会对cpu造成压力的，因为：每当一个事务被锁的时候，就要看看它所依赖的线程有没有被别人锁住，如此循环，最后判断是否出现了循环等待（死锁）；如果这种场景出现在热点数据上，即很多并发线程同时更新同一行数据，那么死锁检测操作就是O(n2)级别（假设100个线程就是100*100）。
热点行更新的解决策略:
降低并发度
-
拆行，一行拆多行
-
Server 层限流，即同一时间进入更新的线程数
-
关闭死锁监测（关闭的弊端是可能超时较多）
