当数据库死锁是由本来会分为两个分区的行引起时,分区是否可以防止数据库死锁?

发布于 2024-12-04 05:04:58 字数 282 浏览 1 评论 0原文

我正在努力解决根本不应该发生的死锁,因为我正在表的互斥子集上运行批量删除和插入。 然而,在多个线程上运行查询时(每个线程访问可能位于不同分区上的数据),死锁似乎是不可避免的。

另请参阅此问题了解更多信息有关该问题的详细信息,但我想知道更一般地说是否建议分区来处理死锁。

I am struggling with deadlocks that should not even be, as I am running bulk delete and inserts on mutually exclusive subsets of a table.
Yet deadlocks seem unavoidable when running the queries on multiple threads (each of which accessing data that could be on separate partitions).

See also this question for more details on the issue, but I am wondering more generally speaking if partitioning is recommended to deal with deadlocks.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

酒几许 2024-12-11 05:04:58

恕我直言,分区不会解决任何问题。死锁情况的事件链基本上是:

T1: get lock L1;
    get lock L2;

T2: get lock L2;
    get lock L1;

如果 T1 和 t2 都在中间,并且每个都拥有一个锁,则发生死锁。
如果 L1 和 L2 锁引用不同表中的对象,则不会发生任何变化;只是事件的顺序导致了死锁。

IMHO partioning would not solve anything. The chain of events for a deadlock situation is basically:

T1: get lock L1;
    get lock L2;

T2: get lock L2;
    get lock L1;

Deadlock occurs if T1 and t2 are both halfway, each owning one lock.
Nothing will change if the L1 and L2 locks refer to objects in different tables; it is only the ordering of events that causes the deadlock.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文