禹鼎侯

做 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.3skip_access_check 作用域收窄。依赖它在 S3 不可达时把服务救起来的手法，升级后失效
23.4formatDateTime 的 %M 从「分钟」变成「月份名」，分钟改用 %i。查询照常返回，只是 22:49:16 会输出成 22:December:16。有开关能拨回去，藏在源码里
23.11官方认为 8 仍偏小，background_fetches_pool_size 默认值改为 16。三次调整（3 → 8 → 16），说明它本来就没有一个普适的最优值
24.6async_load_databases 默认开启。进程起了、端口通了、探活绿了，一查表还是报错
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。