Clickhouse杀死查询永远悬挂

Question

具有以下潜在的无限执行查询。为什么将其发行给Clickhouse服务器是没有意义的。查询已经启动并仍在运行：

SELECT Count("SN".*) FROM (SELECT sleepEachRow(3) FROM system.numbers) "SN"

好的，尝试查找关联的query_id或已经有一个。例如，query_id ='D02F4BDB-8928-4347-8641-4DA4B9C0F486'。让我们通过查询来杀死它：

KILL QUERY WHERE query_id = 'd02f4bdb-8928-4347-8641-4da4b9c0f486' 

从第一次看，实现的杀戮结果似乎还可以：

┌─kill_status─┬─query_id─────────────────────────────┬─user────┬─query────────────────────────────────────────────────────────────────────────┐
│ waiting     │ d02f4bdb-8928-4347-8641-4da4b9c0f486 │ default │ SELECT Count("SN".*) FROM (SELECT sleepEachRow(3) FROM system.numbers) "SN"; │
└─────────────┴──────────────────────────────────────┴─────────┴──────────────────────────────────────────────────────────────────────────────┘

好吧，让我们等待几秒钟，并确保原始查询已成功终止。让我们通过以下系统信息架构查询进行检查：

SELECT "query_id", "query", "is_cancelled" FROM system.processes WHERE query_id = 'd02f4bdb-8928-4347-8641-4da4b9c0f486';

不幸的是，原始查询仍在某种意义上运行。它变成了“ is_canceld”状态，但仍然悬挂：

┌─query_id─────────────────────────────┬─query────────────────────────────────────────────────────────────────────────┬─is_cancelled─┐
│ d02f4bdb-8928-4347-8641-4da4b9c0f486 │ SELECT Count("SN".*) FROM (SELECT sleepEachRow(3) FROM system.numbers) "SN"; │            1 │
└──────────────────────────────────────┴──────────────────────────────────────────────────────────────────────────────┴──────────────┘

等待一个小时和更多时间，并仍然取得一些结果。原始查询仍然挂在“ is_canceld”状态下。随后使用相同Query_id的杀戮查询没有任何作用。

最有可能重新启动服务器将有助于解决问题，但我不想这样做。如何在不重新启动服务器的情况下通过卡住查询解决问题？

Answer 1

在睡眠期间，Clickhouse查询无法杀死。

如果您使用的是最近的CH版本（21.12+），则将在处理每个块后检查杀戮标志（在较旧的版本上，可能永远不会检查它）。由于默认块为65536，因此查询将睡65536 * 3秒〜= 54小时，然后检查任何内容。

在将来的CH版本中，无法入睡超过3秒（现在是睡眠的限制，而不是SleepeachRow）。同时，您可以等待或重新启动服务器。