尝试获取锁时发现哪个查询导致死锁;尝试重新启动事务

发布于 2024-12-10 03:35:10 字数 839 浏览 1 评论 0原文

我无法弄清楚哪个查询导致尝试获取锁定时发现死锁;尝试重新启动事务。 我的 mysql 包装器具有以下几行

if (mysql_errno($this->conn) == 1213) {
  $this->bug_log(0,"Deadlock. SQL:".$this->sql);
}

,其中 bug_log 写入文件。

bug日志文件没有死锁错误,但/var/log/mysqld.log有多个记录:

111016  3:00:02 [ERROR] /usr/libexec/mysqld: Deadlock found when trying to get lock; try restarting transaction
111016  3:00:02 [ERROR] /usr/libexec/mysqld: Sort aborted
111016  3:00:02 [ERROR] /usr/libexec/mysqld: Deadlock found when trying to get lock; try restarting transaction
111016  3:00:02 [ERROR] /usr/libexec/mysqld: Sort aborted
111016  3:00:02 [ERROR] /usr/libexec/mysqld: Deadlock found when trying to get lock; try restarting transaction
111016  3:00:02 [ERROR] /usr/libexec/mysqld: Sort aborted

我如何追踪它?

I cannot figure out which Query is causing Deadlock found when trying to get lock; try restarting transaction.
My wrapper for mysql has the following lines

if (mysql_errno($this->conn) == 1213) {
  $this->bug_log(0,"Deadlock. SQL:".$this->sql);
}

where bug_log writes to a file.

The bug log file has no Deadlock errors, but /var/log/mysqld.log has multiple records:

111016  3:00:02 [ERROR] /usr/libexec/mysqld: Deadlock found when trying to get lock; try restarting transaction
111016  3:00:02 [ERROR] /usr/libexec/mysqld: Sort aborted
111016  3:00:02 [ERROR] /usr/libexec/mysqld: Deadlock found when trying to get lock; try restarting transaction
111016  3:00:02 [ERROR] /usr/libexec/mysqld: Sort aborted
111016  3:00:02 [ERROR] /usr/libexec/mysqld: Deadlock found when trying to get lock; try restarting transaction
111016  3:00:02 [ERROR] /usr/libexec/mysqld: Sort aborted

How can i track it down?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

眼泪淡了忧伤 2024-12-17 03:35:10

如果另一个事务等待当前事务完成,则使用 WHERE 子句而不是通过唯一列进行更新将导致死锁。下面是一个快速测试:

CREATE TABLE test (pk int PRIMARY KEY, a int);
INSERT INTO test VALUES (0, 0);
INSERT INTO test VALUES (1, 0);

会话 1

BEGIN;
SELECT a FROM test WHERE pk=0 FOR UPDATE;

会话 2

BEGIN;
SELECT a FROM test WHERE pk=0 FOR UPDATE;

(会话 2 现已被阻止)

会话 1

UPDATE test SET a=1 WHERE a>0;

在会话 2 中,我们收到错误

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

如果在更新的 WHERE 子句中我们仅使用 pk 列,则不会发生错误。

An update with WHERE clause which is not by unique column will cause deadlock if another transaction waits for the current transaction to complete. Here's a quick test:

CREATE TABLE test (pk int PRIMARY KEY, a int);
INSERT INTO test VALUES (0, 0);
INSERT INTO test VALUES (1, 0);

Session 1

BEGIN;
SELECT a FROM test WHERE pk=0 FOR UPDATE;

Session 2

BEGIN;
SELECT a FROM test WHERE pk=0 FOR UPDATE;

(Session 2 is now blocked)

Session 1

UPDATE test SET a=1 WHERE a>0;

In session 2 we receive an error

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

If in the WHERE clause of the update we use the pk column only, the error does not occur.

梦醒灬来后我 2024-12-17 03:35:10

我发现这种情况发生在以下一种或多种情况下:

  1. 在一个查询中多次加入同一个表 (SELF JOIN)
  2. 当使用包含以多种方式同时操作同一个表的查询的事务
  3. 时 当使用事务并使用与自连接或子查询相同的表

可能很难追踪,但情况基本上是说一个查询正在阻止另一个查询运行,这反过来又阻止第一个查询完成等...

http://en.wikipedia.org/wiki/Deadlock

I've seen this occur on one or more of the following conditions:

  1. Joining on the same table multiple times in a query (SELF JOIN)
  2. When using transactions that contain queries that manipulate the same table in multiple ways concurrently
  3. When using transactions and using the same table as a SELF JOIN or a Sub-query

It can be difficult to track down but the situation is basically saying one query is preventing another from running which in turn prevents the first from finishing etc...

http://en.wikipedia.org/wiki/Deadlock

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文