SXT Proof of SQL 时间单位差异比较问题解析

问题背景

在SXT Proof of SQL项目中，当处理不同时间单位的比较操作时，发现了一个关键性的边界条件问题。具体表现为：当用户尝试在秒级时间单位的表上执行纳秒级时间戳的比较查询时，系统会返回验证错误而非预期的查询结果。

问题现象

考虑一个包含时间戳列的表，该列以秒为单位存储，数据值为[-1, 0, 1]。当执行以下查询时：

SELECT * FROM table WHERE times < timestamp '1970-01-01T00:00:00.000000001Z'

理论上应该返回[-1, 0]两条记录，因为：

• -1秒早于基准时间
• 0秒等于基准时间（不考虑纳秒部分）
• 1秒晚于基准时间

然而实际执行时，系统却抛出"sumcheck evaluation check failed"验证错误。有趣的是，将查询条件改为大于比较时却能正常工作。

技术分析

时间单位处理机制

项目中通过检查时间戳字符串的纳秒部分来确定时间单位：

• 如果纳秒部分不能被1000整除，则为纳秒级
• 否则如果不能被1,000,000整除，则为微秒级
• 否则如果不能被1,000,000,000整除，则为毫秒级
• 否则为秒级

这种处理方式虽然直观，但在边界条件下可能不够精确，特别是当处理不同时间单位的比较时。

不等式表达式实现缺陷

核心问题出在不等式表达式节点的实现上。在代码中，对于小于等于(LTE)和大于等于(GTE)条件的处理存在参数顺序错误：

let diff = if self.is_lte {
    scale_and_subtract(alloc, lhs_column, rhs_column, lhs_scale, rhs_scale, false)
} else {
    scale_and_subtract(alloc, rhs_column, lhs_column, lhs_scale, rhs_scale, false)
};

在GTE分支中，rhs和lhs参数应该交换位置。这个错误导致时间单位转换后的比较运算产生了不正确的结果。

解决方案

修复方案包括两个关键部分：

1. 修正不等式表达式节点中的参数顺序问题
2. 增加针对大于等于(GTE)不等式的测试用例，确保边界条件得到充分验证

项目影响

这个问题在proofs-service中尤为突出，因为网关目前只能以纳秒精度创建表(DDL)。当查询解析出的时间单位与表的纳秒精度不一致时，就会导致验证失败。这个修复确保了不同时间单位之间的比较操作能够正确执行。

最佳实践建议

1. 在涉及时间比较的查询中，尽量确保比较双方使用相同的时间单位
2. 对于关键业务逻辑，增加边界条件的测试用例
3. 考虑更精确的时间单位检测机制，避免仅依赖纳秒部分的零值判断

这个问题的解决不仅修复了一个具体的技术缺陷，也为处理时间相关查询提供了更可靠的基础。