京公网安备11010502063487号本机真实对比Float64和Decimal64在单次和100万次累加下的精度差异，并诚实记录Decimal32加法容许超位数、乘法立刻报DECIMAL_OVERFLOW的不对称行为。
本机真实用toStartOfInterval做5分钟分桶并制造数据缺口，验证WITH FILL真实只补齐缺失的时间点位置，填充值是默认值0而非真正的插值。
本机真实对比argMax和两阶段子查询JOIN取每组最新记录，发现argMax更快却多耗约82%内存的反直觉结果，根源是聚合状态携带的是字符串还是数值。
本机真实对比count(DISTINCT)精确去重和uniq/uniqExact/uniqCombined/uniqHLL12四种函数，近似版省约154倍内存，四种算法的真实误差从0.29%到2.7%不等。
本机真实对比普通JOIN和Bitmap函数在两个百万级用户集合上求交集，Bitmap真实省约95倍内存、快约2倍，结果完全一致。
本机真实搭建3节点集群，插入100行数据后发现本地表行数相加(150)与Distributed汇总(100)不一致，揭示分片1的数据被完整复制到两个副本而非平分。
本机真实查system.clusters看清shard_num和replica_num是两个独立维度，混淆两者会导致对集群数据总量的错误理解。
本机真实用k本身作分片键插入数据，核对每个k值的分片落点，发现清一色的奇偶分布规律，并说明分片键设计需要匹配业务查询模式。
本机真实用EXPLAIN拆解跨分片GROUP BY的执行计划，看清两阶段聚合如何通过本地预聚合压缩跨节点传输的数据量。
本机真实用Distributed表JOIN只在单节点有数据的本地维度表，发现每个分片各用各的本地数据导致静默漏算，验证了修复方式。
本机真实对比普通IN和GLOBAL IN在数据分布不均时的行为差异，GLOBAL IN真实通过广播机制避开了与分布式JOIN同样的静默漏算问题。
本机真实只往一个副本插入1万行，另一个副本自动同步，核对part物理路径完全独立证明是网络拷贝而非共享存储，并揭示Keeper协调+HTTP传输的两层真实机制。