MySQL 死锁与复合主键和触发自动增量答案

【问题标题】：MySQL deadlocks with composite primary key and trigger autoincrementMySQL 死锁与复合主键和触发自动增量
【发布时间】：2019-07-15 22:17:43
【问题描述】：

我有独立的服务器和 2000 个在线用户（不是很多）。 MySQL DB 5.6 与表 request_action（没有自动增量但增量的复合 PK 在触发器中，您可以在下面看到它）：

  CREATE TABLE `request_action` (
  `ra_id` bigint(20) NOT NULL,
  `cl_id` int(11) NOT NULL DEFAULT '0',
  `ra_r_id` bigint(20) NOT NULL,
  `ra_tr_id` bigint(20) DEFAULT '0',
  `ra_ss_id` bigint(20) NOT NULL DEFAULT '0',
  `ra_h_id` int(11) NOT NULL DEFAULT '0',
  `ra_uch_id` bigint(20) DEFAULT '0',
  `ra_u_id` int(11) DEFAULT '0',
  `ra_datetime` datetime NOT NULL,
  `ra_uct_id` int(11) NOT NULL DEFAULT '0',
  `ra_text` longtext NOT NULL,
  `ra_datetime_reply` datetime NOT NULL,
  `ra_reply` longtext NOT NULL,
  `ra_line_breaks` tinyint(4) NOT NULL DEFAULT '0',
  `ra_plan` tinyint(4) NOT NULL DEFAULT '0',
  `ra_shw` tinyint(4) NOT NULL DEFAULT '1',
  `ra_to_u_id` int(11) DEFAULT '0',
  `ra_created_at` datetime DEFAULT NULL,
  `ra_seen` tinyint(4) NOT NULL DEFAULT '0',
  `ra_seen_u_id` bigint(20) NOT NULL DEFAULT '0',
  PRIMARY KEY (`cl_id`,`ra_id`),
  KEY `rm_r_id` (`ra_r_id`),
  KEY `ra_u_id` (`ra_u_id`),
  KEY `ra_plan` (`ra_plan`),
  KEY `ra_rat_id` (`ra_ss_id`),
  KEY `ra_h_id` (`ra_h_id`),
  KEY `ra_tr_id` (`ra_tr_id`),
  KEY `ra_id` (`ra_id`),
  KEY `ra_datetime` (`ra_datetime`,`ra_seen`),
  KEY `ra_shw` (`ra_shw`,`ra_seen`,`ra_to_u_id`),
  KEY `ra_r_id` (`ra_r_id`,`ra_tr_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

在此表上触发（插入前）：

if (cast(NEW.ra_id as UNSIGNED) = 0) then
SET NEW.ra_id = (SELECT COALESCE(MAX(ra_id)+1, 1) FROM request_action WHERE cl_id = NEW.cl_id);
end if

而且我一天中有很多次死锁（（例如，一天有 100 次。

LATEST DETECTED DEADLOCK
------------------------
2019-02-21 21:09:34 7f5e11f3b700
*** (1) TRANSACTION:
TRANSACTION 2947112777, ACTIVE 0 sec inserting
mysql tables in use 11, locked 11
LOCK WAIT 5 lock struct(s), heap size 1184, 3 row lock(s)
MySQL thread id 19952598, OS thread handle 0x7f5e10e38700, query id 248552715 192.168.0.7 vh_uon_com_ru
insert into request_action (
                    ra_r_id,
                    ra_u_id,
                    ra_datetime,
                    ra_text,
                    ra_datetime_reply,
                    ra_reply,
                    ra_plan,
                    cl_id,
                    ra_tr_id,
                    ra_ss_id,
                    ra_h_id,
                    ra_uch_id,
                    ra_to_u_id,
                    ra_uct_id,
                    ra_shw
                ) values (
                    40053,
                    906,
                    '2019-02-21 21:09:34',
                    'Звонок',
                    '2019-02-21 21:09:34',
                    '',
                    '0',
                    698,
                    0,
                    0,
                    0,
                    171114,
                    0,

*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 2320 page no 546708 n bits 104 index `PRIMARY` of table `request_action` trx id 2947112777 lock_mode X locks gap before rec insert intention waiting
*** (2) TRANSACTION:
TRANSACTION 2947112774, ACTIVE 0 sec inserting
mysql tables in use 11, locked 11
5 lock struct(s), heap size 1184, 3 row lock(s)
MySQL thread id 19952597, OS thread handle 0x7f5e11f3b700, query id 248552705 192.168.0.7
insert into request_action (
                    ra_r_id,
                    ra_u_id,
                    ra_datetime,
                    ra_text,
                    ra_datetime_reply,
                    ra_reply,
                    ra_plan,
                    cl_id,
                    ra_tr_id,
                    ra_ss_id,
                    ra_h_id,
                    ra_uch_id,
                    ra_to_u_id,
                    ra_uct_id,
                    ra_shw
                ) values (
                    25182,
                    906,
                    '2019-02-21 21:09:34',
                    'Звонок',
                    '2019-02-21 21:09:34',
                    '',
                    '0',
                    698,
                    0,
                    0,
                    0,
                    171113,
                    0,

*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 2320 page no 546708 n bits 104 index `PRIMARY` of table `request_action` trx id 2947112774 lock mode S locks gap before rec
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 2320 page no 546708 n bits 104 index `PRIMARY` of table `request_action` trx id 2947112774 lock_mode X locks gap before rec insert intention waiting
*** WE ROLL BACK TRANSACTION (2)

在 my.cf 中，我们有以下选项：

max_connections = 10000
key_buffer_size = 1024M
join_buffer_size = 256M
read_buffer_size = 256M
sort_buffer_size = 256M
tmp_table_size = 512M
read_rnd_buffer_size = 8M
max_heap_table_size = 512M

thread_cache_size = 8192
query_cache_type = 1

query_cache_size = 15G
wait_timeout = 6000
connect_timeout = 15
interactive_timeout = 60
max_allowed_packet = 512M
bulk_insert_buffer_size = 64M

innodb_log_file_size                    = 512M
innodb_log_buffer_size                  = 2G
innodb_buffer_pool_size                 = 20G

您能帮我解决死锁问题吗？我该如何解决？我应该在死锁中重新运行查询吗？

【问题讨论】：

标签： mysql triggers deadlock auto-increment composite-primary-key

【解决方案1】：

TL;DR -- 当您尝试为每个不同的 cl_id 生成一个新的递增 id 时，您不能进行并发插入。您必须使用表锁来执行此操作，从而导致并发插入串行运行。

AUTO_INCREMENT 绕过这个死锁的原因是它获取了一个简短的表锁来生成下一个 id。从技术上讲，这会导致所有执行 INSERT 的并发会话串行执行。幸运的是，表锁非常简短。默认情况下，它会在 id 生成后立即释放。你可以在这里阅读更多：https://dev.mysql.com/doc/refman/8.0/en/innodb-auto-increment-handling.html

而您生成 id 的方法会导致死锁，因为它使用了两个锁定操作：

一个用于创建行的 X 锁。
一个用于读取表的 S 锁。当您作为 INSERT/UPDATE/DELETE 的一部分读取表时，您会在所读取的行上创建一个共享锁。

但是锁不是一起获取的，两个步骤之间有一个短暂的时间，这就是竞争条件发生的地方。我们可以用两张表来证明这一点：

mysql> create table foo ( id serial primary key);
mysql> insert into foo (id) values (1);

mysql> create table bar ( id serial primary key);

mysql> create trigger b before insert on bar 
       for each row set new.id=(select max(id) from foo);

现在我们在bar 上有一个触发器，它将读取foo 中的某些行以获取最大值（id）。

mysql> begin;
mysql> insert into bar () values ();

这应该使用从foo 读取的值在bar 中创建一个新行。但交易仍然开放。

在第二个窗口中，执行以下操作：

mysql> update foo set id = 2;
...

这挂起，等待其在foo 上的 X 锁定。它无法更新foo，因为它上面已经有一个 S 锁，由会话在第一个窗口中放置。

回到第一个窗口并运行：

mysql> update foo set id = 3;
Query OK, 1 row affected (0.01 sec)
Rows matched: 1  Changed: 1  Warnings: 0

这会创建一个循环锁定等待，这就是死锁。两个事务都在等待另一个事务持有的锁。我们在第二个窗口中看到，该事务已被终止：

mysql> update foo set id = 2;
...
ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction

“我该如何解决？我应该在死锁中重新运行查询吗？”

一种解决方法是强制并发会话连续运行，方法是在您尝试插入之前获取 INSERT 或触发器引用的所有表上的表锁。

mysql> begin;
mysql> lock tables foo write, bar write;
mysql> insert into bar () values ();

第二个窗口挂起，但这次它挂在表锁上，而不是行锁上。

mysql> update foo set id = 2;
...

在第一个窗口中，完成交易。解锁表锁会隐式提交事务。

mysql> unlock tables;

第二个窗口停止等待，并成功完成更新。

mysql> update foo set id = 2;
...
Query OK, 1 row affected (3.50 sec)
Rows matched: 1  Changed: 1  Warnings: 0

请注意，它已经等待了 3.5 秒，这是我返回第一个窗口并提交事务所用的时间。

连续插入会话会限制应用的吞吐量，因为会话正在排队。但它避免了死锁。

【讨论】：

我可以在触发器中添加“锁定表”吗？还是仅在我的代码中插入查询之前？！
您应该在代码中插入查询之前执行此操作。如果你在触发器中这样做，我认为避免竞争条件为时已晚。
触发器中的这个结构怎么样 - “select max() .. for update”并在此之后释放锁？
我认为你也做不到。释放锁会隐式提交事务，但您不能从触发器启动或提交事务。
如果您在同一个脚本中进行 5 次插入，它们应该可以工作。在一个会话中锁定表后，您可以在同一个会话中写入表而不会遇到麻烦。 other 会话必须等到您的会话释放其锁定。