我有独立的服务器和2000个用户在线（不是很多）。MySQL db 5.6带有table 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)
在我的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
您能帮我解决僵局问题吗？我该如何修复？我应该在僵局中重新查询吗？
tl; dr-当您试图每个不同的cl_id生成新的增量ID时，您无法执行并发插入。您必须使用桌锁进行此操作，从而导致并发插入串行运行。
AUTO_INCREMENT绕过此僵局的原因是，它获得了一个简短的表锁来生成下一个ID。从技术上讲，这会导致所有并发会话执行插入以串行执行。幸运的是，桌锁非常简短。默认情况下，它在生成ID后立即发布。您可以在此处阅读更多信息：https：//dev.mysql.com/doc/refman/8.0/en/innodb-auto-increment handling.html
虽然您的生成ID的方法正在造成僵局，因为它使用了两个锁定操作：
- 一个用于创建行的X锁。
- 一个用于阅读桌子的S锁。当您阅读表作为插入/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-Lock。它无法更新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
"我该如何修复它？我应该在死锁中重新查询吗？"
一个解决方法是通过在尝试插入之前在插入或触发器引用的所有表上获取表锁来迫使并发会话串行。
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秒，这就是我回到第一个窗口并进行交易的时间。
使会话插入串行限制应用程序的吞吐量，因为会话正在排队。但这避免了死锁。