gpt4 book ai didi

mysql - 解释莫名其妙的死锁

转载 作者:IT老高 更新时间:2023-10-29 00:12:03 24 4
gpt4 key购买 nike

首先,我完全看不出我怎么会出现任何死锁,因为我没有使用显式锁定,只涉及一个表,每个表都有一个单独的进程要插入、选择和更新行,一次只插入或更新一行,并且每个进程很少(可能一分钟一次)运行。

这是一个电子邮件队列:

CREATE TABLE `emails_queue` (
`id` varchar(40) NOT NULL,
`email_address` varchar(128) DEFAULT NULL,
`body` text,
`status_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
`status` enum('pending','inprocess','sent','discarded','failed') DEFAULT NULL,
KEY `status` (`status`),
KEY `status_time` (`status`,`status_time`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

生成过程响应某些用户操作,但大约每 90 秒一次,对表执行一次插入,将状态设置为“待处理”。

有一个监控过程,每分钟检查一次“待处理”和“失败”电子邮件的数量是否过多。运行时间不到一秒钟,而且从未给我带来任何麻烦。

发送进程每分钟都会抓取所有待处理的电子邮件。它循环遍历一次一封电子邮件,将其状态设置为“处理中”,尝试发送它,最后将其状态相应地设置为“已发送”、“已丢弃”(它有理由决定一封电子邮件不应该发出),或“失败”(被 SMTP 系统拒绝)。

设置状态的语句不正常。

UPDATE emails_queue SET status=?, status_time=NOW() WHERE id=? AND status = ?

也就是说,只有当当前状态已经达到我认为的状态时,我才会更新状态。在这个机制之前,我不小心启动了两个发送进程,它们都会尝试发送相同的电子邮件。现在,如果发生这种情况,一个进程会成功地将电子邮件从“待处理”移动到“处理中”,但第二个进程会更新零行,意识到存在问题,然后跳过该电子邮件。

问题是,大约有 100 次更新完全失败!我得到 com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: Deadlock found when trying to get lock;尝试重启事务

什么?

这是唯一发生这种情况的表和唯一查询,并且它只发生在生产中(以最大限度地增加调查难度)。

只有两件事看起来很不寻常:(1) 更新参与 WHERE 子句的列,以及 (2) status_time 的(未使用的)自动更新。

我正在寻找任何建议或诊断技术。

最佳答案

首先,死锁不依赖于显式锁定。 MySQL 的 LOCK TABLE 或使用非默认事务隔离模式不需要有死锁。如果您从不使用显式事务,您仍然会遇到死锁。

死锁很容易发生在单个表上。最常见的是来自单个热表。

如果您的所有事务都只执行单行插入,则甚至可能会发生死锁。

如果你有,可能会发生死锁

  • 不止一个数据库连接(显然)
  • 内部涉及多个锁的任何操作。

不明显的是,大多数时候,单行插入或更新涉及多个锁。这样做的原因是二级索引在插入/更新期间也需要锁定。

SELECT 不会锁定(假设您使用的是默认隔离模式,并且没有使用 FOR UPDATE)所以它们不可能是原因。

SHOW ENGINE INNODB STATUS 是你的 friend 。它会给你一堆(诚然非常困惑)关于死锁的信息,特别是最近的。

  • 您无法完全消除死锁,它们将继续在生产中发生(即使在测试系统上,如果对它们施加适当的压力)
  • 以尽可能少的死锁为目标。如果 1% 的交易死锁,那可能太多了。
  • 如果您完全理解其中的含义,请考虑将事务的事务隔离级别更改为已提交读
  • 确保您的软件能够正确处理死锁。

关于mysql - 解释莫名其妙的死锁,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/5970210/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com