SELECT FOR UPDATE查询中的死锁

Question

我有桌子说

TAB1

ID, TARGET, STATE, NEXT

列ID是主键。

查询显示死锁与此类似

SELECT * 
FROM TAB1 
WHERE NEXT = (SELECT MIN(NEXT) FROM TAB1 WHERE TARGET=? AND STATE=?) FOR UPDATE

我做了解释计划，我看到了这样的事情：

| Id  | Operation             | Name          | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT      |               |     1 |  8095 |     6   (0)| 00:00:01 |
|   1 |  FOR UPDATE           |               |       |       |            |          |
|   2 |   BUFFER SORT         |               |       |       |            |          |
|*  3 |    TABLE ACCESS FULL  | TAB1          |     1 |  8095 |     3   (0)| 00:00:01 |
|   4 |     SORT AGGREGATE    |               |     1 |  2083 |            |          |
|*  5 |      TABLE ACCESS FULL| TAB1          |     1 |  2083 |     3   (0)| 00:00:01 |

由于查询正在执行两次TABLE ACCESS FULL，所以我怀疑执行相同查询的2个会话将访问不同顺序的行。

列的索引是否有助于防止死锁？说在NEXT上创建一个索引???或者将PRIMARY更改为NON CLUSTERED KEY ??注意：通常，该表最多有1000行。

Answer 1

在NEXT列上添加非聚集索引确实可以提高性能并减少死锁问题。