ClickHouse v25.5.3.75-stable 补丁版本全解析缓存与内存性能优化、依赖安全升级与 19 项 Bug 修复【免费下载链接】ClickHouseClickHouse® is a real-time analytics database management system项目地址: https://gitcode.com/GitHub_Trending/cli/ClickHouse导读本文基于当前仓库中的发布记录 docs/changelogs/v25.5.3.75-stable.md对 ClickHouse v25.5 稳定分支的补丁版本 v25.5.3.75-stablecommit3321577b6dd做一次系统性解读。v25.5.3.75-stable 是在 v25.5.2.47-stablecommitbb5f156f689基础上回移backport了一批修复与改进的维护版本覆盖查询缓存锁竞争、内存跟踪性能回退、Iceberg 数据湖元数据读取、第三方依赖安全升级libarchive / libxml2 / krb5 / orc以及覆盖查询执行、分布式下推、文件格式、Keeper 协调服务等多个维度的 19 项用户可见 Bug 修复。读完本文你将掌握该版本每一条变更的实质内容、触发场景、对应的仓库源码位置以及升级前应关注的兼容性要点。版本概览一次典型的稳定分支维护发布从发布记录可以看到本次发布以v25.5.2.47-stable为基线回移内容按官方分类组织为四大部分Performance Improvement性能改进2 项Improvement功能与稳定性改进10 项Bug Fix用户可见行为修复19 项NO CL CATEGORY未分类与NOT FOR CHANGELOG / INSIGNIFICANT不显著/不进日志共 6 项内部改动。这类补丁版本的意义在于主版本如 25.5开发分支上的修复在经社区评审后通过 backport 机制进入稳定分支让生产环境用户无需等待下一个大版本即可获得关键修复与安全升级。其中多项改动是安全相关的 CVE 修复升级优先级较高。性能改进Performance Improvement1. 降低 QueryConditionCache 的锁竞争#80247变更说明避免不必要的更新并降低QueryConditionCache中的锁竞争。QueryConditionCache是 ClickHouse 用于跳过数据标记marks读取的查询条件缓存。在 src/Common/ProfileEvents.cpp 中定义了与之配套的两个 ProfileEventQueryConditionCacheHitsNumber of times an entry has been found in the query condition cache (and reading of marks can be skipped). Only updated for SELECT queries with SETTING use_query_condition_cache 1.QueryConditionCacheMisses命中失败、无法跳过 mark 读取的次数。从事件注释可以看出该缓存仅在显式开启设置use_query_condition_cache 1的 SELECT 查询中生效。此 PR 的优化核心是在缓存命中写入路径上避免不必要的更新动作并缩小锁的持有范围从而减少高并发查询场景下的锁竞争开销。缓存的实现位于 src/Interpreters/Cache/QueryConditionCache.cpp其键的构造逻辑相当讲究——queryConditionCacheSettingsSalt会把一批会改变函数返回值的设置项如formatDateTime的格式参数、locate的参数顺序、least/greatest的 NULL 行为、h3ToGeo的参数顺序等纳入 SipHash 盐值避免不同设置下缓存键碰撞导致结果错误。此外仓库还配套了单元测试 src/Storages/tests/gtest_query_condition_cache_key.cpp 来验证缓存键的正确性。升级提示本变更不影响查询语义只影响缓存更新的频率与并发行为若你使用了use_query_condition_cache设置可观察到锁竞争降低带来的查询吞吐改善。2. 修复内存跟踪的性能回退#81694变更说明修复内存跟踪memory tracking中的性能回退。ClickHouse 通过MemoryTracker对查询、线程和服务器进程进行细粒度的内存记账用于实现max_memory_usage等限制。该修复针对的是在某次重构后内存跟踪路径上引入的开销回退恢复其原有性能水平。内存跟踪相关实现可参考 src/Common/AsynchronousMetrics.cpp 中MemoryTracker::updateRSS的调用见下文 MemoryResidentWithoutPageCache 小节进程级 RSS 会定期同步到 MemoryTracker 中。此类修复对高吞吐、多并发查询的实例尤为关键因为内存记账位于查询热路径上。功能与稳定性改进Improvement1.system.iceberg_history支持 Catalog 数据库并重命名列#80975变更说明现在system.iceberg_history会对 catalogs 数据库如 glue、iceberg rest显示历史同时为了一致性将table_name和database_name列改名为table和database。这条改进同时包含能力扩展与破坏性变更两部分能力扩展此前该系统表仅覆盖通过 Iceberg 表函数/引擎直接挂载的表现在对通过 Catalog如 AWS Glue Catalog、Iceberg REST Catalog注册的 Iceberg 数据库也能展示快照历史。列名变更table_name→tabledatabase_name→database。任何依赖旧列名的查询、监控面板或下游 ETL 都需要同步调整。在 src/Storages/System/StorageSystemIcebergHistory.cpp 中可以看到该表当前完整的列结构getColumnsDescription列名类型说明databaseString数据库名tableString表名made_current_atNullable(DateTime64(3))该快照成为当前快照的时间Iceberg 规范中时间戳以毫秒存储故TIME_SCALE 3snapshot_idUInt64快照 IDparent_idUInt64父快照 IDis_current_ancestorUInt8该快照是否为当前快照的祖先operationEnum8快照操作APPEND、OVERWRITE、REPLACE、DELETE、UNKNOWNsummaryMap(String, String)快照摘要字段值得注意的细节fillData在读取历史时会强制将设置use_iceberg_metadata_files_cache关闭src/Storages/System/StorageSystemIcebergHistory.cpp以确保每次查询拿到的是最新元数据同时会做SHOW_TABLES权限检查。历史的实际解析逻辑位于 src/Storages/ObjectStorage/DataLakes/Iceberg/IcebergMetadata.cpp 的IcebergMetadata::getHistory它通过读取 metadata 文件中的snapshot-log与parent-snapshot-id字段来还原快照血缘并标记当前祖先链。2. 第三方依赖安全升级#81174 / #81187 / #81453 / #81455本版本集中升级了四个第三方组件其中两项直接对应 CVE 安全公告依赖升级版本修复的 CVE仓库集成位置libarchive3.7.9CVE-2024-20696、CVE-2025-25724、CVE-2024-48958、CVE-2024-57970、CVE-2025-1632、CVE-2024-48957、CVE-2024-48615contrib/libarchive-cmakelibxml22.14.3—常规升级contrib/libxml2krb51.21.3-final—常规升级contrib/libkrb5orc2.1.2—常规升级contrib/orc其中 libarchive 的升级一口气封堵了 7 个 CVE涉及归档解压路径上的内存安全问题。对于通过 HTTP 接口导入tar、zip等归档格式、或使用 S3/对象存储 归档读取能力的部署该升级对安全性意义重大。libxml2 用于 XML 解析例如xpath相关函数与部分配置解析。这些组件均通过 contrib 目录下的子模块与 CMake 构建系统集成。3. 新增异步指标MemoryResidentWithoutPageCache#81233变更说明MemoryResidentWithoutPageCache提供服务器进程使用的物理内存量以字节为单位排除 userspace page cache从而在启用了 userspace page cache 时更准确地反映真实内存占用当 userspace page cache 禁用时该值等于MemoryResident。userspace page cache 是 ClickHouse 在对象存储S3、HDFS 等场景下引入的用户态缓存层它把远程数据块缓存到本地磁盘/内存中避免重复从远端拉取。此时/proc报告进程 RSS 会包含这部分缓存导致内存占用异常高的误判。该指标在 src/Common/AsynchronousMetrics.cpp 中实现计算逻辑非常直观UInt64 page_cache_bytes 0; if (context context-getPageCache()) page_cache_bytes context-getPageCache()-sizeInBytes(); UInt64 resident_without_page_cache (data.resident page_cache_bytes) ? (data.resident - page_cache_bytes) : 0; new_values[MemoryResidentWithoutPageCache] { resident_without_page_cache, ... };即在 Linux/FreeBSD/SunOS 上从进程常驻内存data.resident中扣除当前 page cache 占用的字节数当 page cache 字节数超过 RSS 时取 0。该指标会出现在system.asynchronous_metrics表中配合已有的MemoryResident、MemoryVirtual使用可显著改善启用了 page cache 却按 RSS 告警的监控误报问题。4. 新增 ProfileEventPageCacheReadBytes#81742变更说明新增 profile eventPageCacheReadBytes。该事件在 src/Common/ProfileEvents.cpp 中定义M(PageCacheReadBytes, Number of bytes read from userspace page cache., ValueType::Bytes)它统计从 userspace page cache 中读取的字节数与上面MemoryResidentWithoutPageCache形成闭环一个是 cache 的存量bytes 占用一个是 cache 的流量读取量。运维者可以通过system.events中的PageCacheReadBytes判断查询对 page cache 的实际命中利用情况从而评估缓存配置是否合理。5. Iceberg manifest 文件推迟读取#81619与内存占用优化#81470变更说明#81619将 Iceberg manifest 文件的读取推迟到首次读取查询时进行变更说明#81470Bug Fix 部分不要将多个 manifest 文件的内容保存在内存中。这两条共同优化了 Iceberg 表元数据加载的内存与 IO 成本。Iceberg 元数据是三层结构metadata.json→manifest list→ 多个manifest文件每个 manifest 记录一批数据文件的位置与统计信息。在 src/Storages/ObjectStorage/DataLakes/Iceberg/IcebergMetadata.cpp 的backgroundMetadataPrefetcherThread中可以看到原先行径后台预取线程会在后台定时任务里一次性获取最新 metadata、解析 manifest list并逐个拉取、解析、缓存所有 manifest 文件。而 #81619 的调整思路是在不需要真正扫描数据的场景如仅查system.iceberg_history、system.iceberg_files或元数据操作下推迟 manifest 的实际读取直到首次真正执行读取数据的查询#81470 则避免把多个 manifest 的完整内容同时驻留内存。对拥有大量 manifest 文件的宽表或高频元数据查询场景这两项能明显降低内存峰值与启动/建表时的 IO 开销。6. 文件系统 journal 写入移出 reserve 锁作用域#81371变更说明在带 journal 的文件系统中mkdir会被写入文件系统的 journal 并持久化到磁盘。在慢盘上这可能耗时很长将其移出 reserve 锁作用域是明确合理的。该改动针对 ClickHouse 的本地/远程文件系统实现中加锁保护写入预留reserve区域的场景。此前mkdir创建目录操作在持锁状态下执行慢盘上的 journal 持久化会长时间阻塞其他并发操作现在将目录创建移出锁作用域减少慢盘环境下的锁等待。7. 修复 filesystem cache 逻辑错误#81868变更说明尝试修复 filesystem cache 中的逻辑错误Having zero bytes but range is not finished。这是 userspace page cache 在极端竞态下可能抛出的断言类逻辑错误某个 range 被标记为尚未读完但读到的字节数为 0。该修复针对缓存读取路径上的状态判断避免查询意外失败。这与上文PageCacheReadBytes、MemoryResidentWithoutPageCache属于同一套 page cache 子系统实现分布在 src/Interpreters/Cache 与 src/Common/PageCache 相关文件中。Bug 修复Bug Fix本版本共回移 19 项用户可见的 Bug 修复按主题可归为以下几组。查询优化器与分布式下推CTE 与谓词下推#77316修复启用allow_push_predicate_ast_for_distributed_subqueries时CTE公共表表达式在分布式子查询谓词下推中的使用问题对应上游 issue #75647、#79672。相关列检查逻辑错误#79727修复检查列是否为相关列时产生的columns unknown origin scope逻辑错误对应 issue #78183、#79451。分布式下推缺失表报错#80915修复在发起端initiator源表不存在、且启用allow_push_predicate_ast_for_distributed_subqueries1时分布式查询下推谓词却报Table does not exist的错误对应 issue #77281。跨副本本地分布式产品模式#81162修复distributed_product_mode_locallocal在跨复制cross-replication场景下报Unknown table expression identifier的问题。这些修复集中在 src/Interpreters 与 src/Planner 的查询分析、分布式查询规划路径上。allow_push_predicate_ast_for_distributed_subqueries是用于将过滤条件下推到分布式子查询的 AST 级设置这组修复保证其在 CTE、缺表、跨副本等组合场景下不再产生错误结果或异常报错。存储引擎与文件格式Merge 引擎列缺失#80643修复 Merge 引擎中某列只存在于部分子表时读取结果不正确的问题。Merge 引擎会并集多个表列集合不一致时容易出现错位或错误值。Projection 与子列崩溃#80333修复带 subcolumns如arr.size0、map.keys等嵌套结构子列的 projections 可能引发的逻辑错误与崩溃。Parquet 行数缓存#81184修复 parquet 文件在过滤后行数被错误缓存的问题该问题会导致后续查询返回错误行数。clickhouse-local 输出 Parquet 崩溃#81249修复clickhouse-local以 Parquet 格式输出常量元组const tuple或 map 时崩溃的问题。JSON 解析 DateTime64#81050修复JSONExtract及 JSON 类型解析中从整数解析DateTime64的问题如时间戳整数字面量被错误处理。HTTP 文本格式插入缺省 Enum 崩溃#81145修复通过 HTTP 协议以文本格式JSON、Values等插入且省略Enum字段时报Too large size ... passed to allocator或崩溃的问题——这是典型的输入解析缓冲区计算缺陷攻击面涉及所有 HTTP 批量导入场景。Hive 分区禁用#80005为 data lakes 禁用 hive 分区逻辑部分解决相关数据湖读取代价问题对应上游 issue #79937 的部分缓解。查询执行边界情况空表 JOIN 窗口函数流爆炸#81299修复查询连接空表并使用窗口函数时并行流数量爆炸导致 OOM 的边界情况。该问题在空表场景下错误地放大了流stream的数量属于资源耗尽型故障。标量相关子查询可空结果#81632让标量相关子查询返回投影表达式的可空结果修复相关子查询产生空结果集时的类型/取值错误。TTL 字典合并上下文过期#81690修复 TTL 表达式中使用字典时合并merge过程中报Context has expired的问题。ConcurrentHashJoin 空 USING 崩溃#81754修复旧分析器old analyzer下ConcurrentHashJoin使用空USING ()时崩溃的问题。divideOrNull 的 JIT#81370禁用divideOrNull函数上不正确的 JIT 编译——该函数被错误地交给 JIT 编译路径可能产生错误结果因此改为回退到解释执行。Iceberg / Delta Lake 数据湖Delta Lake region 错误#81353修复 delta-kernel 中的 region 错误对应 issue #79914。Manifest 内存驻留#81470见上文 Improvement 部分避免多个 manifest 文件内容同时驻留内存。Keeper 协调服务无效日志条目阻塞提交#81780Keeper 修复如果日志中存在无效条目则阻止提交新的日志。此前如果 leader 错误地应用了某些日志它会继续提交新日志即使 follower 检测到 digest 不匹配并中止。这是本次发布中最关键的分布式一致性修复之一。ClickHouse Keeper 使用 Raft 协议正常情况下 follower 校验日志 digest一旦发现与 leader 不一致会中止但旧行为下 leader 可能在已存在无效日志的情况下继续提交新日志扩大分歧。修复后在检测到无效条目时阻断后续提交避免集群状态进一步分化。Keeper 相关实现位于 src/Coordination。内部条目NO CL CATEGORY 与 NOT FOR CHANGELOGNO CL CATEGORY#81372、#81975两条未归类条目一条回移自 Smita Kulkarni#81372一条来自 Nikita Mikhaylov#81975。发布记录中未给出具体描述属于未附带分类说明的回移改动对外部用户通常无直接可观测影响。NOT FOR CHANGELOG / INSIGNIFICANT4 项默认关闭 job 栈跟踪采集#80978Disable collecting job stack traces by default。减少后台任务栈跟踪采集带来的额外开销涉及 src/Processors/QueryPlan 相关的 job 执行框架。降低 NATS 重连日志噪音#81587让 NATS 连接重试在日志中不再刷屏属于可观测性体验改进NATS 引擎相关代码位于 src/Storages/MessageQueue。修复 CVE-2023-0286 / CVE-2023-5678#81672额外封堵两个 X.509/ASN.1 解析相关的安全漏洞与上文的依赖升级共同构成本次发布的安全加固组合。MergeTree 事务元数据补全#81734修复appendRemovalTIDToVersionMetadata对covered_parts的处理——即使在无事务删除的情况下也会在事务元数据文件中写入removal_id从而避免重启时因part 处于 Outdated 状态但缺少 removal tid触发逻辑错误典型报错形如Logical error: Data part 202410_1_42_8 is Outdated ... but does not have removal tid。相关逻辑位于 src/Storages/MergeTree/MergeTreeTransaction.cpp 及其配套文件。升级建议与验证清单综合本版本变更升级到 v25.5.3.75-stable 前建议核对以下几点破坏性变更优先处理system.iceberg_history的table_name/database_name列已更名为table/database请同步修改所有依赖旧列名的查询与监控当前列结构见 src/Storages/System/StorageSystemIcebergHistory.cpp。安全升级优先级高libarchive 修复了 7 个 CVElibxml2、krb5、orc 同步升级另有 X.509 相关 CVE-2023-0286/CVE-2023-5678 修复。凡对外提供 HTTP 导入或使用归档/XML/对象存储能力的部署建议尽快升级。内存监控方式更新启用了 userspace page cache 的实例可用新增的MemoryResidentWithoutPageCachesystem.asynchronous_metrics与PageCacheReadBytessystem.events区分真实内存与缓存内存避免误告警。Keeper 集群建议在升级窗口内滚动重启 Keeper 节点使 digest 不一致的日志保护逻辑生效。功能验证若使用 Iceberg/Delta Lake 数据湖表回归验证元数据查询system.iceberg_history与首次读取查询若使用use_query_condition_cache 1、allow_push_predicate_ast_for_distributed_subqueries 1、distributed_product_mode_local等设置回归对应查询路径。关于版本基线与回移的完整条目清单均可直接查阅仓库内的发布记录 docs/changelogs/v25.5.3.75-stable.md若需按季度浏览该分支的演进历史可参见 docs/changelogs 目录下的其他版本记录。【免费下载链接】ClickHouseClickHouse® is a real-time analytics database management system项目地址: https://gitcode.com/GitHub_Trending/cli/ClickHouse创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考