京公网安备11010502063487号本机真实用sleepEachRow验证子查询执行次数，发现WITH和手写重复子查询耗时几乎相同，真相是公共子表达式消除只认文本是否完全相同，与WITH语法本身无关。
本机真实验证物化视图对创建前历史数据完全不自动回填，并说明它真实的加速原理是把计算提前分摊到写入时，减少查询要读取的数据量。
本机真实给按k排序的2000万行表加一个按cat排序的Projection，验证同样的过滤查询read_rows从2000万降到4.9万，降约407倍，且对业务SQL完全透明。
本机真实测试Date类型的边界，发现超出1970~2149范围的日期不报错而是静默钳制到边界值，并说明四种日期时间类型2~8字节的存储成本与范围/精度取舍。
本机真实对比Nullable列和普通列的物理磁盘文件，纠正存储膨胀的常见误解——额外代价不到0.1%，真实的性能影响在于每次访问都要多一次null-mask判断。
本机真实用columns_substreams.txt精确核对Array/Tuple/Map三种复合类型在磁盘上的物理拆分，4个逻辑列真实对应10个物理文件，Map真实被当成Array(Tuple)处理。
本机真实对比Nested类型和3个独立Array列，发现Nested的子列真实共享同一个长度文件，从存储层面提供了独立Array做不到的逐行等长保证。
本机真实插入两条结构不同的JSON文档到原生JSON类型列，用columns_substreams.txt揭示1个JSON列、2行数据就真实产生了47个物理文件的惊人复杂度。
本机真实起一个 ClickHouse 26.9 单节点：200 次单行 INSERT 真实耗时 23.6 秒且产生大量 part，同样 200 行一次批量 INSERT 只要 0.14 秒；再用 ALTER TABLE UPDATE 验证一次更新真实是怎样的异步 mutation。
本机真实建一张 50 列的宽表，只查 1 列 vs 查全部 50 列，用 system.query_log 里真实的 read_bytes 数字看列存到底省在哪，以及为什么 length() 比 SELECT * 读得更少。
用 EXPLAIN AST / EXPLAIN PLAN / EXPLAIN PIPELINE 加 system.query_log，真实拆开同一条 SQL 从解析、生成执行计划、拼成处理器流水线到真正执行的每一步。
在本机 2000 万行的真实表上，把 max_block_size 从 1 调到默认的 65505，同一条聚合查询真实耗时从 32.8 秒降到 0.09 秒，361 倍的差距全部来自一行一行处理还是一批一批处理。