假设我的服务器收到 1000 个更新单个 MySQL 表的请求。在这种情况下不可避免地会出现死锁问题。我们已按照针对死锁的建议重新发布交易，但它们仍然会发生。

我们正在考虑提出以下替代解决方案。

1. 创建表 A、B、C。
2. 将到达服务器的更新表 D 的请求写入 A 或 B 或 C。
3. 分别在表 A、B 和 C 上创建一个 INSERT 触发器，这将依次将数据写入表 D，而不是直接将表 D 暴露给发送到服务器的 1000 个请求。

所以我们的问题是，当发生这种情况并且多行被写入表 A、B 和 C 时，表 A、B 和 C 上的基础触发器可能会同时触发以更新表 D。

MySQL InnoDB 引擎是否自动对这些触发器进行排队，还是我们必须在代码中处理这个问题？

非常感谢任何帮助。

现在所有这些请求直接更新的表 D 和发生死锁的地方如下所示。

v_user_email    varchar(60) NO  PRI     
v_device_IMEI   varchar(40) NO  PRI     
i_adid          int(11)         NO  PRI     
i_impressions   int(4)          YES 0   
dt_pulllogdttm  datetime    NO          
c_created_by    char(15)    NO          
dt_created_on   datetime    NO          
c_modified_by   char(15)    YES         
dt_modified_on  datetime    YES 

在此表中插入/更新行的 PHP 如下所示。您会看到，如果事务因死锁而失败，我们会尝试将事务发布 3 次，但即使如此，仍有事务失败，并且日志显示是由于死锁。

$updateQuery = "UPDATE tb_ad_pull_log SET i_impressions = (i_impressions + 1), dt_pulllogdttm = SYSDATE(), c_modified_by = '$createdBy', dt_modified_on = SYSDATE() WHERE v_user_email = '$email' AND i_adid = $adId";
        if(ExecuteDeadLockQuery($updateQuery, "UPDATE", __LINE__) == 0) // If there is no record for this ad for the user, insert a new record
        {
            $insertQuery = "INSERT INTO tb_ad_pull_log VALUES('$email', '$device_IMEI', $adId, 1, SYSDATE(), '$createdBy', SYSDATE(), NULL, NULL)";
            ExecuteDeadLockQuery($insertQuery, "INSERT", __LINE__);
        }    

ExecuteDeadLockQuery 函数如下所示 -

function ExecuteDeadLockQuery($query, $activity, $lineNumber)
    {
        global $errorLoggingPath;
        $maxAttempts = 3;
        $currentTry = 1;
        $noOfAffectedRows = -1;

        while($currentTry <= $maxAttempts)
        {
            $currentTry++;

            mysql_query($query);

            if( mysql_errno() <> 0 ) // If error occured
            {
                continue;
            }
            else
            {
                $noOfAffectedRows = mysql_affected_rows();
                break;
            }           
        }

        if($noOfAffectedRows == -1) // Query never executed successfully
        {
            LogError($activity . " failed in tb_ad_pull_log: " . mysql_error(), __FILE__, $lineNumber , $errorLoggingPath);
        }

        return $noOfAffectedRows;
    }

有没有更简洁的方法来避免这种僵局？这是我们拥有的一些日志。

ERROR:  08-21-2011 14:09:57  UPDATE failed in tb_ad_pull_log: Deadlock found when trying to get lock; try restarting transaction    LINE  83
ERROR:  08-21-2011 14:09:57  INSERT failed in tb_ad_pull_log: Deadlock found when trying to get lock; try restarting transaction    LINE  86
ERROR:  08-21-2011 14:09:57  INSERT failed in tb_ad_pull_log: Deadlock found when trying to get lock; try restarting transaction    LINE  86
ERROR:  08-21-2011 14:09:57  UPDATE failed in tb_ad_pull_log: Deadlock found when trying to get lock; try restarting transaction   LINE  83
ERROR:  08-21-2011 14:09:57  INSERT failed in tb_ad_pull_log: Deadlock found when trying to get lock; try restarting transaction    LINE  86
ERROR:  08-21-2011 14:09:57  UPDATE failed in tb_ad_pull_log: Deadlock found when trying to get lock; try restarting transaction    LINE  83
ERROR:  08-21-2011 14:09:59  UPDATE failed in tb_ad_pull_log: Deadlock found when trying to get lock; try restarting transaction    LINE  83
ERROR:  08-21-2011 14:09:59  UPDATE failed in tb_ad_pull_log: Deadlock found when trying to get lock; try restarting transaction    LINE  83
ERROR:  08-21-2011 14:10:01  UPDATE failed in tb_ad_pull_log: Deadlock found when trying to get lock; try restarting transaction    LINE  83
ERROR:  08-21-2011 14:10:01  INSERT failed in tb_ad_pull_log: Deadlock found when trying to get lock; try restarting transaction    LINE  86

第 83 行是 PHP 中的 UPDATE 语句，第 86 行是 INSERT。请记住，此数据可以每秒 5-8 个事务的速度写入此表。

附加信息

对于表 D 中的每个 INSERT 和 UPDATE，都会执行一个触发器来更新表 X 和表 Y。这是表 D 保持锁定的原因，因此传入请求会出现死锁吗？

终于找到了问题，但我不确定如何解决。 TABLE D 上的 AFTER INSERT 和 AFTER UPDATE 触发器在触发时锁定表，因此传入请求死锁。为什么我如此确定这一点是因为一旦我删除这些触发器，日志就会停止记录死锁消息，否则会记录

触发器代码片段。

    CREATE DEFINER=CURRENT_USER TRIGGER tuadmin.t_update_CPM_updateBalance
AFTER UPDATE
ON tb_ad_pull_log
FOR EACH ROW
BEGIN

    DECLARE `cpm_value` decimal(10,4);
    DECLARE `clientid` int(4);

    /* Execute the below block if the requested ad is not the default ad */
    IF NEW.i_adid <> 1 THEN

        SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
            //do updates to TABLE X and Y logic
END

我不明白为什么这些触发器会锁定表 D 并且不允许任何插入/更新同时发生。

如果我们放弃触发器并仅从 PHP 调用 SP 来完成工作，这是否可以避免所有问题？

最佳答案

好的，所以您使用的是一个表和几个触发器？

而且您每秒只有很少的事务？

你有奇怪的锁定问题吗？

使用 PostgreSQL，我很确定以下几点: a) 不会有那些问题 b) 如果有它们，您将立即获得社区支持

您的问题有 99.99% 的可能性是由 VERY_SLOW_TRIGGERS 引起的，我的意思是非常非常慢，因为每秒只有 8 次意味着事务运行时间为 125 毫秒，这非常大。

锁的原因很明显，你在表D上调用触发器。

-> call modification on table D
 -> before mod trigger
 -> modification
 -> after mod trigger
-> modification complete

即触发器中发生的所有事情都是表 D 上事务的一部分，因此将保持锁定直到它完成。

您可以:

a) 锁定更少的行

b) 锁定更少的时间 -> 插入另一个表，从那里处理异步

c) 使用正确支持触发器的 rdbms

平衡选项是 hammer-vs-fly 选项，对于如此低的 tps 计数，您没有理由需要一台以上的服务器。

但是，您应该对触发器的性能进行故障排除，并确认您没有在某处遇到 I/O 拥塞(通常速度过慢的往往还会过度使用宝贵的资源)。

好吧，这是另一种选择:

UNLOCK TABLES 显式释放当前 session 持有的任何表锁。

如果您的最后一个操作是更新/插入 并且如果您的触发器失败是不可能的或不是问题

然后您可以在触发器的开头使用它，释放所有锁并仅请求非锁定一致读取。

关于mysql - MySQL InnoDB 引擎是否自动对数据库触发器进行排队？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/7136469/