关键词搜索量查询一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /a844b074f621.html
📄
关键词搜索量查询一次全站扫描被中断后怎样判断已覆盖范围
中断后最可靠的做法不是看剩余词表，而是先固定中断前的最后一条已写回记录，再用它反推扫描顺序、游标位置和未提交批次，从而把“已覆盖”限定为可验证的部分，而不是整站。下面用一个假设情境说明判断步骤和取舍。
假设情境：扫描到一半时任务被终止
假设你维护一个内容站，用某类批量查询工具对全站页面涉及的关键词做搜索量补全。任务按字母顺序处理词表，每处理一批就写回结果，同时把当前游标写入一张进度表。某天任务因配额耗尽或进程被杀而中断，你打开结果表发现只完成了约六成行。此时最容易犯的错误是把“结果表里的行数”直接当成覆盖范围，因为写入和游标更新可能不在同一事务里，两者会出现偏差。
判断覆盖范围的目标不是算出精确百分比，而是回答一个更实际的问题：哪些词的结果可以直接用，哪些必须重跑。这个区别决定了你下一步是补扫还是全量重来。
先确认三个可验证的锚点
中断后不要立刻重启任务，先固定以下三个锚点，它们互相独立，能交叉验证：
- 最后成功写回的主键或时间戳。查结果表里最大的写入时间或最大自增编号，这是“已提交”的边界。
- 进度表里的游标值。它记录任务处理到词表哪个位置，但可能领先或落后于实际写入。
- 批次日志或任务日志。如果工具按批提交，日志里最后一条“批次完成”记录是判断已提交范围的第三份证据。
三者一致时，覆盖范围基本可以确认；三者不一致时，以写入结果表为准，取三者中最保守的边界。原因是写入是唯一已经落地的产物，游标和日志都可能因为提交顺序问题而虚高。
用抽样反推，而不是重扫全站
确认边界后，从边界附近取小样本做验证。假设游标停在字母 M 附近，就从 M 前后各取几十个词，逐个核对结果表里是否有对应行、值是否合理。如果边界前的词大部分有结果、边界后的词基本没有，说明中断位置和游标大致吻合，可以只补扫边界之后的词。
反过来，如果边界前也出现成片缺失，说明存在写入失败或跳批，补扫范围要往前扩展。抽样验证的动作会直接改变下一步：抽样通过就做增量补扫，抽样不通过就宁可对整段区间重跑，因为逐词排查的成本通常高于重跑。
区分“没覆盖”和“覆盖了但值为空”
规模化扫描最容易出现的例外是：某些词确实被处理过，但没有返回有效数值。这类词在结果表里可能是空行、默认值或缺失行，看起来像没覆盖，实际是已处理但无数据。判断方法是看结果表是否区分“已处理无结果”和“从未处理”两种状态。如果工具不区分，你就无法只靠结果表判断覆盖范围，必须结合日志或游标。
这个区别会影响补扫策略：把“已处理无结果”的词当成未覆盖去重跑，会浪费配额且结果不变；把它们排除，又可能漏掉因临时错误而失败的情况。可行的折中是只对边界附近的空值词重试一次，远离边界的空值词按已覆盖处理。
决定补扫还是重扫的判断依据
把上面的信息汇总成一张简单判断表，可以避免凭感觉决策：
- 写入边界、游标、日志三者一致，且边界附近抽样正常：只补扫游标之后的区间。
- 三者不一致，但写入边界附近抽样正常：以写入边界为准，补扫其后的区间，并记录偏差原因。
- 边界附近抽样出现成片缺失：把补扫起点前移到最近一个抽样完整的批次，重跑该区间。
- 工具不区分空值和未处理，且日志不可用：对整段区间重跑，或在下次任务中改为逐批提交并保留批次标识。
这套判断的前提是任务本身按顺序处理且有可查的写入记录。如果扫描是并发乱序、结果表没有时间或批次字段，那么中断后无法可靠重建覆盖范围，只能全量重扫。这也是下次设计任务时值得改的地方：让每次提交带上批次号和时间，中断后的判断成本会大幅下降。
