针对你的问题，我来详细解答：

1. 内存不足直接报错确实是ClickHouse的默认设计 #

ClickHouse从设计之初就高度优先性能，内存操作的速度比磁盘IO快几个数量级，所以它默认会尽可能用内存来处理查询。当查询所需内存超过限制时直接抛出错误，而不是自动降级到磁盘，这是官方的有意选择——避免因为磁盘IO的引入导致查询性能骤降，同时也促使用户优化查询逻辑、调整内存配置或者利用ClickHouse的分区/索引特性来减少扫描的数据量。

你的报错就是这种设计的典型体现：

SQL Error [241]: ClickHouse exception, code: 241, host: XXXXXX, port: 8123; Code: 241, e.displayText() = DB::Exception: Memory limit (for query) exceeded: would use 9.32 GiB (attempt to allocate chunk of 9440624 bytes), maximum: 9.31 GiB (version 21.4.6.55 (official build))

它明确告诉你当前查询需要的内存已经超过了设定的上限。

2. 存在设置让ClickHouse转用磁盘处理 #

虽然默认不启用，但ClickHouse提供了专门的参数来开启外部处理（即把中间数据写入磁盘），主要针对聚合、排序这类容易占用大量内存的操作，以下是关键设置：

针对聚合类查询（比如你的MAX(id)） #

max_bytes_before_external_group_by：当聚合操作（包括MAX、MIN、SUM等）的中间数据占用内存超过这个阈值时，ClickHouse会将部分中间数据写入临时磁盘文件，避免内存溢出。

• 默认值是0（禁用外部聚合），你可以设置一个合理的值，比如2GB：

  SET max_bytes_before_external_group_by = 2147483648; -- 2GB
  

• 如果你希望全局生效，可以在ClickHouse的配置文件（比如config.xml）中添加：

  <max_bytes_before_external_group_by>2147483648</max_bytes_before_external_group_by>
  

针对排序类查询（比如用ORDER BY id DESC LIMIT 1替代MAX(id)） #

max_bytes_before_external_sort：当排序操作需要的内存超过这个阈值时，会启用外部排序，将数据分批写入磁盘再合并结果。

• 设置方式类似：

  SET max_bytes_before_external_sort = 2147483648;
  

• 全局配置同样在config.xml中添加对应节点。

配套设置：临时文件存储路径 #

确保tmp_path参数指向一个有足够剩余空间的磁盘路径，默认是/tmp，如果空间不足可以修改：

<tmp_path>/data/clickhouse/tmp</tmp_path>

3. 针对你的场景的额外建议 #

你的表是MergeTree引擎且id不是排序键，查询MAX(id)需要扫描全表数据。除了开启外部聚合，你还可以考虑：

• 给id字段添加二级索引（比如INDEX idx_id id TYPE minmax GRANULARITY 8192），这样ClickHouse可以利用索引快速获取最大值，无需扫描全表。
• 如果表有分区，可以按分区分别查询MAX(id)再聚合，减少单批次处理的数据量。

需要注意的是，启用外部处理后，查询性能会明显下降（因为磁盘IO远慢于内存），所以这只是内存不足时的临时解决方案，长期来看优化查询和数据模型才是更优的选择。

内容的提问来源于stack exchange，提问作者Thomas Miller