INSERT操作会导致死锁吗？

快乐的王一贴

假设：
我正在使用REPEATABLE_READ或SERIALIZABLE事务隔离(每次访问都会保留锁)
在访问多个表的同时，我们正在讨论多个线程。我有以下问题：
[ol]操作是否可能INSERT导致死锁？如果是这样，请提供一个详细的场景来演示如何发生死锁(例如，线程1会这样做，线程2会这样做，…，死锁）。
为所有其他操作获得加分(如SELECT，UPDATE，DELETE）回答同样的问题。[/ol]更新：3.超级奖励积分：在以下情况下如何避免僵局？
给定表：
权限[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删除公司如下：
在公司ID = 选择200家公司Permission_id -返回Permissions_id = 100
从ID删除200家公司；
从ID删除100权限；在上述示例中，INSERT锁定顺序为[权限，公司]，而DELETE锁定顺序是[公司，权限]。有没有办法解决这个例子的问题？REPEATABLE_READ或SERIALIZABLE隔离？

解决方案:
                                                            通常，所有的修改都可能导致死锁，但选择不会（稍后介绍）。
[ol]不，你不能忽视这些。
您可以根据数据库和设置忽略选择，但其他选择会给您带来僵局。[/ol]你甚至不需要多个表。
产生死锁的最佳方法是按不同的顺序执行相同的操作。
SQL Server示例：
create table A( PK int primary key)第一场：
begin transactioninsert into A values(1)第二场：
begin transaction insert into A values(7)第一场：
delete from A where PK=7第二场：
delete from A where PK=1你将陷入僵局。这证明了插入和删除可能会死锁。
更新类似：
第一场：
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僵局！
SELECT永远不要死锁，但它会在某些数据库上死锁，因为它使用的锁会干扰一致的读取。但这只是数据库引擎设计的一个糟糕方法。
如果您使用SNAPSHOT ISOLATION，则SQL
Server将不会锁定SELECT。Oracle＆我认为Postgres永远不会锁定SELECT(除非你有FOR
UPDATE，无论如何，它显然保留了更新)。
所以，基本上我觉得你有一些错误的假设。我想我已经证明了:
[ol]更新可能导致死锁
删除可能导致死锁
插入会导致死锁
你不需要多张桌子
您确实需要多次会议[/ol]你只需要相信SELECT;），但这取决于你的数据库和设置。

INSERT操作会导致死锁吗？

快乐的王一贴 LV1