根据加锁的范围，MySQL的锁可以分为全局锁，表级锁和行锁。
1. 全局锁
一般用于全局逻辑备份操作；
1.1 FTWRL
MySQL提供了一个加全局读锁的方法。命令是：Flush tables with read lock（FTWRL），执行该命令以下语句会被阻塞：数据更新语句，数据定义语句和更新事务的提交语句。
优点：
1：适用于所有的引擎；
2：客户端执行命令后若发生异常断开，则自动释放锁；
1.2 mysqldump
MySQL自带的逻辑备份工具，当mysqldump使用参数 -single-transaction的时候，导数据前其启动一个事务来确保拿到一致性视图，因为MVCC的支持，这个过程中的数据也是可以正常更新的。
缺点：引擎必须支持这个隔离级别，InnoDB支持该级别；
1.3 readonly
通过设置参数 set global readonly = true，让全库进入只读状态
缺点：
1：在某些系统中，可能会通过该参数的值判断一个数据库是主库还是从库，修改该参数的方式影响较大，不建议使用；
2：客户端在 set global readonly = true 之后若发生异常，该锁不会释放，整个库将一直处于只读状态，风险较大；
2. 表级锁
表级锁有两种：一种是表锁，一种是元数据锁（meta data lock，MDL）。
2.1 表锁
加锁语法：lock tables [table1] read,[table2] write;，该语句执行后,：
当前线程可以读 table1，不能写 table1，其他线程可以读 table1，不能写 table1；
当前线程可以读写 table2，其他线程不可以读写 table2；
当前线程不可以访问其他表；
解锁语法：unlock tables; ，该操作会释放所有表锁；
2.2 MDL
2.2.1 作用
MDL不需要显示使用，访问一个表时自动加MDL锁。它的作用是：在读写期间，保证表结构的一致性；
2.2.2 读锁和写锁
读锁之间不互斥，多个线程可以同时对一个表进行增删改查；
读锁和写锁，写锁和写锁之间互斥，保证修改表结构操作的安全性；
假设事务A查询记录，事务B修改表结构，事务C查询记录；
当事务B获取到表的MDL写锁后，在事务B提交之前，事务B 之后的所有事务都需要进行等待；
MDL锁会直到事务提交才释放，做表结构变更的时候一定不能阻塞线程的增删改查操作；
2.2.3 等待机制
理想的机制是修改表结构时设置等待时间，在等待时间内获取到MDL锁则进行操作，否则放弃操作；
MariaDB 支持该功能：
alter table table_name nowait add ...;
alter table table_name wait n add ...;
3. 行锁
行锁由引擎层实现，并不是所有的引擎都支持行锁，InnoDB支持行锁。
在InnoDB的事务中，行锁在需要时进行加锁，事务结束后释放锁。这就是两阶段锁协议。
如果事务需要多个行锁，则尽可能将可能导致锁冲突的锁往后放；减少冲突锁的等待时间。
3.2 死锁和死锁检测
假设有两个事务同时进行，事务A要先修改记录1，再修改记录2，事务B要先修改记录2，再修改记录1；
当两个事务各自完成第一个操作后，都开始等待对方释放锁，这就形成了一个死锁；
解决死锁的策略：
1. 直接进入等待，直到超时。超时时间可通过 innodb_innodb_lock_wait_timeout 参数来设置，默认值为50；
超时时间设置过长业务一般无法接受，时间过短又容易出现误伤，一般采用第二种方案，即死锁检测，
2. 发起死锁检测，发现死锁后，主动回滚死锁链条中的某个事务，让其他事务继续执行，死锁检测可通过 innodb_deadlock_detect 参数设置为 on 开启该功能，默认值为 on；
死锁检测需要消耗CPU资源，如果某个时刻进行大量事务的死锁检测，这需要耗费大量的CPU资源，但是事务执行效率却很低；所以尽量控制这个并发数量；