京公网安备11010502063487号本机真实对比多线程(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阶段的内存超限报错，验证内存开销真实只跟右表大小成正比。
本机真实用同一条撞爆内存的JOIN对比hash和grace_hash算法，200MB内存上限下hash失败而grace_hash真实通过分桶把内存需求降了约一半，成功完成。
本机真实对比dictGet、普通JOIN、direct算法三种字典查找方式，dictGet和direct都比普通JOIN省4~5倍内存，但真实发现省内存不等于更快，direct算法内存最省却耗时最长。
本机真实对比WHERE IN子查询和等价JOIN写法，IN子查询走CreatingSets专用Set结构更轻量，验证了两者是为不同目的设计的不同工具而非可随意互换的写法。