HDB抽取的表与原表内容一致，为何布尔匹配返回0b而非1b？

这个问题在KDB+的日常使用里挺常见的，主要是几个容易忽略的细节导致的：

1. 表结构不一致：自动新增的date列 #

看你的代码就能发现，最初创建的trade表是没有date列的：

trade:trade2:`sym`time xasc ([] sym:5?`apple`google;time:5?.z.t;price:100+5?1.)

但用.Q.dpft写入HDB时，你指定了分区日期.z.d-1，KDB+会自动给HDB中的表加上date列作为分区键。之后从HDB查询出的hist表包含date列，而内存里的原trade表没有这一列——表的列数、列结构都不一样，直接做整表布尔匹配（比如trade~hist）自然会返回0b。

2. 浮点数的隐形精度差异 #

你的price列是用100+5?1.生成的浮点数，这类数值在内存中是二进制存储的。写入HDB再读取回来后，虽然打印出来的数值看起来完全一致，但底层可能因为存储/读取的二进制精度问题，存在极其细微的差异（比如小数点后第15位的不同）。KDB+的布尔匹配是精确匹配，哪怕是极微小的浮点数差异都会导致匹配失败。

3. 时间列的潜在精度损耗 #

time列用.z.t生成的是timespan类型，虽然KDB+对时间类型的精度支持很好，但在部分场景下（比如旧版本KDB+的HDB存储），写入再读取后可能会出现微秒级的精度截断，导致内存中的时间值和HDB读取的时间值存在细微不同，这也会让整表匹配失败。

快速验证方法 #

你可以通过以下方式确认问题：

• 用meta trade和meta hist对比列结构，会明显看到hist多了date列；
• 逐行对比price列：trade.price ~ hist.price，大概率会看到个别值返回0b；
• 同样检查time列：trade.time ~ hist.time，也可能存在不匹配的情况。

解决思路 #

• 如果只需要匹配核心数据，手动指定对比的列：select sym,time,price from trade ~ select sym,time,price from hist；
• 对于浮点数，用近似匹配替代精确匹配：abs[trade.price - hist.price] < 1e-12，忽略微小精度差异；
• 确保两张表的列结构完全一致后再做整表匹配。

内容的提问来源于stack exchange，提问作者nyi