问MySQL 8.0 trx_sys_mutex等待时间峰值

EN

SELECT查询不需要任何行锁，除非您使用事务隔离级别SERIALIZABLE。所以它只能是一个元数据锁。每个查询都需要一个元数据锁，这可以被持有该元数据锁的任何其他会话阻塞。例如，任何ALTER/DROP/TRUNCATE/RENAME TABLE语句或LOCK TABLES。

我还看到Query_time是6分钟(359.87秒)，其中超过2分钟是在锁等待完成之后。

我假设user.user_id是那个表的主键？因此，它通过主键查找单行，并花费了几分钟的时间？要花这么长时间，这是不可能的。

根据我的经验，只有当主机变得没有响应时，才会发生这种情况。它与您的SQL查询无关。

我会考虑其他的可能性：

• 嘈杂的邻居问题。也就是说，同一主机上的另一个RDS容器做了一些导致系统负载达到峰值的事情。不幸的是，亚马逊网络服务与属于不同账户的容器共享主机，所以这种事情可能会发生，你永远不知道谁应该对此负责。

• 主机上发生了一些事情，与任何RDS容器无关。可能是操作系统升级或故障转移等。同样，这将超出您的控制范围，您将无法进行检查。

您是否可以再次运行相同的查询，在相同的RDS实例上搜索相同的表以查找相同的值，并且只需要很少的时间？这将指向主机上的临时问题，而不是您的查询的问题。

正如我所说的，任何查询都需要一个元数据锁。必须获取这个锁，这意味着需要非零量的代码来检查元数据锁是否存在，从而阻止您的查询。通常这是如此之快，以至于你永远不会注意到它，但是如果主机超载到正常操作需要几分钟，甚至这种元数据锁定的快速检查也可能延伸。