概括一下您所提到的问题：
- probe 端只有 1 行数据
- 随着 build 端的增大，会开始触发 hashjoin 的落盘行为
- 但即便存在落盘，随着 build 的不断增大，仍然会出现 query 内存超限而被 cancel 掉的情况
我抓了下过程中的 heap profile，确实如您所分析的，落盘后内存的增长，来自于存储 key 和指针关系的那个 map（hashtable），进而导致了 query 被 cancel。
可否进行增强，如果当前buildside统计信息表记录数过大（比语句级内存设置*系数大），那么则采用另一种算法，可以稍微慢一些但是支持更大数据量buildSide的hashJoin呢（比如其它数据库用的对build和probe进行partition划分，分批逐步完成计算）
是一个可行的方向。这种自适应的方式，同时也会依赖优化器对 build 侧的基数估计的准确度。
额外提一点是，自 6.5.0 之后，我们支持了实例级别的内存控制。默认的 tidb_mem_quota_query 为 1GB，实际使用中相对比较保守，在真实业务中使用的时候，由于存在实例级别的内存控制，如有必要，我们会倾向于放大 tidb_mem_quota_query 的设置值。