MySQL高级讲座篇之：MySQL锁机制全景图：行锁、表锁与意向锁的层级关系。 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

各位观众老爷们，大家好！我是你们的老朋友，今天咱们来聊聊MySQL里那些“锁事儿”。保证让你们听得懂，记得住，用得上！

今天要讲的是MySQL的锁机制，听起来好像很高大上，其实也没那么玄乎。锁，说白了，就是为了解决并发访问时的数据安全问题。你想想，好比你们家只有一个厕所，你上的时候肯定要锁门，防止别人闯进来跟你抢位置，对吧？MySQL的锁也是这个道理，防止多个用户同时修改同一份数据，导致数据混乱。

咱们今天就从最基本的锁类型说起，然后一层一层深入，争取把MySQL的锁机制给扒个底朝天！

一、锁的分类：从粒度大小说起

MySQL的锁，按照锁定的范围大小，可以分为这么几种：

全局锁 (Global Lock)：锁定整个数据库实例。
表锁 (Table Lock)：锁定整张表。
行锁 (Row Lock)：锁定表中的某一行或多行。
页面锁 (Page Lock)：锁定数据页（介于表锁和行锁之间，MySQL中不常用，主要是存储引擎InnoDB支持）。

锁定的范围越大，并发性就越低，但开销也越小；反之，锁定的范围越小，并发性越高，但开销也越大。这就好比，你要保护一个文件，你可以把整个房子锁起来（全局锁），也可以只锁住放文件的抽屉（行锁）。锁的开销不同，保护的粒度也不同。

二、全局锁 (Global Lock)：一锁锁全家

全局锁，顾名思义，就是把整个数据库实例都锁住。这就好比你把整个小区都封锁了，谁也别想进出。

应用场景：

做全库逻辑备份。

如何加锁/解锁：

-- 加全局锁
FLUSH TABLES WITH READ LOCK;

-- 解锁
UNLOCK TABLES;

优点：

简单粗暴，备份数据时可以保证数据的一致性。

缺点：

会阻塞所有数据更新语句（DML），以及数据定义语句（DDL）。在生产环境中使用要非常谨慎，因为可能会导致服务停止。
如果数据库很大，备份时间很长，那么阻塞的时间也会很长，对业务影响很大。

更好的选择：

在MySQL 5.7之后，可以使用mysqldump --single-transaction参数来进行逻辑备份，这个参数会在备份开始时启动一个事务，利用MVCC来保证数据的一致性，而不需要加全局锁。

三、表锁 (Table Lock)：锁一张表，影响一大片

表锁，锁定的范围是一张表。当你对一张表加了表锁，其他用户就不能对这张表进行写操作了，甚至有些情况下，连读操作都不行。

表锁的分类：

表读锁 (Table Read Lock)：允许其他用户读，不允许其他用户写。
表写锁 (Table Write Lock)：不允许其他用户读，也不允许其他用户写。

应用场景：

对MyISAM引擎的表进行操作时，可能会用到表锁。
在某些特定的场景下，需要对表进行整体性的维护或操作。

如何加锁/解锁：

-- 加表读锁
LOCK TABLE table_name READ;

-- 加表写锁
LOCK TABLE table_name WRITE;

-- 解锁
UNLOCK TABLES;

注意：

使用LOCK TABLES命令加锁后，只能访问被锁定的表，不能访问其他表。
一定要记得UNLOCK TABLES，否则可能会导致死锁。

表锁的优缺点：

优点： 开销小，加锁速度快。
缺点： 并发性差，容易发生锁冲突。

代码示例：

假设有两个用户A和B，都要访问表users。

用户A：

LOCK TABLE users READ; -- 加表读锁
SELECT * FROM users;  -- 可以读
-- UPDATE users SET name = 'new name' WHERE id = 1; -- 会报错，因为加的是读锁
UNLOCK TABLES;

用户B：

在用户A加了表读锁之后：

SELECT * FROM users;  -- 可以读，因为是读锁
-- UPDATE users SET name = 'new name' WHERE id = 1; -- 会阻塞，直到A释放锁

如果用户A加的是表写锁，那么用户B的读写操作都会被阻塞。

四、行锁 (Row Lock)：精准打击，并发之王

行锁，锁定的范围是表中的某一行或多行。只有InnoDB存储引擎才支持行锁。行锁是MySQL中并发性最高的锁，但开销也最大。

行锁的种类：

共享锁 (Shared Lock, S Lock)：允许其他事务读取被锁定的行，但不允许其他事务修改。
排他锁 (Exclusive Lock, X Lock)：不允许其他事务读取或修改被锁定的行。

如何加锁：

行锁是由InnoDB存储引擎自动管理的，不需要手动加锁。只有在事务中，通过特定的SQL语句，才会触发行锁。

共享锁 (S Lock)： 通过SELECT ... LOCK IN SHARE MODE语句来获取。
排他锁 (X Lock)： 通过SELECT ... FOR UPDATE语句、UPDATE语句或DELETE语句来获取。

代码示例：

假设有两个用户A和B，都要修改表accounts中id为1的账户余额。

用户A：

START TRANSACTION;
SELECT balance FROM accounts WHERE id = 1 FOR UPDATE; -- 获取排他锁
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
COMMIT;

用户B：

START TRANSACTION;
SELECT balance FROM accounts WHERE id = 1 FOR UPDATE; -- 会阻塞，直到A释放锁
UPDATE accounts SET balance = balance + 50 WHERE id = 1;
COMMIT;

在这个例子中，用户A通过SELECT ... FOR UPDATE语句获取了id为1的账户行的排他锁，所以用户B在执行相同的语句时会被阻塞，直到用户A提交事务释放锁。这样就保证了并发修改账户余额时的安全性。

行锁的优缺点：

优点： 并发性高，可以减少锁冲突。
缺点： 开销大，加锁速度慢。

五、意向锁 (Intention Lock)：预告片的角色

意向锁是一种表级别的锁，用来表明某个事务正在持有或者想要获取某个表中的行锁。有了意向锁，就不需要在每次加行锁的时候都遍历整张表来判断是否有其他事务持有该表的锁，提高了效率。

意向锁的种类：

意向共享锁 (Intention Shared Lock, IS Lock)：表明事务想要在表中的某些行上加共享锁。
意向排他锁 (Intention Exclusive Lock, IX Lock)：表明事务想要在表中的某些行上加排他锁。

意向锁的兼容性：

	意向共享锁 (IS)	意向排他锁 (IX)	共享锁 (S)	排他锁 (X)
意向共享锁 (IS)	√	√	√	×
意向排他锁 (IX)	√	×	×	×
共享锁 (S)	√	×	√	×
排他锁 (X)	×	×	×	×

意向锁的作用：

快速判断表是否可以加锁： 当一个事务想要对一张表加表锁时，只需要检查该表是否存在意向锁即可。如果存在意向排他锁，说明有其他事务正在修改该表中的数据，那么该事务就不能加表锁。
提高并发性： 意向锁的存在，使得行锁和表锁可以并发执行。例如，一个事务正在对表中的某些行加行锁，而另一个事务可以同时对整张表加表读锁（共享锁）。

举个例子：

事务A想要修改products表中id为1的商品信息，它会先在products表上加上一个意向排他锁（IX Lock），然后再在id为1的行上加上一个排他锁（X Lock）。
事务B想要对products表进行全表扫描，它会先尝试在products表上加一个共享锁（S Lock）。因为products表上已经存在意向排他锁（IX Lock），所以事务B会被阻塞，直到事务A释放锁。
事务C想要修改products表中id为2的商品信息，因为products表上只存在意向排他锁（IX Lock），所以事务C可以在id为2的行上加上一个排他锁（X Lock），而不会被阻塞。

意向锁的总结：

意向锁是表级别的锁。
意向锁是由InnoDB存储引擎自动管理的，不需要手动加锁。
意向锁的作用是表明事务想要在表中的某些行上加行锁，提高并发性。

六、锁的层级关系：金字塔结构

把全局锁、表锁、行锁和意向锁放在一起，可以看作是一个金字塔结构：

            全局锁 (Global Lock)
                /      
               /        
              /          
         表锁 (Table Lock)     页面锁（Page Lock）(不常用)
            /  
           /    
          /      
意向锁 (Intention Lock)   
          /
         /
        /
行锁 (Row Lock)

全局锁是最大的锁，锁定整个数据库实例。
表锁锁定整张表。
意向锁是表级别的锁，用来表明事务想要在表中的某些行上加行锁。
行锁是最小的锁，锁定表中的某一行或多行。

七、死锁 (Deadlock)：锁的噩梦

死锁是指两个或多个事务互相持有对方需要的锁，导致所有事务都无法继续执行的情况。这就好比两个人过独木桥，谁也不让谁，结果谁也过不去。

死锁的常见场景：

交叉锁： 两个事务分别持有对方需要的锁。
- 事务A：获取表orders的行锁，然后尝试获取表products的行锁。
- 事务B：获取表products的行锁，然后尝试获取表orders的行锁。
如果事务A和事务B同时执行，就可能发生死锁。
循环依赖： 多个事务形成一个循环依赖的锁链。

如何避免死锁：

尽量以相同的顺序访问资源： 如果多个事务都需要访问相同的资源，尽量保证它们以相同的顺序访问，可以减少死锁的发生。
避免长时间持有锁： 事务的执行时间越长，发生死锁的概率就越高。尽量缩短事务的执行时间，减少锁的持有时间。
使用较低的隔离级别： 较高的隔离级别会增加锁的竞争，导致死锁的概率增加。可以考虑使用较低的隔离级别，例如读已提交（READ COMMITTED）。
设置锁超时时间： 如果事务在等待锁超时后仍然无法获取锁，可以主动放弃锁，释放资源，避免死锁。
使用死锁检测机制： MySQL会自动检测死锁，并回滚其中一个事务，释放资源，解决死锁。

如何查看死锁信息：

查看SHOW ENGINE INNODB STATUS的输出： 这个命令会显示InnoDB存储引擎的状态信息，包括死锁信息。
查看错误日志： MySQL会将死锁信息记录到错误日志中。

代码示例（模拟死锁）：

用户A：

START TRANSACTION;
SELECT * FROM accounts WHERE id = 1 FOR UPDATE;
-- 模拟等待
SELECT SLEEP(5);
SELECT * FROM accounts WHERE id = 2 FOR UPDATE;
COMMIT;

用户B：

START TRANSACTION;
SELECT * FROM accounts WHERE id = 2 FOR UPDATE;
SELECT * FROM accounts WHERE id = 1 FOR UPDATE; -- 会被阻塞，并最终导致死锁
COMMIT;

在这个例子中，用户A先获取了id为1的账户行的排他锁，然后尝试获取id为2的账户行的排他锁；用户B先获取了id为2的账户行的排他锁，然后尝试获取id为1的账户行的排他锁。这样就形成了交叉锁，导致死锁。

八、总结：锁的应用之道

MySQL的锁机制是一个复杂而重要的概念。了解各种锁的特性和应用场景，可以帮助我们编写出更高效、更安全的SQL代码。

选择合适的锁粒度： 根据实际情况选择合适的锁粒度，在并发性和开销之间取得平衡。
避免长时间持有锁： 尽量缩短事务的执行时间，减少锁的持有时间。
预防死锁： 尽量以相同的顺序访问资源，避免循环依赖。
监控死锁： 及时发现和解决死锁问题。

好啦，今天的MySQL锁机制讲座就到这里。希望大家有所收获，以后在遇到锁相关的问题时，能够胸有成竹，迎刃而解！记住，锁不是洪水猛兽，而是保护数据的卫士！只要合理使用，就能让你的数据库更加安全、高效！下次再见！

发表回复 取消回复

发表回复取消回复