标签: database-deadlocks

我添加了一个触发器后,我遇到了僵局.有一个UserBalanceHistory表,每个事务和一Amount列有一行.添加了一个触发器来对Amount列进行求和,并将结果放在相关的User表Balance列中.

CREATE TABLE [User]
(
    ID INT IDENTITY,
    Balance MONEY,
    CONSTRAINT PK_User PRIMARY KEY (ID)
);

CREATE TABLE UserBalanceHistory
(
    ID INT IDENTITY,
    UserID INT NOT NULL,
    Amount MONEY NOT NULL,
    CONSTRAINT PK_UserBalanceHistory PRIMARY KEY (ID),
    CONSTRAINT FK_UserBalanceHistory_User FOREIGN KEY (UserID) REFERENCES [User] (ID)
);

CREATE NONCLUSTERED INDEX IX_UserBalanceHistory_1 ON UserBalanceHistory (UserID) INCLUDE (Amount);

CREATE TRIGGER TR_UserBalanceHistory_1 ON UserBalanceHistory AFTER INSERT, UPDATE, DELETE AS
BEGIN
    DECLARE @UserID INT;

    SELECT TOP …

我看到MySQL 5.6的死锁,因为似乎试图锁定同一行/两次.

从下面的代码段中,id =(11,12,13,14,15)的行已经锁定.当另一个事务试图获取对这些的锁定时,MySQL无法检测到死锁的事务.

我的阅读是否正确？如果是这样,MySQL 5.6中有什么可以克服这个问题吗？FWIW,5.5中的相同代码工作得很好(几百次迭代).

------------------------
LATEST DETECTED DEADLOCK
------------------------
2013-07-25 11:46:05 13a515000
*** (1) TRANSACTION:
TRANSACTION 2333130, ACTIVE 0 sec fetching rows
mysql tables in use 1, locked 1
LOCK WAIT 31 lock struct(s), heap size 6960, 6 row lock(s)
MySQL thread id 2944, OS thread handle 0x13ae88000, query id 184533 localhost 127.0.0.1 root Sending data
SELECT id FROM table_meta WHERE id IN (11, 12, 13, 14, 15) FOR UPDATE
*** (1) WAITING FOR THIS LOCK TO BE …

我在PostgreSQL 9.1服务器上有一个表,如下所示:

CREATE TABLE foo(id integer PRIMARY KEY);

在一个带psycopg2(≥2.4.2)的交互式Python shell中,我可能会启动一个连接和游标,并查询该表:

import psycopg2
conn = psycopg2.connect('dbname=...')
curs = conn.cursor()
curs.execute('SELECT * FROM foo;')
curs.fetchall()

但是,如果我然后尝试修改表:

ALTER TABLE foo ADD COLUMN bar integer;

这会引发虚拟死锁,直到我conn.close()从Python开始.

如何启动与psycopg2的简单连接,以防止它在其他地方创建由DDL更改引起的死锁？Python中的连接可以是只读的.

我有一个C#项目,它将数据写入TSQL数据库.在循环中运行有两个更新语句,例如:

 for (int i = 0; i < customersProducts.Count; i++) {
     CustomerProducts c = customersProducts[i];

     // Update product dimensions
     for (int j = 0; j < c.Count; j++) {
         Product p = c[j];
         updateProductDimensions(p);
     }

     // ... some processing

     // Update product
     for (int j = 0; j < c.Count; j++) {
         Product p = c[j];
         updateProduct(p);
     }
 }

在updateProductDimensions()与updateProduct()两个触发SQL Update语句.更新的列中存在一些重叠:

string updateProductDimensions = "UPDATE products SET width = @width, height = @height, length = @length …

假设some_table有两行,主键1和2.以下语句序列可能导致死锁:

session 1: begin;
session 2: begin;
session 1: DELETE FROM my_table WHERE my_key = 1;
session 2: DELETE FROM my_table WHERE my_key = 2;
session 1: DELETE FROM my_table WHERE my_key = 2;
session 2: DELETE FROM my_table WHERE my_key = 1;

如果两个会话以相同的顺序删除,则不会发生死锁.

现在,回答我的问题,如果DELETE语句触及多行会发生什么？例如:

session 1: begin;
session 2: begin;
session 1: DELETE FROM my_table;
session 2: DELETE FROM my_table;

是否有可能两个并发但相同的DELETE语句将以不同的顺序删除行？是否可以强制执行删除顺序以避免死锁？

我在文档中找不到这些信息,所以我想说不能保证删除顺序(尽管它可能间接地作为实现细节).我想在这里仔细检查一下.

好吧，我完全迷失在死锁问题上。我只是不知道如何解决这个问题。

我有这三个表（我删除了不重要的列）：

CREATE TABLE [dbo].[ManageServicesRequest]\n(\n    [ReferenceTransactionId]    INT                 NOT NULL,\n    [OrderDate]                 DATETIMEOFFSET(7)   NOT NULL,\n    [QueuePriority]             INT                 NOT NULL,\n    [Queued]                    DATETIMEOFFSET(7)   NULL,\n    CONSTRAINT [PK_ManageServicesRequest] PRIMARY KEY CLUSTERED ([ReferenceTransactionId]),\n)\n\nCREATE TABLE [dbo].[ServiceChange]\n(\n    [ReferenceTransactionId]    INT                 NOT NULL,\n    [ServiceId]                 VARCHAR(50)         NOT NULL,\n    [ServiceStatus]             CHAR(1)             NOT NULL,\n    [ValidFrom]                 DATETIMEOFFSET(7)   NOT NULL,\n    CONSTRAINT [PK_ServiceChange] PRIMARY KEY CLUSTERED ([ReferenceTransactionId],[ServiceId]),\n    CONSTRAINT [FK_ServiceChange_ManageServiceRequest] FOREIGN KEY ([ReferenceTransactionId]) REFERENCES [ManageServicesRequest]([ReferenceTransactionId]) ON DELETE CASCADE,\n    INDEX [IDX_ServiceChange_ManageServiceRequestId] ([ReferenceTransactionId]),\n    INDEX [IDX_ServiceChange_ServiceId] ([ServiceId])\n)\n\nCREATE TABLE [dbo].[ServiceChangeParameter]\n(\n    [ReferenceTransactionId]    INT                 NOT NULL,\n    [ServiceId]                 VARCHAR(50)         NOT NULL,\n    [ParamCode]                 VARCHAR(50) …

更新:以下潜在解决方案

我有一大堆配置文件,包括我想要推送到数据库中的键/值对.在配置文件中重复了很多键和值,因此我使用3个表存储数据.一个用于所有唯一键值,一个用于所有唯一对值,另一个列出每个文件的所有键/值对.

问题: 我正在使用多个并发进程(以及连接)将原始数据添加到数据库中.不幸的是,在尝试向键和值表添加值时,我遇到了很多检测到的死锁.我尝试了几种不同的插入数据的方法(如下所示),但最终总是出现"检测到死锁"错误

TransactionRollbackError:检测到死锁
详细信息:进程26755在事务689456上等待ShareLock; 由进程26754阻止.进程26754在事务689467上等待ShareLock; 被进程26755阻止.

我想知道是否有人可以对可能导致这些死锁的确切原因有所了解,并可能指出我采取某种方法解决问题.看看我正在使用的SQL语句(下面列出),我真的不明白为什么会有任何共同依赖.

谢谢阅读!

示例配置文件:

example_key this_is_the_value
other_example other_value
third example yet_another_value

表定义:

    CREATE TABLE keys (
        id SERIAL PRIMARY KEY,
        hash UUID UNIQUE NOT NULL,
        key TEXT);

    CREATE TABLE values (
        id SERIAL PRIMARY KEY,
        hash UUID UNIQUE NOT NULL,
        key TEXT);

    CREATE TABLE keyvalue_pairs (
        id SERIAL PRIMARY KEY,
        file_id INTEGER REFERENCES filenames,
        key_id INTEGER REFERENCES keys,
        value_id INTEGER REFERENCES values);

SQL语句:

最初我试图使用此语句来避免任何异常:

    WITH s AS (
        SELECT id, hash, key FROM …

大交易的设计..

START TRANSACTION;
    /*
        INERT for login detail
    */
    /*
        INSERT for personal information
    */
    /*
        INSERT for user's transaction account
    */
COMMIT; 

和小交易的设计..

START TRANSACTION;
    /*
        INSERT for login detail
    */
COMMIT;

START TRANSACTION;
    /*
        INSERT for personal information
    */
COMMIT;

START TRANSACTION;
    /*
        INSERT for user's transaction account
    */
COMMIT;  

目前的结果

• 我在我们的应用程序中尝试了两种方法,并且通过使用'Big'事务,我们在某个表中遇到了死锁.

• 通过使用小型交易,三个中的一个或两个可能无法运行并导致差异.

我在处理此类案例方面的经验不足以在这种情况下提供最佳解决方案.这里可以做出什么样的解决方案？

我们有一个应用程序，它从数据流中读取并将该信息插入到数据库中。数据是发生在 Google Drive 上的变化，这意味着影响相同对象的许多事件可能彼此非常接近。

将此信息更新到数据库中时，我们遇到了死锁，这是日志中出现的内容。我已经重构并清理了查询以提高可读性：

ERROR:  deadlock detected
DETAIL:  Process 10586 waits for ShareLock on transaction 166892743; blocked by process 10597.
  Process 10597 waits for ShareLock on transaction 166892741; blocked by process 10586.
  Process 10586: 
          INSERT INTO documents
              (version, source, source_id, ingestion_date)
          VALUES
              (0, 'googledrive', 'alpha', '2017-09-21T07:03:51.074Z'),
              (0, 'googledrive', 'beta', '2017-09-21T07:03:51.074Z')
              (0, 'googledrive', 'gamma', '2017-09-21T07:03:51.074Z'),
              (0, 'googledrive', 'delta', '2017-09-21T07:03:51.074Z'),
              (0, 'googledrive', 'epsilon', '2017-09-21T07:03:51.074Z'),
              (0, 'googledrive', 'zeta', '2017-09-21T07:03:51.074Z')

          ON CONFLICT (source, source_id)
          DO UPDATE
          SET
              ingestion_date = EXCLUDED.ingestion_date,
              version = documents.version …

I'm getting deadlocks in my MySQL InnoDB tables. InnoDB log pinpoints two queries that resulted in deadlock (it's two exact same queries, both parts of exact same transactions, resulting from almost-simultaneous duplicate requests to API). But I can't understand what is the problem - query just updates some fields in a row, why should it deadlock?

Here's example of the query:

update `some_table` set `some_field` = 123 where `some_table`.`id` = 530;

Below I pasted the deadlock log from InnoDB show …