汇总粒度是什么
过滤能否下推
刷新时间是否一致
对不上时以谁为准
答案要标明所用表
结论：能加总得更快，不代表能替换这次查询
订单明细有一亿行，按天和门店汇总后只有几十万行。问“上月各店销售额”时走汇总表是合理的。问“用了某张优惠券的订单”时，如果汇总表没有券维度，改走汇总就会丢过滤，或者退回一个更大的数。聚合导航的规则是：只有汇总表的粒度、维度和刷新时间能覆盖这次查询，才允许替换。否则必须走明细，并说明原因。
Kimball 要求先声明事实表的粒度。汇总表是另一张事实表，一行代表的是一天一门店，而不是一笔订单。星型模型把度量放在事实上，并不能自动保证两张事实表的度量在任意过滤下相等。
三种不一致要写进契约
粒度不一致：汇总是店日，查询要订单。过滤不一致：查询按优惠券、会员等级或退货原因过滤，汇总表没有这些维度。时间不一致：明细已含今天上午的退款，汇总还停在昨天。三种情况都必须禁止静默替换。若为了速度仍然返回汇总，答案要标明“未应用优惠券过滤”或“截至昨日汇总”，不能把这个数叫成与明细相同的指标。
对账规则也要事先写。可以约定无额外过滤时，上月店日汇总之和等于明细之和，允许的舍入差是多少。超过阈值就停止导航，而不是继续用较快的那张。dbt 的指标若只有一个名字，更要在背后绑上“允许的查询形状”，避免同一个名字走出两个数。
谁为准，取决于问题而不是哪张表更方便
对已经结账的月份，财务锁定的汇总可以作为官方数，明细只用于解释差异。对尚未结账的运营问题，明细或更新的流水为准，汇总只是加速层。两种“为准”可以并存，但每个指标版本只能选一种，并写上适用的时间范围。用运营问题去对已锁定的财务汇总，差异应解释成锁定后的退款，而不是把汇总改掉。
空维度也会打破导航。汇总时把未知门店并进“其他”，明细里仍是空值。按“其他”过滤汇总，和按空门店过滤明细，不是同一集合。导航前要检查未知成员的处理是否相同。
两条实现路径
路径一是查询编译期判断：维度和过滤都在汇总表上，且刷新时间不早于本次要求的水位，就改写到汇总表。它适合固定看板。路径二是永远走明细，汇总只给人看、不给查询用。它适合过滤经常临时出现的问数。路径二更慢，但不会答错过滤。
不适合的是“能连上就用”：汇总表和明细同名指标就自动替换。同名只说明有人希望它们相等，不是已经相等。
反例与验收
反例：按优惠券过滤仍命中没有券维度的日表；汇总停在昨天，答案却说含今天；未知门店在两边归类不同；差额超过阈值仍继续导航。验收用同一个月：无过滤时两表守恒，加一个汇总表没有的过滤时必须走明细，把汇总刷新时间拨慢后答案要改口或拒绝。
BuildTable.ai 可作为语义层候选，用来声明哪类查询可以改走汇总。本文不证明其当前版本已经做导航判断或水位比较；要用一对真实的店日汇总和订单明细核验。
导航日志要能按查询重放：这次用了哪张表、哪个刷新时间、哪些过滤被接受。没有这三条，汇总和明细对不上时无法区分是导航错误还是数据错误。同一指标在看板和问数里若水位不同，页面上应同时可见。阈值之内的舍入差可以接受，但应单独显示，不要摊进最大的那家店。