Partial QueryCache（部分查询缓存）在非DBMS数据源下的实现思路探讨

以下方案适配非DBMS数据源（如CSV文件、SQL/MED、Spark查询等无原生索引、单次查询成本高的场景），优先保证结果正确性，可根据业务场景逐步放宽规则提升命中率：

1. 语义解析替代纯文本哈希匹配 #

不直接对SQL文本做归一化哈希，而是先解析为抽象语法树（AST），拆解为可独立匹配的语义组件，每个组件单独做匹配校验：

• 数据源组件：对表/文件路径、连接逻辑、分区规则、源数据修改时间/版本号生成唯一指纹，要求100%匹配，避免源数据变更导致结果错误
• 投影列组件：记录每一列的完整血缘（原始来源字段、计算表达式、数据类型），而非仅记录列名。例如ProductGroup AS Product会被标记为「列值=Sales表.ProductGroup，别名=Product，类型=VARCHAR」，只要新查询需要的列可以通过缓存列的确定性运算得到，即可命中
• 过滤条件组件：将所有过滤条件转换为合取范式（CNF），校验缓存的过滤条件是否为新查询过滤条件的子集。例如缓存过滤条件为Country='US'，新查询过滤条件为Country='US' AND State='CA'，即可判定缓存数据范围完全覆盖新查询需要的范围
• 聚合/排序/分页组件：记录聚合函数类型、分组键来源、排序规则、分页范围，缓存的对应逻辑粒度更粗（或者一致）时即可命中，例如缓存按天聚合的销售额，可以支撑按月聚合的新查询二次计算

2. 缓存条目附加完整元数据 #

每个缓存结果除了存储数据集本身，同步存储以下元数据用于快速命中校验：

• 源数据指纹：如CSV的文件修改时间、大小、路径哈希，Spark表的版本号，用于快速校验源数据是否变更
• 数据边界：缓存结果覆盖的维度范围，例如Country ∈ ['US']、date between '2023-01-01' and '2023-12-31'
• 计算属性标记：是否有聚合、是否去重、是否有分页截断、是否使用非确定性函数（如rand()），使用了非确定性函数的缓存不参与部分匹配

3. 分层缓存设计提升命中率 #

按照计算成本从高到低设置多层缓存，自动淘汰低命中率条目：

• 底层缓存：存储全量原始数据扫描结果，适合多次查询同一份源文件的场景，避免重复扫描磁盘
• 中间层缓存：存储常用过滤条件、常用聚合粒度的中间结果，减少二次计算量
• 顶层缓存：存储高频查询的最终结果，直接返回无需二次计算

4. 表达式归一化处理 #

对所有语法树节点做等价归一化，避免不同写法的等价逻辑无法匹配：

• 运算表达式归一化：例如a + b和b + a、date >= '2023-01-01' AND date < '2024-01-01'和year(date) = 2023转换为统一的哈希值
• 别名归一化：匹配时优先使用原始字段/表达式匹配，忽略别名差异
• 常量参数归一化：将常量占位，适配参数化查询的匹配

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