您好，登录后才能下订单哦！
密码登录
登录注册
点击 登录注册 即表示同意《亿速云用户服务条款》
这篇文章的知识点包括：全局锁、表级锁和行锁的概念和使用、解决死锁和避免死锁检测的损耗，阅读完整文相信大家对数据库的锁有了一定的认识。
全局锁会让整个库处于只读状态，其他线程语句（DML，DDL，更新事务类）的语句都被会阻塞。
在做全库逻辑备份时，会把整库进行 select 然后保存成文本。
想象这样一个场景，要备份一个购买系统，其中购买操作设计到更新账号余额表和用户课程表。
现在进行逻辑备份，在备份过程中，一位用户购买了一门课程，这时需要在余额表扣掉余额，然后在购买的课程中加上一门课。正确的顺序肯定是先进行购买操作，减少余额和增加课程然后在进行备份。但却有可能出现这样的问题：
如果在时间顺序上先备份余额表 (u_account)，然后用户购买(操作两张表)，再备份用户课程表(u_course)？
这时用备份的数据做恢复时，会发现用户没花钱却买了一堂课。原因在于，先备份余额表，说明用户余额不变。之后才进行购买操作，余额表减钱，课程表增加一门课程。接着备份课程表，课程表课程加一。购买操作在已经备份完的余额表后进行。
如果在时间顺序上先备份用户课程表(u_course)，然后用户购买(操作两张表)，再备份余额表 (u_account)？
同样的，如果先备份课程表，课程没有增加，因为没有进行购买操作。之后进行购买操作后，余额表减钱，然后被备份。就出现了，用户花钱却没有购买成功的情况。
也就是说，不加锁的话，备份系统的得到的库不是一个逻辑时间点，这个视图是逻辑不一致。
对于不支持事务的引擎，像 MyISAM. 通过使用 Flush tables with read lock (FTWRL) 命令来开启全局锁。
但使用 FTWRL 存在的问题是：
对于支持事务并且开启一致性视图（可重复读级别）下配合上 MVCC 的功能的引擎（InnoDB），备份就很简单了。
使用官方的 mysqldump 工具时，加上 --single-transaction 选项，再导出数据前就会启动一个事务，来确保拿到一致性视图。并且由于 MVCC 的支持，同时可以进行更新操作。
为什么不推荐使用 set global readonly=true ，要使用 FTWRL ：
在有些系统中，readonly 的值会被用来做其他逻辑，比如用来判断一个库是主库还是备库。因此，修改 global 变量的方式影响面更大，不建议使用。
在异常处理机制上有差异。
执行 FTWRL 命令之后由于客户端发生异常断开，那么 MySQL 会自动释放这个全局锁，整个库回到可以正常更新的状态。
将整个库设置为 readonly 之后，如果客户端发生异常，则数据库就会一直保持 readonly 状态，这样会导致整个库长时间处于不可写状态，风险较高。
表级锁的作用域是对某张表进行加锁，在 MySQL 中表级别的锁有两种，一种是表锁，一种是元数据锁（meta data lock，MDL）。
与 FTWRL 类似，可以使用 lock tables … read/write 来锁定某张表。在释放时，可以使用 unlock tables 来释放锁或者断开连接时，主动释放。
需要注意的是，这样方式的锁表，不但会限制其他线程的读写，也限定了自己线程的操作对象。
假如，线程 A 执行 lock tables t1 read, t2 write; 操作。
这时对于表 t1 来说，其他线程只能只读，线程 A 也只能只读，不能写。
对于表 t2 来说，只允许线程 A 读写，其他线程读写都会被阻塞。
与表锁手动加锁不同，元数据锁会自动加上。
为什么要有 MDL？
MDL 保证的就是读写的正确性，比如在查询一个中的数据时，此时另一个线程改变了表结构，查询的结果和表结构不一致肯定不行。简单来说，*MDL 就是解决 DML 和 DDL 之间同时操作的问题。*
在 MySQL 5.5 引入了 MDL，在对一个进行 DML 时，会加 DML 读锁。进行 DDL 时，会加 MDL写锁。
读锁间不互斥，允许多个线程同时对同一张表进行 DML。
读写锁之间、写锁之间是互斥的，用来保证变更表结构操作的安全性。
MDL 引发的问题？
给表加字段，却导致库挂了？
由于 MDL 是自动加的，并且在给表加字段或者修改字段或者加索引时，需要扫描全表的数据。所以在对大表操作时，要非常小心，以免对线上的服务造成影响。但实际上，操作小表时，也可能出问题。假设 t 是小表。按照下图所示，打开四个 session.
MySQL 5.7.27
假设有一张叫 sync_test 的表：
mysql> desc sync_test;
+-------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-------+--------------+------+-----+---------+----------------+
| id | int(11) | NO | PRI | NULL | auto_increment |
| name | varchar(255) | NO | | NULL | |
+-------+--------------+------+-----+---------+----------------+
2 rows in set (0.00 sec)开启事务1, 插入数据。对于事务 1 来说，自动申请了表 sync_test 的 MDL 读锁：
开启事务2，插入数据。对于事务 2 来说，自动申请了表 sync_test 的 MDL 读锁：
开启事务3，改变表结构。对于事务 3 来说，会申请表 sync_test 的 MDL 写锁，这时由于读写锁互斥，被阻塞：
开启事务 4，插入数据。对于事务 4 来说，会申请 sync_test 的 MDL 读锁，由于之前事务 3 提前申请了写锁，互斥所以被阻塞：
这时如果在这张表上的查询语句很频繁，而且客户端有重连机制，在超时后会再起一个新 session 请求，这个库的线程就很快会爆满了。
通过上面的例子也可以看到，MDL 会直到事务提交才释放，在做表结构变更的时候，一定要小心不要导致锁住线上查询和更新。在开启事务后，并没有在短时间内结束，也就是由于所谓的长事务造成的。如果想对某个表进行 DDL 的操作时，可以先查询下是否有长事务的运行（information_schema 下的 innodb_trx 表），可以先 kill 这个事务，然后做 DDL 操作。
但有时 kill 也未必可以，在表被频繁使用时，新的事务可能马上就来了。比较理想的情况，在 alter table 中设定等待时间，如果在时间内拿到最好，否则就放弃，不要阻塞语句。之后再重复这个操作。
MariaDB 已经合并了 AliSQL 的这个功能，所以这两个开源分支目前都支持 DDL NOWAIT/WAIT n 这个语法。
ALTER TABLE tbl_name NOWAIT add column ...
ALTER TABLE tbl_name WAIT N add column ...MySQL 的行锁是由引擎层自己实现的，所有不是所有的引擎都执行行锁，比如在 MyISAM 引擎就不支持行锁。不支持行锁意味着并发控制只能用表锁，这就造成了在同一时刻只有一个更新在执行，就影响到了业务的并发度。InnoDB 支持行锁是让 MyISAM 被取代的重要原因。
行锁就是对数据库表中行记录的锁。比如事务 A，B 同时想要更新一行数据，在更新时一定会按照一定的顺序进行，而不能同时更新。
行锁的目的就是减少像表级别的锁冲突，来提升业务的并发度。
在 InnoDB 的事务中，行锁是在需要的时候在加上，但并不是使用完就释放，而是在事务结束后才释放，这就是两阶段锁协议。
假设有一个表 t，事务 A, B 操作表 t 的过程如下：
在事务 A 的两条语句更新后，事务 B 更新操作会被阻塞。直到事务 A 中执行 commit 操作后才能执行。
由于两阶段锁的特点，在事务结束时才会释放锁，所以需要遵循的一个原则是事务中需要锁多个行时，把有可能造成锁冲突，最可能影响并发度的锁尽量向后放。
比如购买课程的例子，顾客 A 购买培训机构 B 一门课程。涉及到操作：
对于第二个操作，当有许多人同时购买时并发度就较高，出现锁冲突的情况也较高。所以将操作 2 放置一个事务的最后就更好。
当有时并发度过大时，我们会发现一种现象 CPU 的使用率接近 100%，但事务执行数量却很少。这就可能出现了死锁。
当并发系统中不同的线程出现循环的资源依赖，等待别的线程释放资源时，就会让涉及的线程处于一直等待的情况。这就称为死锁。
如上图中，事务 A 对id =1 的所在行，加入了行锁。等待 id=2 的行锁。事务 B 对 id = 2 的行，加入了行锁。等待 id=1 的行锁。事务 A，B 等待对方资源的释放。
方式 一： 设置死锁的等待时间 innodb_lock_wait_timeout
还是 sync_test 这张表，模拟简单的锁等待情况，注意这里并不是死锁。开启两个事务 A，B. 同时对 id=1 这行进行更新。
事务 A 更新操作：
mysql> begin;
Query OK, 0 rows affected (0.00 sec)
mysql> update sync_test set name="dead_lock_test" where id = 1;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0事务 B 更新操作：
mysql> begin;
Query OK, 0 rows affected (0.00 sec)
mysql> update sync_test set name="dead_lock_test2" where id = 1;
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction可以看到事务 B 抛出了死锁等待的错误。
设置等待时间的问题
在 InnoDB 中，MySQL 默认的死锁等待时间是 50s. 意味着在出现死锁后，被锁住的线程要过 50s 被能退出，这对于在线服务说，等待时间过长。但如果把值设置的过小，如果是像上述例子这样是简单的锁等待呢，并不是死锁怎么办，就会出现误伤的情况。
方式二：发起死锁检测，发现死锁后，主动回滚某个事务，让其他事务继续执行。
MySQL 中默认就是打开状态，能够快速发现死锁的情况。
set innodb_deadlock_detect=on事务 A，B 互相依赖，造成死锁的例子：
开启事务 A:
mysql> begin;
mysql> update sync_test set name="dead_lock_test1" where id = 1;开启事务 A:
mysql> begin;
mysql> update sync_test set name="dead_lock_test3" where id = 3;继续操作事务 A:
mysql> update sync_test set name="dead_lock_test3_1" where id = 3;
# 会出现阻塞的情况继续操作事务 B:
mysql> update sync_test set name="dead_lock_test1_2" where id = 1;
ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction此时事务 A 阻塞取消，执行成功。
不过检测死锁也是有额外负担的，每当一个事务被锁的时候，就要看看它所依赖的线程有没有被别人锁住，如此循环，最后判断是否出现了循环等待，也就是死锁。如果是所有事务都要更新同一行的场景呢？每个新来的被堵住的线程，都要判断会不会由于自己的加入导致了死锁，这是一个时间复杂度是 O(n) 的操作。假设有 1000 个并发线程要同时更新同一行，那么死锁检测操作就是 1000*1000=100 万这个量级的。
所以，对于更新频繁并发量大的表，死锁检测会导致消耗大量的 CPU.
方法一：如果保证业务一定不会出现死锁，可以临时把死锁检查关掉。
但这样存在一定的风险，因为业务设计时不会把死锁当做严重的问题，出现死锁后回滚后，再重试就没有问题了。但关掉死锁检测后，可能出现大量超时的情况。
方法二：控制并发度。
如果对于并发量能控制，比如同一行同时最多只有 10 个线程在更新，那么死锁检测的成本很低，就不会出现这个问题。具体来说在客户端做并发控制，但对于客户端较多的应用，也无法控制。所以并发控制在数据库服务端，如果有中间件，也可以考虑在中间件中实现。
方法三：降低死锁的概率
将一行统计的结构，拆成多行累计的结构。比如将之前某个教学机构的金额由一行拆成 10 行，总收入就等于这 10 行数据的累计。这样原来锁冲突的概率变为原来的 1/10, 也就减少了死锁检测的 CPU 消耗。但在一部分行记录变成0 时，代码需要特殊处理。
看完上述内容，你们对数据库的锁有进一步的了解吗？如果还想学到更多技能或想了解更多相关内容，欢迎关注亿速云行业资讯频道，感谢各位的阅读。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。