禹鼎侯

做 ClickHouse 的存储与集群运维，主要场景是金融和信创。

这类环境有几个共同点：变更窗口是提前排期排出来的，出了事进不去现场，机器可能是 aarch64，网络大概率不通外网。所以判断标准和互联网侧不太一样 —— 确定性优先于最优性。一个边界清楚、能回滚的方案，比一个理论上更优但说不准的方案有用。

这不意味着可以不要性能。只是当两者冲突时，知道该放弃哪个。

版本升级，哪些地方会崩

ClickHouse 的行为变更很少上头条，但每一条都能让你在升级当晚多待三个小时。下面是几条已经踩实的 —— 完整清单在 版本升级避坑清单。

20.12background_fetches_pool_size 引入，此前 fetch 与 merge 共用线程池。默认值 3
21.2官方意识到 3 个线程在大数据量场景根本不够用，默认值提到 8
21.10replicated_max_parallel_fetches 废弃。网上还有大量资料在教人用它调 fetch 并发 —— 你可以设置，但没有任何效果
22.5从 profile 级升级为全局配置。改在旧位置不报错，只是不生效 —— 副本同步队列会一直堆，而你以为参数已经调过了
23.4formatDateTime 的 %M 从「分钟」变成「月份名」，分钟改用 %i。查询照常返回 —— 只是 22:49:16 会输出成 22:December:16。有开关能拨回去，藏在源码里
23.3skip_access_check 作用域收窄。依赖它在 S3 不可达时把服务救起来的手法，升级后失效
24.8async_load_databases 默认开启。进程起了、端口通了、探活绿了 —— 一查表报错。「起来了」不等于「可用了」
23.11官方认为 8 仍偏小，background_fetches_pool_size 默认值改为 16。三次调整（3 → 8 → 16）说明它本就没有普适最优解
26.3 → 26.4text index 的 unicode_word 在发布次日被改名。26.3 建的索引在 26.4 打不开，而且连 DROP INDEX 都执行不了 —— 表进去就出不来

OPTIMIZE TABLE 不解决 too many parts，而且通常会加剧。

too many parts 判定的是 part 的数量，OPTIMIZE 优化的是数据组织 —— 它会挑最大的那些 part 去合并，长任务占满线程池槽位，真正造成问题的小 part 反而排不上队。

改了不生效，先别问「为什么不生效」，先问「它到底生效了没有」。

前者是个开放问题，后者是个能查的问题。ClickHouse 的 settings 散在 system.settings、system.server_settings、system.merge_tree_settings 几张表里，不确定就都查一遍。

副本不是备份。

ReplicatedMergeTree 防的是节点故障，防不了误删和逻辑错误。这是从 Oracle 迁过来的团队最常见的认知盲区。

更多条目在 Field Notes。

这里写的都是自己踩过的：能复现的给命令，不能复现的说清楚边界，判断错的地方也留着不删。