ClickHouse v25.3.7.194-lts 变更日志深度解读Keeper 稳定性、内存管理与查询正确性修复【免费下载链接】ClickHouseClickHouse® is a real-time analytics database management system项目地址: https://gitcode.com/GitHub_Trending/cli/ClickHouse本篇文章基于当前仓库 docs/changelogs/v25.3.7.194-lts.md 中记录的 ClickHouse v25.3.7.194-lts构建号 36637934778发布内容展开逐个剖析该 LTS 补丁版本在 KeeperClickHouse 内置的 ZooKeeper 替代品、内存追踪器、Data Lake 集成、查询分析与各类存储引擎上的关键改进与 Bug 修复并对照src目录下的真实源码与配置实现进行交叉印证帮助读者理解每个变更背后的原理、影响范围与升级收益。读完本文你将能够判断该补丁版本是否值得升级快速定位与本次修复相关的源码与配置项并在生产环境中针对性地进行验证与监控。版本背景一次典型的 LTS 补丁迭代v25.3.7.194-lts 是在 v25.3.6.56-lts 基础上的累积补丁版本属于 25.3 LTS 分支的维护迭代。changelog 头部保留了FIXME占位标记说明这是由发布流程自动生成、持续更新中的草稿性变更记录但其中收录的条目均为实际合入并 backport 到 25.3 分支的改动。从整体构成看该版本包含三个主要类别Improvement改进8 条集中在 Web UI 体验、Keeper 性能与可观测性、内存追踪准确性、Data Lake 系统表可见性Bug Fix用户可见行为修复超过 40 条覆盖查询分析器Analyzer、Keeper、存储引擎、格式读写、访问控制等多个领域Build/Testing/Packaging Improvement1 条PostgreSQL 测试镜像升级到 18.0另有少量NO CL ENTRY回滚类与NOT FOR CHANGELOG / INSIGNIFICANT内部健壮性修复。Keeper本版本最集中的改进方向Keeper 是 ClickHouse 内置的、兼容 ZooKeeper 协议的协调服务组件。v25.3.7 中 Keeper 相关的改动密度最高既包含性能优化也包含数据安全修复。新增 4LW 命令lgrq动态开关请求日志本次新增了一个四字母命令4 Letter Word4LWlgrq用于动态切换 Keeper 对收到的请求的日志记录request logging无需重启服务即可排查请求流量。该命令的实现位于 src/Coordination/FourLetterCommand.hstruct ToggleRequestLogging : public IFourLetterCommand { explicit ToggleRequestLogging(KeeperDispatcher keeper_dispatcher_) : IFourLetterCommand(keeper_dispatcher_) { } String name() override { return lgrq; } String run() override; ~ToggleRequestLogging() override default; };该命令被注册进 Keeper 支持的 4LW 列表见 src/Coordination/CoordinationSettings.cpp。使用方法与 Keeper 的其他 4LW 命令一致即通过 TCP 直连 Keeper 端口并发送命令文本例如echo lgrq | nc localhost 9181同样地ruok、srvr、mntr、stat等既有 4LW 命令也列在同一注册表中lgrq的加入使得运维可以在不修改配置、不重启的前提下按需打开或关闭请求级日志——在生产环境高流量时默认关闭日志、排障时临时开启是典型的低侵入排障手段。降低 Keeper 存储锁竞争Keeper 的请求处理链路高度依赖存储层锁。本次变更backport #84866PR #84732通过调整锁的使用方式降低了 storage lock 上的竞争contention。从 src/Coordination/CoordinationSettings.cpp 可以看到新式请求分发器use_new_dispatcher默认启用及max_in_flight_request_batches默认 20等参数都围绕请求并发管线设计本项优化即是在这一管线中减少全局锁的串行化点提升多请求并发吞吐。用条目数限制 Keeper 日志缓存大小Keeper 会将最新日志条目缓存在内存中以加速读路径此前仅通过内存字节上限latest_logs_cache_size_threshold默认 1 GiB约束。本次新增按条目数限制的配置项配置项默认值语义keeper_server.coordination_settings.latest_logs_cache_entry_count_threshold200,000最新日志条目内存缓存的最大条目数keeper_server.coordination_settings.commit_logs_cache_entry_count_threshold100,000已废弃无实际效果请改用log_readahead_commit_window_bytes源码定义见 src/Coordination/CoordinationSettings.cpp其中commit_logs_cache_entry_count_threshold已被明确标记为OBSOLETE废弃这说明它仅是出于向后兼容保留的占位参数实际配置提交日志预读窗口时应使用log_readahead_commit_window_bytes。缓存的实际构造在 src/Coordination/Changelog.cpp: latest_logs_cache(log_settings.latest_logs_cache_size_threshold, log_settings.latest_logs_cache_entry_count_threshold)即字节阈值与条目数阈值共同生效src/Coordination/KeeperStateManager.cpp 负责把配置透传给 Changelog两条限制同时满足才会停止缓存新条目。这一改动对内存压力较大的 Keeper 节点尤为重要单条日志条目内存开销不可控时仅靠字节上限可能仍缓存过多小条目增加条目数上限可避免缓存失控。修复 Keeper changelog 乱序写入导致的数据丢失风险这是本版本中 Keeper 方向最值得重视的修复backport #84648PR #84434此前 changelog 的写入可能存在 in-flight 并发写而回滚rollback操作可能并发修改目标文件导致日志不一致乃至数据丢失。修复后写入顺序得到保证消除了回滚与写入并发交织的窗口。对于依赖 Keeper 存放分布式 DDL 元数据、复制表协调信息的集群建议尽快升级到包含此修复的版本。其他 Keeper 修复与优化会话关闭时临时节点删除导致 watch 计数错误#83583修复 ephemeral 节点删除时总 watch 数统计不正确的问题总 watch 数返回不正确#84890修复wchs/mntr等命令汇报的 watch 总数RemoveRecursive 请求性能改进#86789优化递归删除节点的处理路径并在 Multi 请求中先检查特性开关#86554减少 Keeper 中的多余拷贝#85131降低请求处理路径的内存拷贝开销S3Queue 有序模式提前退出#84463收到 shutdown 信号后立即退出有序消费循环加快优雅停机system.distributed_ddl_queue容错#86848当部分任务缺少对应 Keeper 节点时不再查询失败KeeperMap 遗留数据清理#87112修复 25.1 之前创建的 KeeperMap 表在 DROP 后仍残留 ZooKeeper 数据的问题。内存管理cgroup 感知与内存追踪校正v25.3.7 将 cgroup 内存信息引入内存追踪memory tracker校正流程。新增/调整了以下服务端设置定义见 src/Core/ServerSettings.cppmemory_worker_use_cgroup默认true当容器环境存在 cgroup 且可用时使用当前 cgroup 的内存使用信息来校正内存追踪memory_worker_correct_memory_tracker默认false控制后台内存 worker 是否基于 jemalloc、cgroups 等外部来源校正内部 memory trackermemory_worker_period_ms默认 0自动取值后台内存 worker 的 tick 周期memory_worker_purge_dirty_pages_threshold_ratio默认 0.2、memory_worker_purge_total_memory_threshold_ratio默认 0.9触发 jemalloc dirty pages 强制清理的阈值。在容器化部署下ClickHouse 看到的宿主内存往往与 cgroup 配额不一致若不校正内存追踪可能失真进而导致 OOM 或被max_server_memory_usage错误限制。启用memory_worker_use_cgroup默认即开后后台内存 worker 以 cgroup 实际用量为准修正追踪值使硬限制检查更贴近容器真实内存水位。同方向的其他修复还包括estimateCompressionRatio()在block_size_bytes0时陷入死循环的问题#83704以及临时数据释放未计入max_temporary_data_on_disk_size限制的问题#87140。Web UI 与 Data Lake 集成改进Web UI 交互修复针对 Web UI 的两个体验问题PR #81131一是正确识别没有输出结果的查询如CREATE、INSERT此前这类查询会导致无限 spinner二是双击表名时自动滚动到页面顶部。这两项改进直接作用于programs/server中的嵌入式 Web 控制台资源低版本用户在浏览器端即可感知差异。show_data_lake_catalogs_in_system_tablesData Lake 目录可见性开关新增查询级设置show_data_lake_catalogs_in_system_tables默认false用于控制 Data Lake 目录是否出现在system.tables等系统表中。其定义位于 src/Core/Settings.cppDECLARE(Bool, show_data_lake_catalogs_in_system_tables, false, R( Enables showing data lake catalogs in system tables. ), 0) \该开关实际作用于多处系统表查询路径包括 src/Storages/System/StorageSystemTables.cpp、src/Storages/System/StorageSystemColumns.cpp 以及 src/Storages/System/StorageSystemCompletions.cpp通过.with_datalake_catalogs settings[Setting::show_data_lake_catalogs_in_system_tables]控制是否附带 Data Lake 目录信息在 src/Databases/DataLake/DatabaseDataLake.cpp 中同样受该设置约束。此外 src/Interpreters/DatabaseCatalog.cpp 显示当数据库是 Data Lake 目录isDatalakeCatalog()且该设置为 false 时会跳过对应的解析逻辑。实际含义是默认情况下 Data Lake 目录不会“污染”system.tables的枚举结果例如通过 Iceberg/Delta Lake 目录挂载的大量外部表需要查看时再显式开启。与之配套的还有show_remote_databases_in_system_tables默认true控制 MySQL/PostgreSQL 外部数据库在系统表中的可见性见 src/Core/Settings.cpp。查询正确性Analyzer 与执行引擎的密集修复25.3 系列默认启用新分析器Analyzer本版本围绕它修复了多个可能导致错误结果或逻辑错误的场景distributed_aggregation_memory_efficient与并行处理冲突#78500当开启distributed_aggregation_memory_efficient时禁用从FROM读取后立即并行处理查询的阶段否则可能触发逻辑错误LOGICAL ERRORJOIN 过滤下推导致NOT_FOUND_COLUMN_IN_BLOCK#80360当ON表达式不是平凡等值条件时逻辑 JOIN 的 filter-push-down 优化可能引用不存在的列本次一并修复了两个相关 issue#79647、#77848VIEW 二次查询全列读取的性能回退#83036启用分析器后子查询读取 VIEW 时会错误地总是读取全部列导致性能退化WITH 子句外层别名引用#83797引入向后兼容设置允许新分析器在名字冲突时引用 WITH 中的外层别名remote表函数view(...)参数限制#83844启用分析器后允许在view(...)中引用任意表additional_table_filters中的IN (subquery)#85210修复Not-ready Set问题避免子查询集合未就绪时被错误使用parallel replicas 反向顺序读取#85406并行副本使用 reverse order 优化读取时可能产生错误结果已修复PREWHERE 拆分为多步后输出未正确 cast#87040session_timezone下 datetime 键的错误分区/粒度消除#87987使用session_timezone设置时基于 datetime 的键可能错误地消除 granule/partition*Cluster函数去重判断改用collaborate_with_initiator#85734此前用distributed_depth判断是否来自 *Cluster 函数可能误判并导致数据重复现改用client_info.collaborate_with_initiator。存储引擎与类型系统修复MergeTree 家族TTL 全部移除后不应再做 TTL 相关工作#84441表的所有 TTL 被移除后MergeTree 不再执行任何 TTL 相关逻辑ALTER MODIFY ORDER BY校验 TTL 列#84536在排序键中使用 TTL 列会在 ALTER 期间被正确拒绝防止潜在的表损坏跳过索引 lambda 表达式无法应用#80025当索引定义中的高阶函数与查询中的函数完全匹配时跳过索引未被正确应用已修复无依赖建表不再检查循环依赖#83077修复创建数千张无依赖表时的性能退化该退化由较早的一次改动引入add_minmax_index_for_*与复制库初始化冲突#83751若以add_minmax_index_for_numeric_columns1或add_minmax_index_for_string_columns1建表索引在后续 ALTER 中物化可能阻止复制数据库Replicated database在新副本上正确初始化备份含损坏投影projection的 part#85362修复含损坏投影数据分区的备份失败问题。动态类型Dynamic / Variant / JSONClickHouse 的“半结构化”类型家族在本版本修复密集Dynamic 列解析失败时回滚#82169Variant 类型在 UNION 中可能崩溃#83295LowCardinality(Nullable(T))转 Dynamic 的 cast#86365ALTER UPDATENullable(JSON) 崩溃#86281JSON 中带 Enum 提示的路径默认值错误#86065RowBinary 写入 JSON 路径 NULL 值#83923以及 RowBinary 输入格式向 JSON 共享数据写 NULL 的校验#86812子列参与物化表达式时 ALTER UPDATE 未正确更新#85985禁止修改其子列被 PK 或分区表达式使用的列#86005。格式与外部数据Parquet 写入 Decimal 统计错误#83754修复 Decimal 类型 min/max 统计输出不正确Parquet offset index 行号错误#83876兼容设置output_format_parquet_date_as_uint16#85510将 Date 作为 UInt16 写入 Parquet 的兼容选项Avro schema registry 认证信息脱敏#83713含两次 revert/重新 backport#84195、#84212确保用户与日志中不暴露认证细节icebergS3Cluster / icebergAzureCluster 密钥脱敏#85658AzureIteratorAsync 双重释放#85064EmbeddedRocksDB 路径必须位于 user_files 内#87109并回退默认使用data/路径#87463。访问控制、复制与 DDLno_password用户登录崩溃#84426当服务器设置allow_no_password被改为 0 后以no_password创建的用户登录会导致服务器崩溃已修复Buffer 表 select/insert 访问校验#87545SYSTEM DROP REPLICA多余getStatus()调用#85220去掉不必要的调用避免表在后台删除时抛出Shutdown for storage is calledCREATE OR REPLACE / RENAME 表名长度校验#85326复制数据库Replicated database元数据校验放宽#80298对 RMT 执行更宽松的元数据检查CREATE ... AS (SELECT * FROM s3Cluster(...))配合 DatabaseReplicated 的逻辑错误#85904恢复数据库副本时正确关闭表#84744不当关闭会导致部分表引擎在副本恢复期间触发 LOGICAL_ERRORTimeSeries 引擎表阻止复制库创建新副本#86845异步删除的视图覆盖全局服务器设置#87603若视图被异步删除且服务器在后台清理完成前重启SELECT 设置可能错误覆盖全局服务器设置已修复system.tables读取外部数据库PostgreSQL/SQLite中无效表时的未捕获异常#88105。构建与测试改进PostgreSQL 测试镜像升级到 18.0#87647提升tests/integration中 PostgreSQL 相关集成测试对最新版本数据库的覆盖sccache 显式启动#83600在ninja构建阶段之前显式启动 sccache 服务器改善 CI 构建缓存命中率并发建表池自动扩容#83834当max_database_replicated_create_table_thread_pool_size0自动池大小时允许并发建表。升级建议与验证清单综合本版本的变更特征给出如下建议优先升级的场景重度使用 Keeper 的集群changelog 乱序写入、watch 计数、锁竞争等多项修复直接提升稳定性和数据安全性容器化部署并依赖精确内存追踪的实例cgroup 校正使用 Parquet 作为主要导出格式、以及使用 Dynamic/Variant/JSON 半结构化类型的业务多项错误结果与崩溃修复。升级后可执行的验证 SQL-- 验证 Data Lake 目录在系统表中的可见性开关 SHOW SETTINGS LIKE show_data_lake_catalogs_in_system_tables; SET show_data_lake_catalogs_in_system_tables 1; SELECT count() FROM system.tables; -- 验证内存相关设置 SHOW SETTINGS LIKE memory_worker%; -- 检查 Keeper 4LW 命令是否可用在 Keeper 节点执行 -- echo lgrq | nc keeper_host 9181Keeper 缓存参数按需调整若 Keeper 节点内存压力大可降低keeper_server.coordination_settings.latest_logs_cache_entry_count_threshold默认 200000与latest_logs_cache_size_threshold默认 1 GiB注意commit_logs_cache_entry_count_threshold已废弃配置提交日志预读请使用log_readahead_commit_window_bytes。以上所有结论均可在当前仓库对应源码路径中复现验证changelog 原文请参考 docs/changelogs/v25.3.7.194-lts.md。由于 changelog 头部带有 FIXME 标记个别条目在最终发布说明中可能略有调整建议以正式发布公告为准。【免费下载链接】ClickHouseClickHouse® is a real-time analytics database management system项目地址: https://gitcode.com/GitHub_Trending/cli/ClickHouse创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
ClickHouse v25.3.7.194-lts 变更日志深度解读：Keeper 稳定性、内存管理与查询正确性修复
ClickHouse v25.3.7.194-lts 变更日志深度解读Keeper 稳定性、内存管理与查询正确性修复【免费下载链接】ClickHouseClickHouse® is a real-time analytics database management system项目地址: https://gitcode.com/GitHub_Trending/cli/ClickHouse本篇文章基于当前仓库 docs/changelogs/v25.3.7.194-lts.md 中记录的 ClickHouse v25.3.7.194-lts构建号 36637934778发布内容展开逐个剖析该 LTS 补丁版本在 KeeperClickHouse 内置的 ZooKeeper 替代品、内存追踪器、Data Lake 集成、查询分析与各类存储引擎上的关键改进与 Bug 修复并对照src目录下的真实源码与配置实现进行交叉印证帮助读者理解每个变更背后的原理、影响范围与升级收益。读完本文你将能够判断该补丁版本是否值得升级快速定位与本次修复相关的源码与配置项并在生产环境中针对性地进行验证与监控。版本背景一次典型的 LTS 补丁迭代v25.3.7.194-lts 是在 v25.3.6.56-lts 基础上的累积补丁版本属于 25.3 LTS 分支的维护迭代。changelog 头部保留了FIXME占位标记说明这是由发布流程自动生成、持续更新中的草稿性变更记录但其中收录的条目均为实际合入并 backport 到 25.3 分支的改动。从整体构成看该版本包含三个主要类别Improvement改进8 条集中在 Web UI 体验、Keeper 性能与可观测性、内存追踪准确性、Data Lake 系统表可见性Bug Fix用户可见行为修复超过 40 条覆盖查询分析器Analyzer、Keeper、存储引擎、格式读写、访问控制等多个领域Build/Testing/Packaging Improvement1 条PostgreSQL 测试镜像升级到 18.0另有少量NO CL ENTRY回滚类与NOT FOR CHANGELOG / INSIGNIFICANT内部健壮性修复。Keeper本版本最集中的改进方向Keeper 是 ClickHouse 内置的、兼容 ZooKeeper 协议的协调服务组件。v25.3.7 中 Keeper 相关的改动密度最高既包含性能优化也包含数据安全修复。新增 4LW 命令lgrq动态开关请求日志本次新增了一个四字母命令4 Letter Word4LWlgrq用于动态切换 Keeper 对收到的请求的日志记录request logging无需重启服务即可排查请求流量。该命令的实现位于 src/Coordination/FourLetterCommand.hstruct ToggleRequestLogging : public IFourLetterCommand { explicit ToggleRequestLogging(KeeperDispatcher keeper_dispatcher_) : IFourLetterCommand(keeper_dispatcher_) { } String name() override { return lgrq; } String run() override; ~ToggleRequestLogging() override default; };该命令被注册进 Keeper 支持的 4LW 列表见 src/Coordination/CoordinationSettings.cpp。使用方法与 Keeper 的其他 4LW 命令一致即通过 TCP 直连 Keeper 端口并发送命令文本例如echo lgrq | nc localhost 9181同样地ruok、srvr、mntr、stat等既有 4LW 命令也列在同一注册表中lgrq的加入使得运维可以在不修改配置、不重启的前提下按需打开或关闭请求级日志——在生产环境高流量时默认关闭日志、排障时临时开启是典型的低侵入排障手段。降低 Keeper 存储锁竞争Keeper 的请求处理链路高度依赖存储层锁。本次变更backport #84866PR #84732通过调整锁的使用方式降低了 storage lock 上的竞争contention。从 src/Coordination/CoordinationSettings.cpp 可以看到新式请求分发器use_new_dispatcher默认启用及max_in_flight_request_batches默认 20等参数都围绕请求并发管线设计本项优化即是在这一管线中减少全局锁的串行化点提升多请求并发吞吐。用条目数限制 Keeper 日志缓存大小Keeper 会将最新日志条目缓存在内存中以加速读路径此前仅通过内存字节上限latest_logs_cache_size_threshold默认 1 GiB约束。本次新增按条目数限制的配置项配置项默认值语义keeper_server.coordination_settings.latest_logs_cache_entry_count_threshold200,000最新日志条目内存缓存的最大条目数keeper_server.coordination_settings.commit_logs_cache_entry_count_threshold100,000已废弃无实际效果请改用log_readahead_commit_window_bytes源码定义见 src/Coordination/CoordinationSettings.cpp其中commit_logs_cache_entry_count_threshold已被明确标记为OBSOLETE废弃这说明它仅是出于向后兼容保留的占位参数实际配置提交日志预读窗口时应使用log_readahead_commit_window_bytes。缓存的实际构造在 src/Coordination/Changelog.cpp: latest_logs_cache(log_settings.latest_logs_cache_size_threshold, log_settings.latest_logs_cache_entry_count_threshold)即字节阈值与条目数阈值共同生效src/Coordination/KeeperStateManager.cpp 负责把配置透传给 Changelog两条限制同时满足才会停止缓存新条目。这一改动对内存压力较大的 Keeper 节点尤为重要单条日志条目内存开销不可控时仅靠字节上限可能仍缓存过多小条目增加条目数上限可避免缓存失控。修复 Keeper changelog 乱序写入导致的数据丢失风险这是本版本中 Keeper 方向最值得重视的修复backport #84648PR #84434此前 changelog 的写入可能存在 in-flight 并发写而回滚rollback操作可能并发修改目标文件导致日志不一致乃至数据丢失。修复后写入顺序得到保证消除了回滚与写入并发交织的窗口。对于依赖 Keeper 存放分布式 DDL 元数据、复制表协调信息的集群建议尽快升级到包含此修复的版本。其他 Keeper 修复与优化会话关闭时临时节点删除导致 watch 计数错误#83583修复 ephemeral 节点删除时总 watch 数统计不正确的问题总 watch 数返回不正确#84890修复wchs/mntr等命令汇报的 watch 总数RemoveRecursive 请求性能改进#86789优化递归删除节点的处理路径并在 Multi 请求中先检查特性开关#86554减少 Keeper 中的多余拷贝#85131降低请求处理路径的内存拷贝开销S3Queue 有序模式提前退出#84463收到 shutdown 信号后立即退出有序消费循环加快优雅停机system.distributed_ddl_queue容错#86848当部分任务缺少对应 Keeper 节点时不再查询失败KeeperMap 遗留数据清理#87112修复 25.1 之前创建的 KeeperMap 表在 DROP 后仍残留 ZooKeeper 数据的问题。内存管理cgroup 感知与内存追踪校正v25.3.7 将 cgroup 内存信息引入内存追踪memory tracker校正流程。新增/调整了以下服务端设置定义见 src/Core/ServerSettings.cppmemory_worker_use_cgroup默认true当容器环境存在 cgroup 且可用时使用当前 cgroup 的内存使用信息来校正内存追踪memory_worker_correct_memory_tracker默认false控制后台内存 worker 是否基于 jemalloc、cgroups 等外部来源校正内部 memory trackermemory_worker_period_ms默认 0自动取值后台内存 worker 的 tick 周期memory_worker_purge_dirty_pages_threshold_ratio默认 0.2、memory_worker_purge_total_memory_threshold_ratio默认 0.9触发 jemalloc dirty pages 强制清理的阈值。在容器化部署下ClickHouse 看到的宿主内存往往与 cgroup 配额不一致若不校正内存追踪可能失真进而导致 OOM 或被max_server_memory_usage错误限制。启用memory_worker_use_cgroup默认即开后后台内存 worker 以 cgroup 实际用量为准修正追踪值使硬限制检查更贴近容器真实内存水位。同方向的其他修复还包括estimateCompressionRatio()在block_size_bytes0时陷入死循环的问题#83704以及临时数据释放未计入max_temporary_data_on_disk_size限制的问题#87140。Web UI 与 Data Lake 集成改进Web UI 交互修复针对 Web UI 的两个体验问题PR #81131一是正确识别没有输出结果的查询如CREATE、INSERT此前这类查询会导致无限 spinner二是双击表名时自动滚动到页面顶部。这两项改进直接作用于programs/server中的嵌入式 Web 控制台资源低版本用户在浏览器端即可感知差异。show_data_lake_catalogs_in_system_tablesData Lake 目录可见性开关新增查询级设置show_data_lake_catalogs_in_system_tables默认false用于控制 Data Lake 目录是否出现在system.tables等系统表中。其定义位于 src/Core/Settings.cppDECLARE(Bool, show_data_lake_catalogs_in_system_tables, false, R( Enables showing data lake catalogs in system tables. ), 0) \该开关实际作用于多处系统表查询路径包括 src/Storages/System/StorageSystemTables.cpp、src/Storages/System/StorageSystemColumns.cpp 以及 src/Storages/System/StorageSystemCompletions.cpp通过.with_datalake_catalogs settings[Setting::show_data_lake_catalogs_in_system_tables]控制是否附带 Data Lake 目录信息在 src/Databases/DataLake/DatabaseDataLake.cpp 中同样受该设置约束。此外 src/Interpreters/DatabaseCatalog.cpp 显示当数据库是 Data Lake 目录isDatalakeCatalog()且该设置为 false 时会跳过对应的解析逻辑。实际含义是默认情况下 Data Lake 目录不会“污染”system.tables的枚举结果例如通过 Iceberg/Delta Lake 目录挂载的大量外部表需要查看时再显式开启。与之配套的还有show_remote_databases_in_system_tables默认true控制 MySQL/PostgreSQL 外部数据库在系统表中的可见性见 src/Core/Settings.cpp。查询正确性Analyzer 与执行引擎的密集修复25.3 系列默认启用新分析器Analyzer本版本围绕它修复了多个可能导致错误结果或逻辑错误的场景distributed_aggregation_memory_efficient与并行处理冲突#78500当开启distributed_aggregation_memory_efficient时禁用从FROM读取后立即并行处理查询的阶段否则可能触发逻辑错误LOGICAL ERRORJOIN 过滤下推导致NOT_FOUND_COLUMN_IN_BLOCK#80360当ON表达式不是平凡等值条件时逻辑 JOIN 的 filter-push-down 优化可能引用不存在的列本次一并修复了两个相关 issue#79647、#77848VIEW 二次查询全列读取的性能回退#83036启用分析器后子查询读取 VIEW 时会错误地总是读取全部列导致性能退化WITH 子句外层别名引用#83797引入向后兼容设置允许新分析器在名字冲突时引用 WITH 中的外层别名remote表函数view(...)参数限制#83844启用分析器后允许在view(...)中引用任意表additional_table_filters中的IN (subquery)#85210修复Not-ready Set问题避免子查询集合未就绪时被错误使用parallel replicas 反向顺序读取#85406并行副本使用 reverse order 优化读取时可能产生错误结果已修复PREWHERE 拆分为多步后输出未正确 cast#87040session_timezone下 datetime 键的错误分区/粒度消除#87987使用session_timezone设置时基于 datetime 的键可能错误地消除 granule/partition*Cluster函数去重判断改用collaborate_with_initiator#85734此前用distributed_depth判断是否来自 *Cluster 函数可能误判并导致数据重复现改用client_info.collaborate_with_initiator。存储引擎与类型系统修复MergeTree 家族TTL 全部移除后不应再做 TTL 相关工作#84441表的所有 TTL 被移除后MergeTree 不再执行任何 TTL 相关逻辑ALTER MODIFY ORDER BY校验 TTL 列#84536在排序键中使用 TTL 列会在 ALTER 期间被正确拒绝防止潜在的表损坏跳过索引 lambda 表达式无法应用#80025当索引定义中的高阶函数与查询中的函数完全匹配时跳过索引未被正确应用已修复无依赖建表不再检查循环依赖#83077修复创建数千张无依赖表时的性能退化该退化由较早的一次改动引入add_minmax_index_for_*与复制库初始化冲突#83751若以add_minmax_index_for_numeric_columns1或add_minmax_index_for_string_columns1建表索引在后续 ALTER 中物化可能阻止复制数据库Replicated database在新副本上正确初始化备份含损坏投影projection的 part#85362修复含损坏投影数据分区的备份失败问题。动态类型Dynamic / Variant / JSONClickHouse 的“半结构化”类型家族在本版本修复密集Dynamic 列解析失败时回滚#82169Variant 类型在 UNION 中可能崩溃#83295LowCardinality(Nullable(T))转 Dynamic 的 cast#86365ALTER UPDATENullable(JSON) 崩溃#86281JSON 中带 Enum 提示的路径默认值错误#86065RowBinary 写入 JSON 路径 NULL 值#83923以及 RowBinary 输入格式向 JSON 共享数据写 NULL 的校验#86812子列参与物化表达式时 ALTER UPDATE 未正确更新#85985禁止修改其子列被 PK 或分区表达式使用的列#86005。格式与外部数据Parquet 写入 Decimal 统计错误#83754修复 Decimal 类型 min/max 统计输出不正确Parquet offset index 行号错误#83876兼容设置output_format_parquet_date_as_uint16#85510将 Date 作为 UInt16 写入 Parquet 的兼容选项Avro schema registry 认证信息脱敏#83713含两次 revert/重新 backport#84195、#84212确保用户与日志中不暴露认证细节icebergS3Cluster / icebergAzureCluster 密钥脱敏#85658AzureIteratorAsync 双重释放#85064EmbeddedRocksDB 路径必须位于 user_files 内#87109并回退默认使用data/路径#87463。访问控制、复制与 DDLno_password用户登录崩溃#84426当服务器设置allow_no_password被改为 0 后以no_password创建的用户登录会导致服务器崩溃已修复Buffer 表 select/insert 访问校验#87545SYSTEM DROP REPLICA多余getStatus()调用#85220去掉不必要的调用避免表在后台删除时抛出Shutdown for storage is calledCREATE OR REPLACE / RENAME 表名长度校验#85326复制数据库Replicated database元数据校验放宽#80298对 RMT 执行更宽松的元数据检查CREATE ... AS (SELECT * FROM s3Cluster(...))配合 DatabaseReplicated 的逻辑错误#85904恢复数据库副本时正确关闭表#84744不当关闭会导致部分表引擎在副本恢复期间触发 LOGICAL_ERRORTimeSeries 引擎表阻止复制库创建新副本#86845异步删除的视图覆盖全局服务器设置#87603若视图被异步删除且服务器在后台清理完成前重启SELECT 设置可能错误覆盖全局服务器设置已修复system.tables读取外部数据库PostgreSQL/SQLite中无效表时的未捕获异常#88105。构建与测试改进PostgreSQL 测试镜像升级到 18.0#87647提升tests/integration中 PostgreSQL 相关集成测试对最新版本数据库的覆盖sccache 显式启动#83600在ninja构建阶段之前显式启动 sccache 服务器改善 CI 构建缓存命中率并发建表池自动扩容#83834当max_database_replicated_create_table_thread_pool_size0自动池大小时允许并发建表。升级建议与验证清单综合本版本的变更特征给出如下建议优先升级的场景重度使用 Keeper 的集群changelog 乱序写入、watch 计数、锁竞争等多项修复直接提升稳定性和数据安全性容器化部署并依赖精确内存追踪的实例cgroup 校正使用 Parquet 作为主要导出格式、以及使用 Dynamic/Variant/JSON 半结构化类型的业务多项错误结果与崩溃修复。升级后可执行的验证 SQL-- 验证 Data Lake 目录在系统表中的可见性开关 SHOW SETTINGS LIKE show_data_lake_catalogs_in_system_tables; SET show_data_lake_catalogs_in_system_tables 1; SELECT count() FROM system.tables; -- 验证内存相关设置 SHOW SETTINGS LIKE memory_worker%; -- 检查 Keeper 4LW 命令是否可用在 Keeper 节点执行 -- echo lgrq | nc keeper_host 9181Keeper 缓存参数按需调整若 Keeper 节点内存压力大可降低keeper_server.coordination_settings.latest_logs_cache_entry_count_threshold默认 200000与latest_logs_cache_size_threshold默认 1 GiB注意commit_logs_cache_entry_count_threshold已废弃配置提交日志预读请使用log_readahead_commit_window_bytes。以上所有结论均可在当前仓库对应源码路径中复现验证changelog 原文请参考 docs/changelogs/v25.3.7.194-lts.md。由于 changelog 头部带有 FIXME 标记个别条目在最终发布说明中可能略有调整建议以正式发布公告为准。【免费下载链接】ClickHouseClickHouse® is a real-time analytics database management system项目地址: https://gitcode.com/GitHub_Trending/cli/ClickHouse创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考