一、交易索引到底是干什么的
比特币全节点默认只保证一样东西：最新的未花费输出集合。至于历史上某一笔交易当初长什么样、装在哪块区块的哪个位置，默认并不记录。getrawtransaction 想按编号取回任意一笔历史交易，靠的是一份额外索引：交易编号指向它在区块文件里的物理位置。开启方式就是配置文件里把 txindex 置为 1，官方参数说明写得很直白——为 getrawtransaction 维护完整交易索引，默认值是关。
这份索引的代价要提前想清楚。它是一比一跟着链长大的第二本账：链每长一块，索引就多记一页，磁盘占用随主网历史线性膨胀，具体体积随节点版本与数据布局而异，以本机数据目录实测为准。它还有一个硬冲突：与修剪模式互不相容——旧的区块文件都被删了，索引指向的位置就成了空头支票；而修剪条目下官方也专门提醒，回退修剪需要重新下载整条链。开了 txindex 的节点，基本就是给自己宣布了全归档角色的定位。
二、旧共识：事后补开要整链重来
很长时间里，官方参数说明对事后启用 txindex 的补救路径写得毫不含糊：加上 txindex=1 之后，需要带着 -reindex 重启，节点会抹掉链状态与区块索引，从磁盘上的 blk*.dat 文件重建一切。reindex 会顺着区块文件从头重放每一个区块，重新推导 UTXO 集合，顺带把新索引建起来。数据目录本身没坏的情况下，账不会丢，代价是几个小时到几十小时的重新处理，以及期间机器基本被链处理线程占满。
这条旧路的问题在于规模：十来年历史要逐块重放，任何一次半途断电或磁盘写满，都可能让你从头再来。所以后来的版本开始改造这个过程，让索引追赶支持断点——但把旧共识当现状照搬的人，会在一台已经同步好的机器上多等一个完全没必要的重放周期。
三、新共识：索引可以后台追着跑
近几个大版本的发行说明与文档开始把可选索引描述为可增量同步的状态：节点记下每个索引追到了哪个区块，重启后从断点继续，而不是每次启动都怀疑人生地全量重建。这意味着事后开启 txindex 的正确姿势变了——加参数、正常重启，节点在正常同步新区块的同时，后台线程逐段回补历史索引；getindexinfo 里的同步高度字段会告诉你它追到哪了。
判断自己站在哪条共识下，办法比记版本号可靠：重启节点看日志，如果开头就出现擦除并重建链状态的提示，说明这台机器的版本还在旧流程；如果只有索引追赶的进度行、区块处理没有被推倒重来，那就是增量路径。拿不准时翻当前版本的发行说明，那里写了每个可选索引的重建要求。
四、补索引期间的三个现象
后台追赶期有几个容易误判的现象。第一，区块同步进度条照常走到顶，节点看起来完全健康，但历史交易查询会时不时返回找不到——索引没追到那个高度而已，这不代表链数据有问题。第二，getrawtransaction 对索引之外的交易报错，信息与交易真的不存在时几乎一样，排查时先查 getindexinfo，别急着怀疑交易本身。第三，追赶期间磁盘读负载明显偏高，RPC 响应变慢属于正常，硬去加大并发只会更慢。
验收动作很简单：等 getindexinfo 报告索引高度追平链尖，再随机抽几笔不同年份的历史交易跑一遍 getrawtransaction，都能取回完整十六进制，才算索引真正可用。
五、什么人真的需要它
值得为 txindex 掏磁盘的场景很具体：自建区块浏览器或余额查询后端，需要在任意地址的完整历史上做交易级检索；给铭文或元协议做索引，要把每笔载带交易的原始字节都取回来；运营对账系统，需要按编号回放任意充值交易。反过来，只是自托管加收款监控，钱包与节点自带机制已经够用，多这本账只是多出一份磁盘与多年的维护义务。
还要交代一个易混点：txindex 管的是按编号找交易，地址找钱靠的是钱包扫描或 blockfilterindex 一类的过滤索引，两者互不替代。有人开了 txindex 却发现查余额依然慢，问题多半出在索引选型而不是参数没生效。
风险提示：本文仅为节点技术机制科普，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。