尽管阻塞会话为 0，但 SQL 查询正在阻塞另一个查询

Posted 2023-05-09

【中文标题】尽管阻塞会话为 0，但 SQL 查询正在阻塞另一个查询

【英文标题】：An SQL query is blocking another though the blocking session is 0

【发布时间】：2013-01-09 11:40:21

【问题描述】：

我从在同一个表上运行的两个应用程序登录并从两个程序执行两个操作，导致后台 SQL 查询运行。一项操作导致另一项操作卡住或运行非常缓慢。我发现这两个查询在一起很长时间了。

从表中选择 count(*) .... 插入表格......

另外，您能否告诉我如何在运行时显示查询获取的锁或查看哪些查询可能存在冲突？

【问题讨论】：

显示冲突锁是非常非常特定于 DBMS 的。您需要指定正在使用的 DBMS。 SELECT 点流中的信息可能与为什么需要这么长时间非常相关；据推测，有一个 WHERE 子句强制进行表扫描。 INSERT 语句的点流中的信息也可能是相关的；它可能不是单行的简单 VALUES 列表。还涉及其他因素；隔离级别可能是个问题。如果您使用的是 mysql，那么了解 InnoDB 和 MyISAM 可能也很重要。等等。

您还应该向我们展示您是如何发现“阻塞会话为 0”

另外：选择和插入不应阻塞彼此（至少在现代 DBMS 中不会）

应用程序正在使用 oracle 10g db。

我通过 select * from v$lock 看到了阻塞会话 0。能否请您告诉我如何查看实时获取的锁。

【参考方案1】：

我认为您没有任何锁定问题，因为 select 不会请求任何锁定。

您可能遇到的是，选择必须求助于前图像，即插入之前的值（假设插入和选择使用同一个表）。之前的图像存储在回滚段中，访问它们的成本有些高。

查询正在填充的表的行数仍然没有什么意义。结果会告诉你什么？一微秒后就会出错。这表明，你应该重新考虑这一切背后的逻辑。