京公网安备11010502063487号本机真实用同一条撞爆内存的JOIN对比hash和grace_hash算法，200MB内存上限下hash失败而grace_hash真实通过分桶把内存需求降了约一半，成功完成。
本机真实对比dictGet、普通JOIN、direct算法三种字典查找方式，dictGet和direct都比普通JOIN省4~5倍内存，但真实发现省内存不等于更快，direct算法内存最省却耗时最长。
本机真实对比WHERE IN子查询和等价JOIN写法，IN子查询走CreatingSets专用Set结构更轻量，验证了两者是为不同目的设计的不同工具而非可随意互换的写法。
本机真实用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个物理文件的惊人复杂度。
本机真实验证@dataclass自动生成的__init__/__repr__/__eq__，两个字段相同的不同实例真实判定相等；再真实验证dataclass对可变默认值直接报ValueError拒绝。