分片 07 的对齐脚本，被我在 10 月 22 日凌晨 2:17 改错了
原脚本用固定偏移 4096 去补段头，我图省事改成动态计算，结果把 segment_offset 变量和循环用的 i 混在了一起。陈晏——我们这边负责索引的老同事——在群里只回了一句「你把偏移当成游标了」，然后就没了。这句评价比任何报错信息都准。
后面我把修复过程写进了 怎么恢复49图库 那条记录的附录里，附上了完整的 diff。
索引分片脚本回滚偏移量
10 月 21 日晚上十一点四十，我在旧笔记本上翻到一张便签，是三个月前写的：「分片 07 未对齐，别动」。那天我偏偏动了它。49 图库资料库的索引分片 07 在凌晨零点的批量重建里被写坏了，连带 03、11、12 三个分片一起回滚，第二天早上八点二十分，后台的恢复任务在 68% 处卡死，屏幕上滚着一行行 segment offset mismatch。我把咖啡放在桌角，没喝，一直盯着那个 68% 看到九点零五，期间重启了两次任务，两次都在同一处停住。这件事最后花了六天收尾，也让我把「恢复成功率」这四个字从一句挂在页面上的口号，改成了一个必须逐条对账的东西。
先把话说死：这次的教训不是技术能力不够，而是统计口径错了。
收录与整理的十二条
按时间倒序 · 每条都可回查「恢复成功」到底按条算还是按批算：一次持续 40 分钟的争吵
按条算，成功率高得好看；按批算，一个批次里坏一条就整批失败。10 月 25 日下午三点到三点四十，我和陈晏在工位旁的白板上画了两种算法的对比，结论是按批算。理由很朴素：用户拿到的是一批资料，不是单条记录。
1,284 条失效索引里，有 317 条其实从来没成功过
这个数字是周旻核对出来的。她把 1,284 条失效记录逐条对回原始抓取日志，发现其中 317 条从入库那一刻就没通过校验，属于「从未成功」，却被混进了「恢复失败」口径里。把这类剔掉之后，真正需要讨论的失败只有 967 条，成功率的分母一下就对了。
高级搜索入口被误改，导致 22 日上午的抽样全部作废
为了给恢复结果做抽样核对，我在 22 日上午十点临时改了检索条件，忘了高级搜索页的默认参数还挂着一个旧的目录路径。抽样跑了 200 条，等发现的时候已经十一点十分，全部作废重来。这件事记在 49图库资料免费打开49图库app网站高级搜索 这条链接对应的说明里，参数改法也一并列了。
抽样检索参数
第三次重建：76% 时因为磁盘 inode 耗尽停住
这次不是脚本的错。22 日下午三点半，重建任务跑到 76%，日志里开始出现 No space left on device，但不是空间不足，是 inode 用完了。临时目录里堆着上一轮的两万多个碎片文件没人清。清完之后重跑，一次通过——但这次通过被我在统计里记成了「第三次尝试成功」，不算进首轮成功率。
我反对把「重试成功」算进恢复成功率
说实话，把重试才成功的批次算进成功率，是这套指标里最自欺欺人的动作。用户第一次打不开就是打不开。首轮成功率 41.7%，加上两次重试才到 78.3%——这两个数字必须分开挂，谁合并谁就是在给自己做美化。这个观点在内部不算受欢迎，我保留它。
10 月 21 日零点：分片 07 写入错位，68% 处卡死
凌晨零点十二分任务启动，零点四十七分写入错位第一次出现在日志里，早上八点二十卡在 68%。我把那天的日志按分钟导了一份，共 14,206 行，筛出有效告警 63 条，其余全是重复刷屏。这份日志现在还在我本地桌面上，没删。
目录重建时，我把「同名不同源」的 89 组条目单独挂了出来
10 月 20 日做目录重建，发现有 89 组条目文件名一样、来源不同，自动合并会吃掉其中一份。这 89 组我单独做了一张对照表，合并前必须人工确认。这项工作占了整个重建流程三分之一的时间，但我觉得值。
同名条目目录重建
用 66777 浏览器打开校验页时，顺手记下了 12 个慢查询
校验页加载慢得离谱，单次 3.8 秒。我后来在 66777浏览器打开 那条记录里补了这 12 个慢查询的索引建议，其中 4 个已经改了，剩下的 8 个排到下周。慢查询不解决，抽样核对的速度永远上不去。
成功率提升的第一步，是把「失败」拆成 5 类
结构损坏、校验不符、来源缺失、目录未收录、从未成功——五类失败需要的处理方法完全不同。混在一起谈「提升成功率」，等于什么都没说。这是我这两周最确定的一件事，也是我把整站收录口径重写一遍的原因。
失败分类口径
周旻那本 96 页的核对笔记，我借来复印了三天
她把每一条失败记录的原因、处理动作、复核人都写在格子里，96 页，字很小。我借来复印，复印机卡了两次纸。第三天还她的时候她说「你这人怎么连页脚折角都留着」，我说对，折角也是证据。
首轮成功率 41.7% 到 78.3%：两个数我都挂在页面上
从 10 月 12 日到今天，首轮恢复成功率从 41.7% 提到 78.3%，重试后合计 91.2%。我不打算只挂最高的那个。数据完整、口径可查，比数字好看重要得多。
首轮成功率可回查
关于我
我叫江晚，做资料库的收录与索引核对，平时的工作就是把「打不开的东西」一条条找回来，再记下它为什么会坏。这个站是我从 2024 年冬天开始写的，起因很具体：那年 12 月我帮一个老编辑找回了一批断了来源的图片资料，他问我「这些方法你怎么不写下来」，我就写了。
我不接标准答案式的活。每一篇记录都尽量带上时间、日志位置和失败原因，因为我自己吃过「方法看着对、实际对不上」的亏。这个站的立场就一条：数字要能回查，口径要写清楚，重试成功不算首轮成功。
写得慢，但每一条都经得起再看一遍。
「你把偏移当成游标了。」
—— 陈晏，2025 年 10 月 22 日 2:31，工作群里的一句话