ClickHouse v25.7.3.13-stable 版本技术解析TTL 排序键校验、副本表 Patch Part 清理与查询优化【免费下载链接】ClickHouseClickHouse® is a real-time analytics database management system项目地址: https://gitcode.com/GitHub_Trending/cli/ClickHouse本文以 ClickHouse v25.7.3.13-stable 的官方变更记录docs/changelogs/v25.7.3.13-stable.md为主体逐条解读该版本相较 v25.7.2.54-stable 引入的 4 项用户可见缺陷修复与 1 项内部优化并结合仓库源码说明每项修复落在哪些模块。读完后你将了解ALTER MODIFY ORDER BY 场景下 TTL 列校验的触发位置、ReplicatedMergeTree 轻量更新产生的 patch part 的清理机制、物化视图与additional_table_filters设置相关的两处行为修正从而判断当前生产环境是否需要升级到该补丁版本以及升级后如何验证修复生效。版本概览该条目记录的是 7 系稳定线的热修复hotfix发布基线版本为 v25.7.2.54-stable发布标识为提交47579ad7fd6。变更全部为 Bug Fix官方稳定版中用户可见的错误行为以及一条标记为 “NOT FOR CHANGELOG / INSIGNIFICANT” 的内部改进。由于 25.7 是稳定的长期支持线这类逐条 backport 的补丁版本对生产环境意义重大——每条修复都对应一个真实的故障场景。以下逐条展开。修复一ALTER MODIFY ORDER BY 未校验 TTL 列可能引发数据损坏原始描述修复ALTER MODIFY ORDER BY未校验排序键中 TTL 列的问题。TTL 列现在会在 ALTER 操作中被正确地拒绝防止潜在的表损坏。对应 issue #85306修复 PR #84536作者 xiaohuanlin。为什么这是一个严重问题MergeTree 族的 TTL 机制在 merge 阶段会按 TTL 规则丢弃或移动行如果表定义了针对某些列的 TTL而这些列之后又被允许通过ALTER TABLE ... MODIFY ORDER BY移入排序键merge 调度与 TTL 执行之间会产生冲突轻则行为异常重则出现 changelog 中明确指出的“表损坏table corruption”风险。这是一个典型的 DDL 校验缺口CREATE 表时相关约束能被拦下但 ALTER 路径漏了同样的校验。源码印证TTL 校验函数的实际落点从源码结构看该校验集中在checkTTLExpressions这一静态函数上定义于 MergeTreeData.cpp声明在 MergeTreeData.h。它在三条路径上被调用新建表时MergeTreeData.cpp 初始化元数据时校验自身ALTER 时MergeTreeData.cpp 以及 StorageMergeTree.cpp 的元数据变更流程中对新旧两版元数据成对校验副本表 ALTER 时StorageReplicatedMergeTree.cpp 单独再走一次。值得一提的是 StorageMergeTree.cpp 中的提交顺序设计TTL 表达式校验第 642 行checkTTLExpressions发生在持久化元数据提交alterTable之前的验证阶段并且与changeSettings合并在同一个 try 块中——任何一步抛异常都会回滚 settings、由PreparedMutationEntry析构清理未注册的mutation_*.txt文件。这保证了“校验失败”绝不会留下已提交但内存中不一致的元数据状态。升级到该版本后把 TTL 列写进新的 ORDER BY 的ALTER语句会在这一层被直接拒绝。验证方法升级后-- 建一张带 TTL 的表 CREATE TABLE ttl_order_test ( dt Date, id UInt64 ) ENGINE MergeTree ORDER BY dt TTL dt INTERVAL 1 MONTH; -- 升级前可能通过升级后应报错拒绝TTL 列 dt 出现在新排序键中 ALTER TABLE ttl_order_test MODIFY ORDER BY (dt, id);修复二ReplicatedMergeTree 中 patch part 的清理导致副本短暂不可见原始描述修复ReplicatedMergeTree中 patch part 的清理逻辑。此前一次轻量更新lightweight update的结果可能在一段时间内对副本不可见——直到物化materialize这些 patch part 的 merged 或 mutated part 从其他副本下载完成。对应 issue #85381修复 PR #85121作者 Anton Popov。背景轻量更新与 patch partClickHouse 的轻量更新ALTER TABLE ... UPDATE ...的轻量变体即lightweight update不立即重写整个 part而是把修改记录为 patch part由后续的 merge/mutation 将其物化为常规 part。在副本表场景下part 之间通过日志Keeper/ZooKeeper log同步副本侧对 patch part 的可见性依赖其生命周期管理与清理时序。故障机理原缺陷的时序问题在于当某个副本对包含 patch part 的 part 执行了清理cleanup时如果物化该 patch part 的 merged/mutated part 尚未从其他副本下载完毕查询会读不到刚才轻量更新的写入结果——表现为“更新成功了但副本上查不到”的窗口期不一致。修复后清理逻辑保证了 patch part 在其物化结果本地可读之前不会被提前清掉消除了这一可见性空窗。从源码结构看patch part 的概念贯穿 MergeTree 核心模块PatchPart类型与patch_parts管理分布在 IMergeTreeDataPart.h、ActiveDataPartSet.cpp、MergeTreeCleanupThread.cpppart 清理线程以及 MergeTask.cppmerge 时的 patch 物化等文件中。本修复涉及的正是清理线程与副本同步FetchPart/log 消费之间的时序判断。适用提示如果你的业务大量使用lightweight update并依赖副本表多副本读一致性该修复直接消除了一类“偶发读旧值”现象属于建议尽快升级的修复。修复三物化视图在不同类型下的 illegal_type_of_argument 报错原始描述修复 MV物化视图中类型不同导致的illegal_type_of_argument报错。对应 issue #85246修复 PR #85135作者 Sema Checherinda。该修复针对的是物化视图刷新链路当源表source table与目标表target table中同名列的类型不完全一致时物化视图内部生成的 INSERT SELECT 表达式在参数类型检查上会误报illegal_type_of_argument。修复后类型不匹配的处理路径更宽松、更符合隐式转换语义。这类问题的排查入口在物化视图的刷新报错日志修复属于“行为修正”而非新功能——从源码结构看函数参数类型解析集中在 Functions 目录如resolveFunction相关路径而 MV 的刷新由 MergeTree 的storage_id关联任务驱动。验证方法构造源表列类型为UInt64、目标表同名列类型为Int64的物化视图插入数据后观察刷新不再抛illegal_type_of_argument。修复四additional_table_filters中 IN (子查询) 的 “Not-ready Set” 报错原始描述修复additional_table_filters表达式设置中IN (subquery)场景下的Not-ready Set报错。对应 issue #85236修复 PR #85210作者 Nikolai Kochetov。这个设置是什么additional_table_filters是一个服务端/查询级设置用于对查询中访问的表附加额外的过滤表达式典型用途是行级过滤row-level filtering或强制追加业务谓词。该设置定义于 Settings.cpp并在 InterpreterSelectQuery.cpp、QueryTreeBuilder.cpp 与 PlannerJoinTree.cpp 等解析/计划路径中被读取和消费。故障机理“Not-ready Set” 是执行引擎中 Set 类中间结果的占位状态——当执行计划中某个 Set 对象尚未由上游步骤填充、而被下游谓词提前引用时就会抛出该异常。此前若用户在additional_table_filters表达式里写了IN (SELECT ...)形式子查询的 Set 在执行顺序上未被正确排序/等待导致执行期访问了未就绪的 Set。修复后此类过滤表达式与子查询的依赖关系被正确建立。验证方法升级后应不再报错-- 假设服务端配置中设置了 additional_table_filters -- 对表 t 追加了 IN (subquery) 形式的过滤表达式 SET additional_table_filters (tenant_id IN (SELECT id FROM tenants)); SELECT * FROM t; -- 升级前可能报 Not-ready Set升级后正常执行修复五SYSTEM DROP REPLICA 期间多余的 getStatus() 调用原始描述在SYSTEM DROP REPLICA查询执行期间去掉了不必要的getStatus()调用修复了表在后台被 DROP 时抛出Shutdown for storage is called异常的场景。对应 issue #85264修复 PR #85220作者 Nikolay Degterinsky。该问题发生在副本表副本元数据维护与表生命周期叠加的竞态窗口SYSTEM DROP REPLICA的内部执行路径反复调用 storage 状态检查恰逢该表正在后台执行 DROP TABLE 流程storage 已进入 shutdown 阶段状态检查随即抛出Shutdown for storage is called。修复方式是精简掉冗余的状态轮询缩短甚至消除该竞态窗口。这与StorageReplicatedMergeTree的副本注册/注销流程StorageReplicatedMergeTree.cpp相关。影响面在集群中执行副本运维操作摘除副本、下线节点同时又有后台删表任务并行时运维脚本不会再被该异常打断。内部改进Keeper 中避免部分拷贝原始描述NOT FOR CHANGELOG / INSIGNIFICANT不面向用户发布避免 Keeper 中的一些拷贝。对应 issue #85284PR #85131作者 Antonio Andelic。Keeper 是 ClickHouse 内置的协调服务ZooKeeper 替代实现其源码位于 Coordination 目录。这条属于内存效率层面的内部清理不改变任何外部行为但对高频协调操作场景可减少不必要的内存分配与复制。列在这里是为了让版本说明完整——它在官方 changelog 中被标记为“不显著”用户无需为此升级但升级后它随版本一起生效。升级与回归验证建议综合以上五条变更给出可操作的升级判断与验证清单是否需要升级到 v25.7.3.13-stable只要生产上存在「带 TTL 的 MergeTree 表 MODIFY ORDER BY」运维操作或「副本表 lightweight update」组合就建议升级——这两条分别堵住数据损坏风险和副本读一致性空窗使用additional_table_filters做行级过滤且过滤条件含子查询的部署也应升级以消除Not-ready Set报错。升级前确认当前版本SELECT version(), revision FROM system.build_info;升级后回归验证要点复现各修复对应的失败语句本文各节的验证方法确认报错消失检查system.mutations与副本表 part 状态确认 patch part 物化链路正常SELECT database, table, is_active, type, all_entries_done FROM system.mutations ORDER BY create_time DESC LIMIT 10;适用前提与限制本文所有结论基于当前仓库中 25.7 稳定线的源码结构TTL 校验调用点、patch part 相关模块、additional_table_filters设置的定义与消费路径修复的具体提交细节以官方 changelog 条目与 PR #84536、#85121、#85135、#85210、#85220、#85131 的变更为准跨大版本如从 25.3 直升 25.7.x时还应参照仓库 docs/changelogs 目录下各版本的变更记录逐版本核对。小结v25.7.3.13-stable 是一个以“堵住真实故障”为目标的热修复版本两条修复TTL 排序键校验、patch part 清理时序直接关系数据安全与副本一致性两条修复MV 类型报错、additional_table_filters子查询消除的是查询/DDL 链路上的误报与误拒一条内部改进则优化了 Keeper 的内存行为。理解这些修复对应的源码落点checkTTLExpressions的三处调用、清理线程与副本同步的时序、执行计划中 Set 的就绪顺序能帮助你更准确地评估升级收益与验证修复是否生效。【免费下载链接】ClickHouseClickHouse® is a real-time analytics database management system项目地址: https://gitcode.com/GitHub_Trending/cli/ClickHouse创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
ClickHouse v25.7.3.13-stable 版本技术解析：TTL 排序键校验、副本表 Patch Part 清理与查询优化
ClickHouse v25.7.3.13-stable 版本技术解析TTL 排序键校验、副本表 Patch Part 清理与查询优化【免费下载链接】ClickHouseClickHouse® is a real-time analytics database management system项目地址: https://gitcode.com/GitHub_Trending/cli/ClickHouse本文以 ClickHouse v25.7.3.13-stable 的官方变更记录docs/changelogs/v25.7.3.13-stable.md为主体逐条解读该版本相较 v25.7.2.54-stable 引入的 4 项用户可见缺陷修复与 1 项内部优化并结合仓库源码说明每项修复落在哪些模块。读完后你将了解ALTER MODIFY ORDER BY 场景下 TTL 列校验的触发位置、ReplicatedMergeTree 轻量更新产生的 patch part 的清理机制、物化视图与additional_table_filters设置相关的两处行为修正从而判断当前生产环境是否需要升级到该补丁版本以及升级后如何验证修复生效。版本概览该条目记录的是 7 系稳定线的热修复hotfix发布基线版本为 v25.7.2.54-stable发布标识为提交47579ad7fd6。变更全部为 Bug Fix官方稳定版中用户可见的错误行为以及一条标记为 “NOT FOR CHANGELOG / INSIGNIFICANT” 的内部改进。由于 25.7 是稳定的长期支持线这类逐条 backport 的补丁版本对生产环境意义重大——每条修复都对应一个真实的故障场景。以下逐条展开。修复一ALTER MODIFY ORDER BY 未校验 TTL 列可能引发数据损坏原始描述修复ALTER MODIFY ORDER BY未校验排序键中 TTL 列的问题。TTL 列现在会在 ALTER 操作中被正确地拒绝防止潜在的表损坏。对应 issue #85306修复 PR #84536作者 xiaohuanlin。为什么这是一个严重问题MergeTree 族的 TTL 机制在 merge 阶段会按 TTL 规则丢弃或移动行如果表定义了针对某些列的 TTL而这些列之后又被允许通过ALTER TABLE ... MODIFY ORDER BY移入排序键merge 调度与 TTL 执行之间会产生冲突轻则行为异常重则出现 changelog 中明确指出的“表损坏table corruption”风险。这是一个典型的 DDL 校验缺口CREATE 表时相关约束能被拦下但 ALTER 路径漏了同样的校验。源码印证TTL 校验函数的实际落点从源码结构看该校验集中在checkTTLExpressions这一静态函数上定义于 MergeTreeData.cpp声明在 MergeTreeData.h。它在三条路径上被调用新建表时MergeTreeData.cpp 初始化元数据时校验自身ALTER 时MergeTreeData.cpp 以及 StorageMergeTree.cpp 的元数据变更流程中对新旧两版元数据成对校验副本表 ALTER 时StorageReplicatedMergeTree.cpp 单独再走一次。值得一提的是 StorageMergeTree.cpp 中的提交顺序设计TTL 表达式校验第 642 行checkTTLExpressions发生在持久化元数据提交alterTable之前的验证阶段并且与changeSettings合并在同一个 try 块中——任何一步抛异常都会回滚 settings、由PreparedMutationEntry析构清理未注册的mutation_*.txt文件。这保证了“校验失败”绝不会留下已提交但内存中不一致的元数据状态。升级到该版本后把 TTL 列写进新的 ORDER BY 的ALTER语句会在这一层被直接拒绝。验证方法升级后-- 建一张带 TTL 的表 CREATE TABLE ttl_order_test ( dt Date, id UInt64 ) ENGINE MergeTree ORDER BY dt TTL dt INTERVAL 1 MONTH; -- 升级前可能通过升级后应报错拒绝TTL 列 dt 出现在新排序键中 ALTER TABLE ttl_order_test MODIFY ORDER BY (dt, id);修复二ReplicatedMergeTree 中 patch part 的清理导致副本短暂不可见原始描述修复ReplicatedMergeTree中 patch part 的清理逻辑。此前一次轻量更新lightweight update的结果可能在一段时间内对副本不可见——直到物化materialize这些 patch part 的 merged 或 mutated part 从其他副本下载完成。对应 issue #85381修复 PR #85121作者 Anton Popov。背景轻量更新与 patch partClickHouse 的轻量更新ALTER TABLE ... UPDATE ...的轻量变体即lightweight update不立即重写整个 part而是把修改记录为 patch part由后续的 merge/mutation 将其物化为常规 part。在副本表场景下part 之间通过日志Keeper/ZooKeeper log同步副本侧对 patch part 的可见性依赖其生命周期管理与清理时序。故障机理原缺陷的时序问题在于当某个副本对包含 patch part 的 part 执行了清理cleanup时如果物化该 patch part 的 merged/mutated part 尚未从其他副本下载完毕查询会读不到刚才轻量更新的写入结果——表现为“更新成功了但副本上查不到”的窗口期不一致。修复后清理逻辑保证了 patch part 在其物化结果本地可读之前不会被提前清掉消除了这一可见性空窗。从源码结构看patch part 的概念贯穿 MergeTree 核心模块PatchPart类型与patch_parts管理分布在 IMergeTreeDataPart.h、ActiveDataPartSet.cpp、MergeTreeCleanupThread.cpppart 清理线程以及 MergeTask.cppmerge 时的 patch 物化等文件中。本修复涉及的正是清理线程与副本同步FetchPart/log 消费之间的时序判断。适用提示如果你的业务大量使用lightweight update并依赖副本表多副本读一致性该修复直接消除了一类“偶发读旧值”现象属于建议尽快升级的修复。修复三物化视图在不同类型下的 illegal_type_of_argument 报错原始描述修复 MV物化视图中类型不同导致的illegal_type_of_argument报错。对应 issue #85246修复 PR #85135作者 Sema Checherinda。该修复针对的是物化视图刷新链路当源表source table与目标表target table中同名列的类型不完全一致时物化视图内部生成的 INSERT SELECT 表达式在参数类型检查上会误报illegal_type_of_argument。修复后类型不匹配的处理路径更宽松、更符合隐式转换语义。这类问题的排查入口在物化视图的刷新报错日志修复属于“行为修正”而非新功能——从源码结构看函数参数类型解析集中在 Functions 目录如resolveFunction相关路径而 MV 的刷新由 MergeTree 的storage_id关联任务驱动。验证方法构造源表列类型为UInt64、目标表同名列类型为Int64的物化视图插入数据后观察刷新不再抛illegal_type_of_argument。修复四additional_table_filters中 IN (子查询) 的 “Not-ready Set” 报错原始描述修复additional_table_filters表达式设置中IN (subquery)场景下的Not-ready Set报错。对应 issue #85236修复 PR #85210作者 Nikolai Kochetov。这个设置是什么additional_table_filters是一个服务端/查询级设置用于对查询中访问的表附加额外的过滤表达式典型用途是行级过滤row-level filtering或强制追加业务谓词。该设置定义于 Settings.cpp并在 InterpreterSelectQuery.cpp、QueryTreeBuilder.cpp 与 PlannerJoinTree.cpp 等解析/计划路径中被读取和消费。故障机理“Not-ready Set” 是执行引擎中 Set 类中间结果的占位状态——当执行计划中某个 Set 对象尚未由上游步骤填充、而被下游谓词提前引用时就会抛出该异常。此前若用户在additional_table_filters表达式里写了IN (SELECT ...)形式子查询的 Set 在执行顺序上未被正确排序/等待导致执行期访问了未就绪的 Set。修复后此类过滤表达式与子查询的依赖关系被正确建立。验证方法升级后应不再报错-- 假设服务端配置中设置了 additional_table_filters -- 对表 t 追加了 IN (subquery) 形式的过滤表达式 SET additional_table_filters (tenant_id IN (SELECT id FROM tenants)); SELECT * FROM t; -- 升级前可能报 Not-ready Set升级后正常执行修复五SYSTEM DROP REPLICA 期间多余的 getStatus() 调用原始描述在SYSTEM DROP REPLICA查询执行期间去掉了不必要的getStatus()调用修复了表在后台被 DROP 时抛出Shutdown for storage is called异常的场景。对应 issue #85264修复 PR #85220作者 Nikolay Degterinsky。该问题发生在副本表副本元数据维护与表生命周期叠加的竞态窗口SYSTEM DROP REPLICA的内部执行路径反复调用 storage 状态检查恰逢该表正在后台执行 DROP TABLE 流程storage 已进入 shutdown 阶段状态检查随即抛出Shutdown for storage is called。修复方式是精简掉冗余的状态轮询缩短甚至消除该竞态窗口。这与StorageReplicatedMergeTree的副本注册/注销流程StorageReplicatedMergeTree.cpp相关。影响面在集群中执行副本运维操作摘除副本、下线节点同时又有后台删表任务并行时运维脚本不会再被该异常打断。内部改进Keeper 中避免部分拷贝原始描述NOT FOR CHANGELOG / INSIGNIFICANT不面向用户发布避免 Keeper 中的一些拷贝。对应 issue #85284PR #85131作者 Antonio Andelic。Keeper 是 ClickHouse 内置的协调服务ZooKeeper 替代实现其源码位于 Coordination 目录。这条属于内存效率层面的内部清理不改变任何外部行为但对高频协调操作场景可减少不必要的内存分配与复制。列在这里是为了让版本说明完整——它在官方 changelog 中被标记为“不显著”用户无需为此升级但升级后它随版本一起生效。升级与回归验证建议综合以上五条变更给出可操作的升级判断与验证清单是否需要升级到 v25.7.3.13-stable只要生产上存在「带 TTL 的 MergeTree 表 MODIFY ORDER BY」运维操作或「副本表 lightweight update」组合就建议升级——这两条分别堵住数据损坏风险和副本读一致性空窗使用additional_table_filters做行级过滤且过滤条件含子查询的部署也应升级以消除Not-ready Set报错。升级前确认当前版本SELECT version(), revision FROM system.build_info;升级后回归验证要点复现各修复对应的失败语句本文各节的验证方法确认报错消失检查system.mutations与副本表 part 状态确认 patch part 物化链路正常SELECT database, table, is_active, type, all_entries_done FROM system.mutations ORDER BY create_time DESC LIMIT 10;适用前提与限制本文所有结论基于当前仓库中 25.7 稳定线的源码结构TTL 校验调用点、patch part 相关模块、additional_table_filters设置的定义与消费路径修复的具体提交细节以官方 changelog 条目与 PR #84536、#85121、#85135、#85210、#85220、#85131 的变更为准跨大版本如从 25.3 直升 25.7.x时还应参照仓库 docs/changelogs 目录下各版本的变更记录逐版本核对。小结v25.7.3.13-stable 是一个以“堵住真实故障”为目标的热修复版本两条修复TTL 排序键校验、patch part 清理时序直接关系数据安全与副本一致性两条修复MV 类型报错、additional_table_filters子查询消除的是查询/DDL 链路上的误报与误拒一条内部改进则优化了 Keeper 的内存行为。理解这些修复对应的源码落点checkTTLExpressions的三处调用、清理线程与副本同步的时序、执行计划中 Set 的就绪顺序能帮助你更准确地评估升级收益与验证修复是否生效。【免费下载链接】ClickHouseClickHouse® is a real-time analytics database management system项目地址: https://gitcode.com/GitHub_Trending/cli/ClickHouse创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
