尧图网页设计 
ClickHouse v25.10.7.6-stable 变更解读INSERT 并发控制修复与 distroless 镜像安全升级【免费下载链接】ClickHouseClickHouse® is a real-time analytics database management system项目地址: https://gitcode.com/GitHub_Trending/cli/ClickHouseClickHouse v25.10.7.6-stable 是 25.10 系列的一个维护性稳定版本核心工作集中在两件事修复普通INSERT不经过物化视图在并发控制ConcurrencyControl槽位分配上的过度请求问题以及把 distroless Docker 基础镜像从 Debian 12 升级到 Debian 13 以消除系统库中的 CVE 漏洞。本文基于本仓库的 v25.10.7.6-stable changelog结合src/与docker/下的源码实现逐条解析这些变更的根因、修复方式与运维影响帮助你判断是否升级、以及升级后如何验证。版本背景25.10 系列的维护节奏v25.10.7.6-stable 的完整版本号是v25.10.7.6-stable (16b240cb400)对比基线是上一个稳定版v25.10.6.36-stable (853dbd2ee0c)。从 changelogs 目录 的序列可以看到25.10 系列采用功能版本 高频补丁版本的节奏版本说明v25.10.1.3832-stable25.10 系列首个 stablev25.10.2.65-stable / v25.10.3.100-stable / v25.10.4.104-stable中间补丁版本v25.10.5.40-stable上一补丁版本v25.10.6.36-stable上一补丁版本v25.10.7.6-stable本文版本修复 INSERT 并发槽位过度占用与 v25.10.6.36-stable changelog 相比本版本变更面收窄、目标明确1 个用户可见行为修复 2 个构建/测试/打包改进 1 个解析器兼容性增强属于典型的小步快跑维护版本。Bug Fix普通 INSERT 不再过度占用 ConcurrencyControl 槽位变更内容本版本最重要的修复是见 changelog 第 11 行Plain INSERTs without materialized views no longer request excessive ConcurrencyControl slots and threads (max_threadsinstead ofmax_insert_threads), preventing CC slot starvation and thread count blowup on clusters with high INSERT throughput.对应上游 PR 为 #102961Sema Checherinda回传自 issue #103748。翻译成可操作的语义没有物化视图的普通 INSERT此前会按max_threads而不是max_insert_threads去申请并发控制槽位与线程数导致在高 INSERT 吞吐的集群上出现两类连锁问题CCConcurrencyControl槽位饥饿槽位被普通 INSERT 大量预借真正需要执行 SELECT 的查询拿不到 CPU 槽位线程数暴涨每个 INSERT 都按读查询的并行度申请线程集群总线程数失控。根因写入侧并行度设置的历史演进要理解这个 bug先看两个核心设置的语义。在 src/Core/Settings.cpp 中max_insert_threads (默认 0): - 0 — Auto. Uses the number of CPU cores available to the server (the same auto value as max_threads), reduced under memory pressure by max_insert_threads_min_free_memory_per_thread.而max_threadssrc/Core/Settings.cpp 附近默认同样是0自动但它是读侧并行度SELECT、UNION以及INSERT ... SELECT的 SELECT 一侧的上限。在 25.10 系列中max_insert_threads的默认值发生过行为变化26.8 之前默认是1无并行写入自 26.8 起默认0会解析为 CPU 核数INSERT 默认并行化。也就是说普通 INSERT 的写入侧已经拥有独立的并行度控制参数max_insert_threads。而本 bug 意味着普通 INSERT 在向 ConcurrencyControl 申请资源时错误地沿用了读侧的max_threads上限把写入吞吐放大到了读查询的规模。修复在源码中的落点修复后普通 INSERT 的线程与槽位申请以max_insert_threads为准。关键逻辑位于 src/Interpreters/InterpreterInsertQuery.cppmax_insert_threads getMaxThreadsForAvailableMemory( std::min(std::maxsize_t(1, settings[Setting::max_insert_threads]), max_threads), settings[Setting::max_insert_threads_min_free_memory_per_thread]);这里可以看到一个值得注意的细节即使走max_insert_threads它仍然会按max_threads做一次std::min封顶并受内存可用性max_insert_threads_min_free_memory_per_thread默认 4 GiB见 Settings.cpp的约束——也就是说修复不是放开并行度而是把普通 INSERT 的并发上限定在写入侧应有的尺度上。随后真正的写入并行流数在 InterpreterInsertQuery.cpp 计算const size_t insert_threads (async_insert || dedup_single_stream || serial_hidden_views || sequential_quorum_insert) ? 1 : max_insert_threads;管道层面对并发控制的开关在 InterpreterInsertQuery.cpp// Pipeline ceiling: simple upper bound on parallelism. Actual slot grants are // demand-driven by lazy ConcurrencyControl / CPULeaseAllocation, so a wide ceiling // does not translate into reserved-but-unused slots. const bool serial_views !settings[Setting::parallel_view_processing] insert_dependencies-isViewsInvolved(); pipeline.setNumThreads(serial_views ? 1 : max_threads); pipeline.setConcurrencyControl(settings[Setting::use_concurrency_control]);use_concurrency_control默认开启DECLARE(Bool, use_concurrency_control, true, ...)见 Settings.cpp因此在默认配置下这条修复直接影响每个普通 INSERT 申请的 CPU 槽位数量。ConcurrencyControl 槽位模型为了评估修复效果有必要理解槽位的生命周期。在 src/Common/ConcurrencyControl.h 中有明确的定义槽位生命周期free - granted - acquired - freefree槽位可被任意查询分配granted槽位已分配给某个查询但尚未被任何线程获取acquired槽位已分配给某个查询并被一个线程持有。分配模型allocate(min, max)无条件拿到min个槽位然后按当前空闲容量贪婪补齐到max。max可运行时通过setMax(new_max)调整。调度器支持三种算法ConcurrencyControl.hround_robin释放的槽位在等待的 allocation 之间轮转公平性一般min槽位无条件授予可能超售fair_round_robinmin槽位不占用真实 CPU 槽位无超售竞争更公平max_min_fair类似 fair_round_robin但释放的槽位总是授予当前已分配槽位最少者高过载下公平性更好。服务端设置中三个算法的语义描述见 src/Core/ServerSettings.cpp。此前普通 INSERT 按max_threads读侧上限申请max个槽位在 INSERT 密集的集群上等于每个写入都把大量槽位置于granted状态直接挤压并发查询——这正是 changelog 中 CC slot starvation 与 thread count blowup 两个症状的来源。何时触发、如何观察触发场景无物化视图的普通 INSERT数据来自clickhouse-client或 HTTP 接口而非SELECT且集群 INSERT 吞吐较高、并发写入多。从 InterpreterInsertQuery.cpp 的注释可以确认普通 INSERT 的输入总是单数据流写入侧并行度是在数据读取与 squashing 规划之后再把管道扩展成sink_stream_size个并行流——本修复针对的正是这个写入侧并行度的槽位申请。观察手段关注system.metrics/system.events中与 ConcurrencyControl 相关的指标如ConcurrencyControlQueriesDelayed见 ConcurrencyControl.h 中query_counted的说明以及线程数指标是否在写入高峰出现异常抬升。验证方式升级后在高并发 INSERT 压测下对比升级前后的并发查询延迟与总线程数普通 INSERT 不再以max_threads规模占用 CPU 槽位后SELECT 类查询的响应应明显改善。构建/打包改进distroless 基础镜像升级到 Debian 13本版本包含两条高度相关的打包修复changelog 第 14-15 行升级 distroless 基础镜像Debian 12 → Debian 13PR #103562以消除系统库中的 CVE刷新 distroless 基础镜像PR #103595修复libssl3t64中的 OpenSSL CVE。两条都由 Rahul Nair 提交说明上游在稳定分支上对 distroless 镜像做了升级 加固两步走先迁移到更新的 Debian 大版本再在同一版本内刷新 digest 以纳入最新的 OpenSSL 修复。仓库中的实际镜像配置当前 docker/server/Dockerfile.distroless 已经落到了 Debian 13 上并且使用了固定 digest的不可变引用# Pinned 2026-08-28. Refresh: docker pull gcr.io/distroless/base-nossl-debian13:debug-nonroot docker inspect ... FROM gcr.io/distroless/base-nossl-debian13:debug-nonrootsha256:12224264396c6637ae850ff7f82fb5c759115d9aa4c8b55f4aa7d40059c2e6f1 AS debug ... FROM gcr.io/distroless/base-nossl-debian13:nonrootsha256:5cab74e7f8a5e7c5f1c8a9e6268b1f352f053c36c656f493308340bcecbc636c AS production值得注意的工程实践基础镜像以sha256:...锁定 digest并在注释中给出刷新方法docker pull后取RepoDigests。这样既保证了构建的可复现性又为后续安全升级提供了明确的操作路径。distroless 镜像的构建目标同一 Dockerfile 还展示了两种 distroless 变体Dockerfile.distroless# production — gcr.io/distroless/base-nossl-debian13:nonroot默认 # debug — gcr.io/distroless/base-nossl-debian13:debug-nonroot含 busybox shell docker build -f Dockerfile.distroless --target production -t clickhouse/clickhouse-server:distroless . docker build -f Dockerfile.distroless --target debug -t clickhouse/clickhouse-server:distroless-debug .distroless 镜像不包含包管理器、shellproduction 变体等传统组件攻击面显著小于完整发行版镜像因此其系统库libssl3t64、glibc 等的 CVE 需要靠升级基础镜像 刷新 digest来治理——这正是本次两条 PR 的动机。对生产环境而言若你正在使用 distroless 变体部署 ClickHouse本版本升级后应同步重建镜像确保libssl3t64中的 OpenSSL 漏洞被覆盖。解析器向前兼容视图定义中COMMENT可位于AS SELECT之前changelog 最后一条第 19 行标记为 NOT FOR CHANGELOG / INSIGNIFICANTAcceptCOMMENTbeforeAS SELECTin view parser for forward compatibility with newer versions. (#99559)解析器行为验证在 src/Parsers/ParserCreateQuery.cpp 中物化视图的解析逻辑同时接受POPULATE/EMPTY COMMENT与COMMENT POPULATE/EMPTY两种顺序并且在AS SELECT之后也允许再跟一个注释/// Accept both POPULATE/EMPTY COMMENT and COMMENT POPULATE/EMPTY orderings for materialized views. auto try_parse_populate_or_empty []() { ... }; try_parse_populate_or_empty(); auto comment parseComment(pos, expected); try_parse_populate_or_empty(); ... /// AS SELECT ... if (!s_as.ignore(pos, expected)) return false; if (!select_p.parse(pos, select, expected)) return false; auto select_comment parseComment(pos, expected); if (comment select_comment) throw Exception( ErrorCodes::SYNTAX_ERROR, Comment for a view cannot be specified both before and after AS SELECT; please use only one);这意味着COMMENT ... AS SELECT ...COMMENT 在 AS SELECT 之前与AS SELECT ... COMMENT ...均被接受但不允许同时在AS SELECT前后各写一个注释会抛出SYNTAX_ERROR。这条解析器宽松化属于向前兼容增强新版本生成的视图 DDL注释写在AS SELECT之前可以在本版本上被解析避免跨版本执行 DDL 时因语法差异失败。由于它不改变任何运行时行为因此被归入 NOT FOR CHANGELOG / INSIGNIFICANT 级别。升级建议与验证清单结合以上分析针对 v25.10.7.6-stable 给出如下运维建议高 INSERT 吞吐集群优先升级若你正在运行 25.10 系列且存在大量无物化视图的普通 INSERT本版本的 ConcurrencyControl 修复直接缓解 CC 槽位饥饿与线程数暴涨升级收益明确。使用 distroless 镜像的部署务必重建镜像升级后使用 Dockerfile.distroless 重新构建确认基础镜像指向base-nossl-debian13的已刷新 digest以覆盖libssl3t64的 OpenSSL CVE。升级后回归验证高并发 INSERT 并发 SELECT 混合压测观察并发查询延迟与集群总线程数是否回落执行含视图注释的 DDLCOMMENT在AS SELECT之前确认解析通过且同一视图不得重复声明注释若希望恢复旧行为INSERT 不并行可将max_insert_threads显式设为1见 Settings.cpp 的说明。关注内存约束max_insert_threads自动档下并行度仍受max_insert_threads_min_free_memory_per_thread默认 4 GiB/线程约束低内存节点上并行度会被自动下调至至少 1Settings.cpp无需手工干预。小结v25.10.7.6-stable 是一个聚焦的维护版本一个影响写入侧资源申请的 ConcurrencyControl 修复InterpreterInsertQuery.cpp 中max_insert_threads的正确应用、一组 distroless 镜像的 Debian 13 迁移与 OpenSSL CVE 修复Dockerfile.distroless以及一个视图 DDL 解析器的向前兼容增强ParserCreateQuery.cpp。对于运行 25.10 系列、尤其是 INSERT 密集或使用 distroless 部署的生产集群本版本建议及时升级并按照上述清单完成回归验证。【免费下载链接】ClickHouseClickHouse® is a real-time analytics database management system项目地址: https://gitcode.com/GitHub_Trending/cli/ClickHouse创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 ClickHouse v25.10.7.6-stable 变更解读：INSERT 并发控制修复与 distroless 镜像安全升级
ClickHouse v25.10.7.6-stable 变更解读INSERT 并发控制修复与 distroless 镜像安全升级【免费下载链接】ClickHouseClickHouse® is a real-time analytics database management system项目地址: https://gitcode.com/GitHub_Trending/cli/ClickHouseClickHouse v25.10.7.6-stable 是 25.10 系列的一个维护性稳定版本核心工作集中在两件事修复普通INSERT不经过物化视图在并发控制ConcurrencyControl槽位分配上的过度请求问题以及把 distroless Docker 基础镜像从 Debian 12 升级到 Debian 13 以消除系统库中的 CVE 漏洞。本文基于本仓库的 v25.10.7.6-stable changelog结合src/与docker/下的源码实现逐条解析这些变更的根因、修复方式与运维影响帮助你判断是否升级、以及升级后如何验证。版本背景25.10 系列的维护节奏v25.10.7.6-stable 的完整版本号是v25.10.7.6-stable (16b240cb400)对比基线是上一个稳定版v25.10.6.36-stable (853dbd2ee0c)。从 changelogs 目录 的序列可以看到25.10 系列采用功能版本 高频补丁版本的节奏版本说明v25.10.1.3832-stable25.10 系列首个 stablev25.10.2.65-stable / v25.10.3.100-stable / v25.10.4.104-stable中间补丁版本v25.10.5.40-stable上一补丁版本v25.10.6.36-stable上一补丁版本v25.10.7.6-stable本文版本修复 INSERT 并发槽位过度占用与 v25.10.6.36-stable changelog 相比本版本变更面收窄、目标明确1 个用户可见行为修复 2 个构建/测试/打包改进 1 个解析器兼容性增强属于典型的小步快跑维护版本。Bug Fix普通 INSERT 不再过度占用 ConcurrencyControl 槽位变更内容本版本最重要的修复是见 changelog 第 11 行Plain INSERTs without materialized views no longer request excessive ConcurrencyControl slots and threads (max_threadsinstead ofmax_insert_threads), preventing CC slot starvation and thread count blowup on clusters with high INSERT throughput.对应上游 PR 为 #102961Sema Checherinda回传自 issue #103748。翻译成可操作的语义没有物化视图的普通 INSERT此前会按max_threads而不是max_insert_threads去申请并发控制槽位与线程数导致在高 INSERT 吞吐的集群上出现两类连锁问题CCConcurrencyControl槽位饥饿槽位被普通 INSERT 大量预借真正需要执行 SELECT 的查询拿不到 CPU 槽位线程数暴涨每个 INSERT 都按读查询的并行度申请线程集群总线程数失控。根因写入侧并行度设置的历史演进要理解这个 bug先看两个核心设置的语义。在 src/Core/Settings.cpp 中max_insert_threads (默认 0): - 0 — Auto. Uses the number of CPU cores available to the server (the same auto value as max_threads), reduced under memory pressure by max_insert_threads_min_free_memory_per_thread.而max_threadssrc/Core/Settings.cpp 附近默认同样是0自动但它是读侧并行度SELECT、UNION以及INSERT ... SELECT的 SELECT 一侧的上限。在 25.10 系列中max_insert_threads的默认值发生过行为变化26.8 之前默认是1无并行写入自 26.8 起默认0会解析为 CPU 核数INSERT 默认并行化。也就是说普通 INSERT 的写入侧已经拥有独立的并行度控制参数max_insert_threads。而本 bug 意味着普通 INSERT 在向 ConcurrencyControl 申请资源时错误地沿用了读侧的max_threads上限把写入吞吐放大到了读查询的规模。修复在源码中的落点修复后普通 INSERT 的线程与槽位申请以max_insert_threads为准。关键逻辑位于 src/Interpreters/InterpreterInsertQuery.cppmax_insert_threads getMaxThreadsForAvailableMemory( std::min(std::maxsize_t(1, settings[Setting::max_insert_threads]), max_threads), settings[Setting::max_insert_threads_min_free_memory_per_thread]);这里可以看到一个值得注意的细节即使走max_insert_threads它仍然会按max_threads做一次std::min封顶并受内存可用性max_insert_threads_min_free_memory_per_thread默认 4 GiB见 Settings.cpp的约束——也就是说修复不是放开并行度而是把普通 INSERT 的并发上限定在写入侧应有的尺度上。随后真正的写入并行流数在 InterpreterInsertQuery.cpp 计算const size_t insert_threads (async_insert || dedup_single_stream || serial_hidden_views || sequential_quorum_insert) ? 1 : max_insert_threads;管道层面对并发控制的开关在 InterpreterInsertQuery.cpp// Pipeline ceiling: simple upper bound on parallelism. Actual slot grants are // demand-driven by lazy ConcurrencyControl / CPULeaseAllocation, so a wide ceiling // does not translate into reserved-but-unused slots. const bool serial_views !settings[Setting::parallel_view_processing] insert_dependencies-isViewsInvolved(); pipeline.setNumThreads(serial_views ? 1 : max_threads); pipeline.setConcurrencyControl(settings[Setting::use_concurrency_control]);use_concurrency_control默认开启DECLARE(Bool, use_concurrency_control, true, ...)见 Settings.cpp因此在默认配置下这条修复直接影响每个普通 INSERT 申请的 CPU 槽位数量。ConcurrencyControl 槽位模型为了评估修复效果有必要理解槽位的生命周期。在 src/Common/ConcurrencyControl.h 中有明确的定义槽位生命周期free - granted - acquired - freefree槽位可被任意查询分配granted槽位已分配给某个查询但尚未被任何线程获取acquired槽位已分配给某个查询并被一个线程持有。分配模型allocate(min, max)无条件拿到min个槽位然后按当前空闲容量贪婪补齐到max。max可运行时通过setMax(new_max)调整。调度器支持三种算法ConcurrencyControl.hround_robin释放的槽位在等待的 allocation 之间轮转公平性一般min槽位无条件授予可能超售fair_round_robinmin槽位不占用真实 CPU 槽位无超售竞争更公平max_min_fair类似 fair_round_robin但释放的槽位总是授予当前已分配槽位最少者高过载下公平性更好。服务端设置中三个算法的语义描述见 src/Core/ServerSettings.cpp。此前普通 INSERT 按max_threads读侧上限申请max个槽位在 INSERT 密集的集群上等于每个写入都把大量槽位置于granted状态直接挤压并发查询——这正是 changelog 中 CC slot starvation 与 thread count blowup 两个症状的来源。何时触发、如何观察触发场景无物化视图的普通 INSERT数据来自clickhouse-client或 HTTP 接口而非SELECT且集群 INSERT 吞吐较高、并发写入多。从 InterpreterInsertQuery.cpp 的注释可以确认普通 INSERT 的输入总是单数据流写入侧并行度是在数据读取与 squashing 规划之后再把管道扩展成sink_stream_size个并行流——本修复针对的正是这个写入侧并行度的槽位申请。观察手段关注system.metrics/system.events中与 ConcurrencyControl 相关的指标如ConcurrencyControlQueriesDelayed见 ConcurrencyControl.h 中query_counted的说明以及线程数指标是否在写入高峰出现异常抬升。验证方式升级后在高并发 INSERT 压测下对比升级前后的并发查询延迟与总线程数普通 INSERT 不再以max_threads规模占用 CPU 槽位后SELECT 类查询的响应应明显改善。构建/打包改进distroless 基础镜像升级到 Debian 13本版本包含两条高度相关的打包修复changelog 第 14-15 行升级 distroless 基础镜像Debian 12 → Debian 13PR #103562以消除系统库中的 CVE刷新 distroless 基础镜像PR #103595修复libssl3t64中的 OpenSSL CVE。两条都由 Rahul Nair 提交说明上游在稳定分支上对 distroless 镜像做了升级 加固两步走先迁移到更新的 Debian 大版本再在同一版本内刷新 digest 以纳入最新的 OpenSSL 修复。仓库中的实际镜像配置当前 docker/server/Dockerfile.distroless 已经落到了 Debian 13 上并且使用了固定 digest的不可变引用# Pinned 2026-08-28. Refresh: docker pull gcr.io/distroless/base-nossl-debian13:debug-nonroot docker inspect ... FROM gcr.io/distroless/base-nossl-debian13:debug-nonrootsha256:12224264396c6637ae850ff7f82fb5c759115d9aa4c8b55f4aa7d40059c2e6f1 AS debug ... FROM gcr.io/distroless/base-nossl-debian13:nonrootsha256:5cab74e7f8a5e7c5f1c8a9e6268b1f352f053c36c656f493308340bcecbc636c AS production值得注意的工程实践基础镜像以sha256:...锁定 digest并在注释中给出刷新方法docker pull后取RepoDigests。这样既保证了构建的可复现性又为后续安全升级提供了明确的操作路径。distroless 镜像的构建目标同一 Dockerfile 还展示了两种 distroless 变体Dockerfile.distroless# production — gcr.io/distroless/base-nossl-debian13:nonroot默认 # debug — gcr.io/distroless/base-nossl-debian13:debug-nonroot含 busybox shell docker build -f Dockerfile.distroless --target production -t clickhouse/clickhouse-server:distroless . docker build -f Dockerfile.distroless --target debug -t clickhouse/clickhouse-server:distroless-debug .distroless 镜像不包含包管理器、shellproduction 变体等传统组件攻击面显著小于完整发行版镜像因此其系统库libssl3t64、glibc 等的 CVE 需要靠升级基础镜像 刷新 digest来治理——这正是本次两条 PR 的动机。对生产环境而言若你正在使用 distroless 变体部署 ClickHouse本版本升级后应同步重建镜像确保libssl3t64中的 OpenSSL 漏洞被覆盖。解析器向前兼容视图定义中COMMENT可位于AS SELECT之前changelog 最后一条第 19 行标记为 NOT FOR CHANGELOG / INSIGNIFICANTAcceptCOMMENTbeforeAS SELECTin view parser for forward compatibility with newer versions. (#99559)解析器行为验证在 src/Parsers/ParserCreateQuery.cpp 中物化视图的解析逻辑同时接受POPULATE/EMPTY COMMENT与COMMENT POPULATE/EMPTY两种顺序并且在AS SELECT之后也允许再跟一个注释/// Accept both POPULATE/EMPTY COMMENT and COMMENT POPULATE/EMPTY orderings for materialized views. auto try_parse_populate_or_empty []() { ... }; try_parse_populate_or_empty(); auto comment parseComment(pos, expected); try_parse_populate_or_empty(); ... /// AS SELECT ... if (!s_as.ignore(pos, expected)) return false; if (!select_p.parse(pos, select, expected)) return false; auto select_comment parseComment(pos, expected); if (comment select_comment) throw Exception( ErrorCodes::SYNTAX_ERROR, Comment for a view cannot be specified both before and after AS SELECT; please use only one);这意味着COMMENT ... AS SELECT ...COMMENT 在 AS SELECT 之前与AS SELECT ... COMMENT ...均被接受但不允许同时在AS SELECT前后各写一个注释会抛出SYNTAX_ERROR。这条解析器宽松化属于向前兼容增强新版本生成的视图 DDL注释写在AS SELECT之前可以在本版本上被解析避免跨版本执行 DDL 时因语法差异失败。由于它不改变任何运行时行为因此被归入 NOT FOR CHANGELOG / INSIGNIFICANT 级别。升级建议与验证清单结合以上分析针对 v25.10.7.6-stable 给出如下运维建议高 INSERT 吞吐集群优先升级若你正在运行 25.10 系列且存在大量无物化视图的普通 INSERT本版本的 ConcurrencyControl 修复直接缓解 CC 槽位饥饿与线程数暴涨升级收益明确。使用 distroless 镜像的部署务必重建镜像升级后使用 Dockerfile.distroless 重新构建确认基础镜像指向base-nossl-debian13的已刷新 digest以覆盖libssl3t64的 OpenSSL CVE。升级后回归验证高并发 INSERT 并发 SELECT 混合压测观察并发查询延迟与集群总线程数是否回落执行含视图注释的 DDLCOMMENT在AS SELECT之前确认解析通过且同一视图不得重复声明注释若希望恢复旧行为INSERT 不并行可将max_insert_threads显式设为1见 Settings.cpp 的说明。关注内存约束max_insert_threads自动档下并行度仍受max_insert_threads_min_free_memory_per_thread默认 4 GiB/线程约束低内存节点上并行度会被自动下调至至少 1Settings.cpp无需手工干预。小结v25.10.7.6-stable 是一个聚焦的维护版本一个影响写入侧资源申请的 ConcurrencyControl 修复InterpreterInsertQuery.cpp 中max_insert_threads的正确应用、一组 distroless 镜像的 Debian 13 迁移与 OpenSSL CVE 修复Dockerfile.distroless以及一个视图 DDL 解析器的向前兼容增强ParserCreateQuery.cpp。对于运行 25.10 系列、尤其是 INSERT 密集或使用 distroless 部署的生产集群本版本建议及时升级并按照上述清单完成回归验证。【免费下载链接】ClickHouseClickHouse® is a real-time analytics database management system项目地址: https://gitcode.com/GitHub_Trending/cli/ClickHouse创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考