INSERT操作会导致死锁吗？

快乐的王一贴

假设：
) D6 Z9 |% G2 ^/ e- b我正在使用REPEATABLE_READ或SERIALIZABLE事务隔离(每次访问都会保留锁)
在访问多个表的同时，我们正在讨论多个线程。我有以下问题：
8 t1 \7 E; V6 P6 T* L- v' }& @[ol]操作是否可能INSERT导致死锁？如果是这样，请提供一个详细的场景来演示如何发生死锁(例如，线程1会这样做，线程2会这样做，…，死锁）。
1 ?7 Z9 z) b2 q/ r为所有其他操作获得加分(如SELECT，UPDATE，DELETE）回答同样的问题。[/ol]更新    ：3.超级奖励积分：在以下情况下如何避免僵局？
$ a$ k$ n. c; M3 x( n给定表：
权限[id BIGINT PRIMARY KEY]
的公司[id BIGINT PRIMARY KEY,name VARCHAR(30),permission_id BIGINT NOT NULL,FOREIGN KEY (permission_id) REFERENCES permissions(id))我创办了一家新公司，如下所示：
INSERT INTO权限；-插入Permissions.id = 100
INSERT INTO公司(名称，permission_id）VALUES（“ Nintendo”，100）；-插入companies.id = 200删除公司如下：
  {7 w; d& U# l在公司ID = 选择200家公司Permission_id -返回Permissions_id = 100
从ID删除200家公司；
7 d! d7 W: n6 x. o  Z: D! m4 _: Z从ID删除100权限；在上述示例中，INSERT锁定顺序为[权限，公司]，而DELETE锁定顺序是[公司，权限]。有没有办法解决这个例子的问题？REPEATABLE_READ或SERIALIZABLE隔离？
1 x+ H5 r+ ]: }* M) O* c6 a7 a7 R                                                               
& ]' `% {3 x8 L; N2 h9 I8 X6 R    解决方案:                                                               
                                                                通常，所有的修改都可能导致死锁，但选择不会（稍后介绍）。
2 W+ a+ r! S5 g# n3 I9 g8 a* Y( ], I[ol]不，你不能忽视这些。
您可以根据数据库和设置忽略选择，但其他选择会给您带来僵局。[/ol]你甚至不需要多个表。
产生死锁的最佳方法是按不同的顺序执行相同的操作。
SQL Server示例：
, D6 Q5 _/ z' dcreate table A(    PK int primary key)第一场：
begin transactioninsert into A values(1)第二场：
. {0 g6 m" I7 ]  b% t0 K3 jbegin transaction    insert into A values(7)第一场：
delete from A where PK=7第二场：
delete from A where PK=1你将陷入僵局。这证明了插入和删除可能会死锁。
  d$ J9 u& H3 W' m  u* Y更新类似：
1 v, W  V; k4 W( d; z第一场：
begin transaction    insert into A values(1)insert into A values(2)commitbegin transactionupdate A set PK=7 where PK=1第二场：
begin transactionupdate A set pk=9 where pk=2    update A set pk=8 where pk=1第一场：
update A set pk=9 where pk=2僵局！
$ F: p1 ^6 A# u/ I9 LSELECT永远不要死锁，但它会在某些数据库上死锁，因为它使用的锁会干扰一致的读取。但这只是数据库引擎设计的一个糟糕方法。
如果您使用SNAPSHOT ISOLATION，则SQL
) j* D* E1 G! QServer将不会锁定SELECT。Oracle＆我认为Postgres永远不会锁定SELECT(除非你有FOR
UPDATE，无论如何，它显然保留了更新)。
所以，基本上我觉得你有一些错误的假设。我想我已经证明了:
[ol]更新可能导致死锁
删除可能导致死锁
插入会导致死锁
你不需要多张桌子
您 确实    需要多次会议[/ol]你只需要相信SELECT;），但这取决于你的数据库和设置。