自己跑 ord 节点的人会先后撞上同一件事：索引库需要重建。ord 官方文档的 Reindexing 页面把这件事的两种触发原因、数据库文件的准确位置和重建命令写得非常具体，值得在动手前完整读一遍。
先说什么叫”重建索引”。文档的定义是：删掉数据库文件，然后用 ord index update 或 ord server 重新启动索引过程。它列出的重建原因只有两条：其一，ord 发布了改动数据库结构的大版本；其二，数据库以某种方式损坏了。注意这里的因果——重建不是性能调优手段，也不是同步卡住时的万能重启键；普通的区块落后用普通同步追块即可，只有”库结构不认了”或”库文件坏了”才需要删档重来。
ord 用的数据库叫 redb，是一个纯 Rust 的键值存储库，索引文件默认名叫 index.redb。文档给了一张按操作系统的默认路径表：Linux 在 $XDG_DATA_HOME/ord 或 $HOME/.local/share/ord（例：/home/alice/.local/share/ord）；macOS 在 $HOME/Library/Application Support/ord（例：/Users/Alice/Library/Application Support/ord）；Windows 在 {FOLDERID_RoamingAppData} 下的 ord（例：C:\Users\Alice\AppData\Roaming\ord）。在 macOS 上重建，文档给的示范是两步：先 rm 掉 ~/Library/Application Support/ord/index.redb，再执行 ord index update。删错目录的结果是”重建了半天、原库原封不动”，所以执行前用 ord settings 或文件系统确认当前 datadir 是必要动作。
不想删默认文件也有正规开关：文档说明可以用 ord —datadir DIR index update 指定数据目录，或用 ord —index FILENAME index update 直接给出索引文件路径。这两条命令的意义在于”先建新、再对照、后切换”——旧库损坏但不急着删时，可以指定一个新文件从零索引，跑完与旧库抽查比对后再替换，把不可逆操作变成可回滚操作。
重建的真实成本是时间而不是磁盘。索引过程要从创世块开始逐块推导每聪归属与每笔铭文的生命周期，文档在 sat hunting 等其他页面反复强调前置条件是”同步完成并带交易索引的 Bitcoin Core 节点”（-txindex 或配置 txindex=1），意味着重建期间你的机器同时承担核心链同步与 ord 索引两条追赶线。普通用户用公共浏览器即可完成的大部分查询，自建节点重建索引通常只有两类人需要：持续跑 ord server 做集成的开发者，和对第三方索引口径不放心、要自查的收藏者。
还有一条与损坏处理相关的常识放在这里最顺：索引库损坏的典型征兆是 ord 启动时报库文件读写错误，或者不同子命令对同一查询给出互相矛盾的结果。处理顺序应当是——先确认不是 Bitcoin Core 端 txindex 未开（文档明确这是 ord 正常工作的条件），再确认二进制版本与库版本匹配，最后才走到删库重建。反过来说，如果删库后同一版本立即复现同样错误，问题多半在底层磁盘或文件系统，继续删库只会重复浪费同步时间。
把整个流程压缩成一份可执行的检查单：第一步，记下 ord 版本号与报错原文，去发行说明里找”是否要求重建”的明示——多数版本升级会在升级提示里写明是否需要删库，按说明操作而不是按社区传闻操作。第二步，定位当前生效的 datadir，确认 index.redb 的实际路径与大小，确认磁盘剩余空间足够容纳新旧两份再考虑保留旧档。第三步，若保留旧档，用 —index 指向新文件从零索引，完成后抽查若干已知铭文与聪的历史，两侧结果逐条对得上才替换。第四步，删档重建期间用 ord 的状态输出监控进度，追平链头之前不要对外提供查询服务，否则返回的是”过去的索引”。整个单子没有一个步骤需要动钱包或密钥，也再次印证了那句话：索引是派生数据，操作它的风险上限是”查询暂不可用”，永远够不到资产本身。
ord 数据库与比特币共识数据的分工也值得一并说清：redb 里存的是 ord 按协议规则推导出的索引结果（哪个聪在哪个输出、铭文如何流转），而不是另一份区块链账本；删掉它永远不会损失任何资产，损失的只是”可查询性”，同步完成后查询会恢复如初。把这一点记住，重建索引时的心态就能稳在”等时间”而不是”救资产”上。
本文为机制说明，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。