一次讲透
挑一个 ClickHouse 的功能，或者一类反复碰到的问题，从它内部怎么运作，一直讲到生产上的边界在哪。
和官方文档的分界
官方文档告诉你一个参数叫什么。这一栏想讲的是它的默认值为什么是这个，什么时候会反咬你一口，到了什么规模它就不成立了。
怎么用就不写了，那部分官方文档比我写得全，也比我更新得快。
一个话题一篇，不拆
栏目叫一次讲透，拆成六篇就是自己打自己的脸。
代价是单页很长，字典那篇一万五千字。右边的目录就是为这个准备的，这类文章本来也不是让人从头读到尾的，是等你真撞上问题的时候，直接跳到那一节去看。
和别的栏目的分界
这几栏都会往深里讲，区别在于从哪儿起头：
排障篇受事故的限制，只能讲到踩中的那一块；这边可以整个摊开讲，反过来也能给排障篇做个背书。
像 Too many parts 这种，不是哪一次事故的复盘，是这些年被问了太多遍攒出来的，所以放在这一栏。
版本
行为会随版本变。文章里凡是某个版本起才这样的，都标了版本号；读源码得出来的，标了位置；没实测过的，会说一句是推断。
文章
Too many parts：merge 追不上写入的时候改上限是自欺欺人，OPTIMIZE 是饮鸩止渴。能做的只有两件事：少产生 part，让 merge 跑得动。Too many partitions：和 Too many parts 一词之差，处理方式截然相反一个要把 batch 调大，一个要把 batch 调小。临时导入可以放宽上限，常态写入不行。同一条 SQL 每次查出来不一样：先看它是怎么变的表引擎用错、副本同步延迟、去重引擎没加 FINAL、TTL，四种原因看结果怎么变就能分开。FINAL 查询为什么慢：两种提速办法，各自会把结果改错显式 PREWHERE 快 9 倍，但会把被覆盖的旧数据捞回来；禁止跨分区 merge 快 17 倍，但同一个 key 跨了分区就漏去重。26.3.3 上逐条验过。ReplacingMergeTree 去重的坑：单机 demo 好使，上集群是另一回事去重要生效，得同一 key 的所有版本落在同一节点同一分区再赶上 merge。sharding 键、分区键、版本列、resharding、副本进度，全是围着这一条的设计义务。物化视图：三种机制，以及 100T 表上的 POPULATE传统 MV、TO TABLE、Refreshable 到底差在哪，大表怎么选，回填、修数据和 schema 演化怎么做。字典：省掉的 JOIN，多付的内存刷新时 2.2~2.5 倍的内存尖刺、LAYOUT 怎么选，以及到了什么规模就不该再用字典。text 索引的 GRANULARITY：写了 1，为什么变成一亿SQL 解析时就改了。倒排索引按整个 part 组织，靠 posting list 定位候选行；26.3.3.20 实测元数据，源码追到布局约束。到底要不要写 UDFSQL、Executable、WASM 三种形态性能差着一个数量级，而大多数「需要 UDF」的场景其实用不着。副本表 readonly：什么时候等它自愈，什么时候该重建元数据所有表一起 readonly 是 Keeper 的事，别碰表；少数表不自愈才是元数据的事。restore 以幸存副本为准，本地多出来的 part 会被直接删掉，动手前先捞数据。