主页 > 知识库 > 5分钟快速了解数据库死锁产生的场景和解决方法

5分钟快速了解数据库死锁产生的场景和解决方法

热门标签:铁路电话系统 服务外包 Linux服务器 地方门户网站 呼叫中心市场需求 AI电销 网站排名优化 百度竞价排名

前言

加锁(Locking)是数据库在并发访问时保证数据一致性和完整性的主要机制。任何事务都需要获得相应对象上的锁才能访问数据,读取数据的事务通常只需要获得读锁(共享锁),修改数据的事务需要获得写锁(排他锁)。当两个事务互相之间需要等待对方释放获得的资源时,如果系统不进行干预则会一直等待下去,也就是进入了死锁(deadlock)状态。

以下内容适用于各种常见的数据库管理系统,包括 Oracle、MySQL、Microsoft SQL Server 以及 PostgreSQL 等。

死锁是如何产生的?

演示死锁的产生非常简单,我们只需要创建一个包含两行数据的简单示例表:

CREATE TABLE t_lock(id int PRIMARY KEY, col int);
INSERT INTO t_lock VALUES (1, 100);
INSERT INTO t_lock VALUES (2, 200);

SELECT * FROM t_lock;
id|col|
--+---+
 1|100|
 2|200|

如果我们在不同事务中以不同的顺序修改数据,就可能引起事务之间的相互等待。一个事务等待另一个事务释放资源不会产生什么问题,但是如果两个事务互相等待对方的资源,数据库管理系统只有两个选择:无限等待或者中止一个事务并让另一个事务成功执行。

显然无限等待不是解决问题的方法,因此数据库通常是等待一定时间之后中止其中一个事务。

以下是一个死锁的演示案例:

事务一 事务二 备注
BEGIN; BEGIN; 分别开始两个事务
UPDATE t_lock
SET col = col + 100
WHERE id = 1;
UPDATE t_lock
SET col = col + 200
WHERE id = 2;
事务一修改 id=1 的数据,事务二修改 id=2 的数据
UPDATE t_lock
SET col = col + 100
WHERE id = 2;
事务一修改 id=2 的数据,需要等待事务二释放写锁
等待中… UPDATE t_lock
SET col = col + 200
WHERE id = 1;
事务二修改 id=1 的数据,需要等待事务一释放写锁
死锁 死锁 数据库检测到死锁,选择中止一个事务
更新成功 返回错误

对于 MySQL InnoDB,默认启用了 innodb_deadlock_detect 选项,事务二返回以下错误信息:

ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction

如果我们禁用 InnoDB 死锁检测选项,事务二在等待 50 s(innodb_lock_wait_timeout )后提示等待超时:

ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

Oracle 检测到死锁时返回以下错误:

ORA-00060: 等待资源时检测到死锁

Microsoft SQL Server 检测到死锁时返回的错误如下

消息 1205,级别 13,状态 51,第 7 行
事务(进程 ID 67)与另一个进程被死锁在 锁 资源上,并且已被选作死锁牺牲品。请重新运行该事务。

PostgreSQL 检测到死锁时返回的错误如下:

SQL 错误 [40P01]: 错误: 检测到死锁
  详细:进程32等待在事务 4765上的ShareLock; 由进程16552阻塞.
进程16552等待在事务 4766上的ShareLock; 由进程32阻塞.
  建议:详细信息请查看服务器日志.
  在位置:当更新关系"t_lock"的元组(0, 1)时

如何解决并避免死锁

死锁不是数据库自身的问题,我们无法通过优化数据库配置来解决或者避免死锁,只能通过修改应用程序来解决。简单来说,我们应该在程序中按照相同的顺序修改数据,避免产生相互等待资源的情况发生。例如:

事务一 事务二 备注
BEGIN; BEGIN; 分别开始两个事务
UPDATE t_lock
SET col = col + 100
WHERE id = 1;

UPDATE t_lock
SET col = col + 200
WHERE id = 1;
事务一和事务二都修改 id=1 的数据,后执行的事务需要等待
UPDATE t_lock
SET col = col + 100
WHERE id = 2;
等待中… 事务一修改 id=1 的数据,事务二等待中
COMMIT; 等待中… 事务一提交
UPDATE t_lock
SET col = col + 200
WHERE id = 2;
事务二继续修改 id=2 的数据
COMMIT; 事务二提交

以上场景不会产生死锁。不过,我们在实际应用中可能无法完全按照相同顺序修改数据。如果出现了不可避免的死锁情况,另一种解决方法就是捕获系统返回的死锁异常并在程序中加入重试机制。

总结

本文简要介绍了数据库死锁产生的原因和解决方法。到此这篇关于5分钟快速了解数据库死锁产生的场景和解决方法的文章就介绍到这了,更多相关数据库死锁内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家!

您可能感兴趣的文章:
  • mysql 数据库死锁原因及解决办法
  • Mysql 数据库死锁过程分析(select for update)
  • 简单说明Oracle数据库中对死锁的查询及解决方法
  • InnoDB数据库死锁问题处理
  • Mybatis update数据库死锁之获取数据库连接池等待
  • MySQL数据库的一次死锁实例分析
  • 讲解Oracle数据库中结束死锁进程的一般方法
  • 记一次公司仓库数据库服务器死锁过程及解决办法
  • 查询Sqlserver数据库死锁的一个存储过程分享
  • MySQL数据库之Purge死锁问题解析

标签:崇左 兰州 黄山 衡水 铜川 湖南 仙桃 湘潭

巨人网络通讯声明:本文标题《5分钟快速了解数据库死锁产生的场景和解决方法》,本文关键词  ;如发现本文内容存在版权问题,烦请提供相关信息告之我们,我们将及时沟通与处理。本站内容系统采集于网络,涉及言论、版权与本站无关。
  • 相关文章
  • 收缩
    • 微信客服
    • 微信二维码
    • 电话咨询

    • 400-1100-266