权重查询方法，自动导出遗漏分页时怎样检查完整性
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /7a50bdd724bb.html
📄
权重查询方法，自动导出遗漏分页时怎样检查完整性
结论先说：自动导出遗漏分页时，完整性不能靠“总条数对得上”来确认，而要用一个独立于导出任务本身的边界样本去反查。如果导出接口只返回了第一页或前几页，而分页参数没有被真正传递下去，那么总数、页数甚至成功状态都可能是对的，缺的只是中间或尾部数据。这种情况在权重查询方法里很常见：查询条件越宽，分页越容易被截断，而截断点往往不在第一页。
先确认遗漏发生在哪一层
自动导出通常经过三层：查询构造、分页请求、结果落盘。遗漏可能出现在任何一层，检查时要分开看。
- 查询构造层：筛选条件是否在翻页时被重置。假设第一页带上了“近30天”条件，第二页请求却丢掉了该条件，那么后续页返回的其实是另一批数据，和第一页无法拼接。判断证据是：对比第一页和后续页请求参数，看筛选字段是否一致。
- 分页请求层：页码或游标是否真的递增。有些自动导出在遇到空页或错误码时会提前停止，但停止前已经写入了部分结果，任务状态仍显示成功。判断证据是：记录每次请求的页码或游标，看是否连续、是否在预期页数前中断。
- 结果落盘层：写入时是否去重或覆盖。如果按主键覆盖写入，而不同页返回了相同主键，后一页可能覆盖前一页，造成总量虚高但内容缺失。判断证据是：统计落盘后的唯一主键数量，与请求返回的原始条数对比。
三层里只要有一层没对齐，完整性检查就会失效。所以不要先看总数，先看请求日志和落盘主键。
用边界样本反查，而不是用总数反查
总数对得上，只说明导出任务自己认为它取全了，不能证明分页真的走完了。更可靠的做法是选一个边界样本：按时间倒序导出时，取最后一页应该出现的那条记录；按权重值排序时，取阈值附近的那条记录。然后单独查询这条记录，看它是否出现在导出结果中。
假设导出条件是权重值大于等于某个阈值，共导出若干页。你可以手动查询阈值附近的一条记录，如果它不在导出文件里，而请求日志显示分页在它之前就停止了，那么遗漏点就定位到了停止的那一页。这个动作的价值在于：它把“完整性”从一个模糊感觉变成了一个可复现的坐标。
如果边界样本存在，但中间页缺失，总数反查就完全看不出来。这时需要按页抽样：从每一页各取一条记录，检查其主键是否连续覆盖了预期区间。抽样不必全量，但必须跨页，不能只查第一页和最后一页。
一个会让上述结论失效的反例
边界样本反查成立的前提是：查询结果本身是稳定排序的。如果排序字段存在大量相同值，而分页又没有稳定的次级排序键，那么同一批数据在不同次请求中可能出现在不同页，甚至重复或跳过。此时边界样本可能恰好被查到，但中间数据仍然缺失；反过来，边界样本没查到，也不一定就是分页停止，可能只是排序抖动把它挪到了别处。
这个反例的识别方法是：用相同条件连续请求两次第一页，对比返回顺序是否一致。如果不一致，先解决排序稳定性，再谈完整性检查。否则任何基于页码的核对都会得出错误结论。
下一步动作：先固定排序，再记录分页轨迹
确认排序稳定后，下一步不是重新导出，而是把分页轨迹记录下来。具体动作是：在自动导出流程中保留每次请求的页码或游标、请求时间、返回条数，落盘时同时写入来源页标识。这样即使后续发现遗漏，也能直接定位到是哪一页、哪个游标出的问题。
这个动作的结果会直接影响下一步：如果轨迹显示分页在某一页后不再递增，问题在请求层，需要检查翻页条件是否被重置；如果轨迹完整但落盘主键缺失，问题在写入层，需要检查去重和覆盖逻辑。只有轨迹完整且边界样本全部命中，才能认为这次导出的完整性达到了可接受水平。在此之前，不要用总数或成功状态作为放行依据。
