MySQL AWS 记录锁定超时未出现在慢查询日志中？

问：

更新于 11.09.2023

我们有一个庞大的数据库，其中包含大约 200,000 行代码，并带有托管在 AWS 上的只读副本。问题是我们偶尔会遇到我似乎无法追踪的死锁超时错误。此错误“呈现”为错误。我相信一个子过程导致了超时死锁，这就是为什么主过程丢失其保存点（旨在在发生错误时回滚到）的原因。显然，子过程的死锁超时会擦除保存点......SAVEPOINT does not exist

我们打开了慢速日志，日志中没有任何内容指示任何相关时间或其他任何内容的记录锁定。整个事情相当令人沮丧。

当然，这发生在我睡着的时候，所以我无法查询 or 表。然而，它是如此随机，当我们知道它正在发生时，我们几乎永远不会抓住它。data_locksdata_lock_waits

请注意，我们的后端系统确实会重用打开的连接，而不是在完成所有操作后关闭它们。我相信这个问题与连接的重用有关 - 但实际上这应该没问题，因为我们的系统旨在允许后端在任何时间使用任何连接进行“核心”过程调用。

下面是主数据库和等待的快照。我发现有趣的是，最大的等待是与 RR 同步的BIN_LOG。

可悲的是，除此之外，我们没有什么可继续的。如前所述，慢速日志没有任何可用内容;最高锁定时间值为：00：00：00.000035

在许多方面，这是没有意义的。我知道我们的查询锁定时间比这更长。也许问题是锁定的那些不慢？有我需要调整的设置吗？

任何关于追踪此事的建议将不胜感激。

所以我尝试了慢速日志方法，没有开玩笑;我的锁定时间都没有超过 0.046564。即使慢日志设置为 0...是的，确实发生了超时......所以我正在尝试一种不同的技术;一个事件监控系统，可以监视sys.innodb_lock_waits，当有记录时，我会存储数据以供查看。我们今天正在测试它。我会让大家知道它是怎么回事。

死锁错误再次发生，但我的事件监视器每 5 秒运行一次以检查锁定等待，但未返回任何内容，这告诉我死锁立即返回而不是“超时”。这可能吗？我以为所有的僵局都会超时......

SQL 代码为：

SELECT
    JSON_ARRAYAGG(JSON_OBJECT
    (
      'waiting_trx_id',waiting_trx_id,
      'waiting_pid',waiting_pid,
      'waiting_query',waiting_query,
      'blocking_trx_id', blocking_trx_id,
      'blocking_pid', blocking_pid,
      'blocking_query', blocking_query
    ))
INTO
    json_results
FROM 
    sys.innodb_lock_waits;