INSERT操作会导致死锁吗？
假设：我正在使用REPEATABLE_READ或SERIALIZABLE事务隔离(每次访问都会保留锁)
在访问多个表的同时，我们正在讨论多个线程。我有以下问题：
操作是否可能INSERT导致死锁？如果是这样，请提供一个详细的场景来演示如何发生死锁(例如，线程1会这样做，线程2会这样做，…，死锁）。
为所有其他操作获得加分(如SELECT，UPDATE，DELETE）回答同样的问题。更新 ：3.超级奖励积分：在以下情况下如何避免僵局？
给定表：
权限
的公司我创办了一家新公司，如下所示：
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隔离？
解决方案:
通常，所有的修改都可能导致死锁，但选择不会（稍后介绍）。
不，你不能忽视这些。
您可以根据数据库和设置忽略选择，但其他选择会给您带来僵局。你甚至不需要多个表。
产生死锁的最佳方法是按不同的顺序执行相同的操作。
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，无论如何，它显然保留了更新)。
所以，基本上我觉得你有一些错误的假设。我想我已经证明了:
更新可能导致死锁
删除可能导致死锁
插入会导致死锁
你不需要多张桌子
您 确实 需要多次会议你只需要相信SELECT;），但这取决于你的数据库和设置。
页:
[1]