京公网安备11010502063487号本机真实对300万行表只更新1/3数据，用part文件名和字节数变化证明ALTER UPDATE是整part重写而非原地patch，即使部分part可能完全不含命中条件的行也照样重写。
本机真实对比DELETE FROM(lightweight)和ALTER TABLE DELETE(mutation)，用system.parts的真实行数元数据证明前者只打掩码不改物理数据，后者才真正物理重写。
本机真实插入带TTL的数据，全程不手动触发任何操作，观察到后台任务在5秒内自动完成了过期数据的物理清理，证明TTL清理有真实的延迟窗口而非立即发生。
本机真实对比多线程(10核)和单线程GROUP BY在2000万行上的耗时，测出约1.5~2倍加速比，结合本系列已验证的向量化执行和列式存储机制说明聚合快的真实根本原因。
本机真实对比低基数和高基数GROUP BY的profile事件，途中发现老资料的事件名已过时，找到本机版本真实生效的AggregationConvertedToTwoLevel和AdaptiveAggregation新机制。
本机真实用AggregatingMergeTree存avgState中间状态，验证跨part合并的正确性，并对比avg与quantile两种聚合函数state体积相差5465倍的真实差异。
本机真实建一张3000万行、极端高基数(全部唯一)的表，触发GROUP BY内存超限报错，并测出默认设置下真实用了约1.02GB内存，约34字节/分组。
本机真实开启external_group_by落盘阈值，把同一条GROUP BY的内存从1.02GB降到290MB，并验证内存预算给得不够时会在聚合阶段或读回归并阶段分别真实报错。
本机真实尝试用多组配置触发ORDER BY落盘，诚实记录未能复现出像External Group By那样清晰的落盘证据，只用EXPLAIN PIPELINE确认了真实的排序执行节点。
本机真实对比精确TopK和近似topK()函数，内存相差565倍，但诚实展示了头部访问量势均力敌时近似算法给出不同排名的真实代价。
本机真实EXPLAIN一条JOIN看到join_algorithm是优先级列表，默认选中SpillingHashJoin，并意外测出partial_merge在已排序表上比hash快且省10倍内存。
本机真实让一张500万行大payload的表做hash JOIN右表，触发FillingRightJoinSide阶段的内存超限报错，验证内存开销真实只跟右表大小成正比。