节点内存怎么切：dbcache 之外，索引缓存另有八分之一与一千兆的双层封顶

给比特币节点调内存参数时，大多数人的注意力都在 dbcache 上——那是 UTXO 集合缓存的主预算。但如果开了 txindex、txospenderindex 或区块过滤器索引，会有一笔容易漏算的账：索引们也有自己的缓存，而且它的上限是自动推导的，规则写死在源码里：拿总缓存预算的八分之一，再和一千兆取较小值。本文全部以 Bitcoin Core v31.0 源码为准，核心逻辑在 src/node/caches.cpp。

一笔总预算，先切索引再给账本

节点启动时，CalculateCacheSizes 先把 dbcache（未显式配置时按机器内存自动定，大内存机器默认一千兆）解析成字节数的总缓存预算，然后逐个问一遍”这个索引开了吗”。开了 txindex，就给它分配 min(总预算/8, MAX_TX_INDEX_CACHE)；开了 txospenderindex，同样按 min(总预算/8, 1024MiB) 给；过滤器索引则合并共享 MAX_FILTER_INDEX_CACHE（也是一千 meg）。注释里说明了为什么要单列：对交易索引而言，数据库缓存的大小会带来”有意义的差别”——索引查询是点查，缓存命中与否直接决定快慢。切完索引，剩下的预算才流向 UTXO 库的缓存。

双层上限各挡什么

这条 min(总预算/8, 1GiB) 的规则两层各有一层用意。除以八，是让索引缓存跟着总预算成比例缩放：小机器上不要把 UTXO 缓存挤死，大机器上索引自动多分一点。一千兆的封顶，则是防止比例在超大配置下失控：有人给几百吉内存的机器把 dbcache 配到天文数字，八分之一也可能是几十吉——对以点查为主的索引库，多给基本是浪费，不如设个天花板。两个数字都写在源码常量里（MAX_TX_INDEX_CACHE、MAX_TXOSPENDER_INDEX_CACHE、MAX_FILTER_INDEX_CACHE 都是 1024 兆），没有配置项能把它们撑大。

对容量规划的实际含义

把 dbcache 调大不等于”多出来的全给账本”。假设机器内存充裕、你把 dbcache 配到八千兆：若开着 txindex，其中一千兆会先被索引层拿走（八千的八分之一正好一千，触到封顶线），UTXO 缓存在剩余额度与自身上限之间再分配。反过来，dbcache 配得过小（比如只有一千多兆）时，索引分到的八分之一也就一百多兆，大型资源管理器上索引查询会明显更吃磁盘。估算内存占用时，日志里各缓存生效值、索引是否开启，比参数名本身更值得记录；32 位系统另有单独的一千兆 dbcache 封顶逻辑，老设备上跑节点时留意版本位数。

常见误区

第一，以为索引缓存可以单独配参数——不能，它只有这条自动规则，想调只能调总 dbcache 再按比例传导。第二，以为多个索引会各抢各的直到把总预算吃光：每个索引最多拿八分之一且封顶一千兆，同时开两三个索引，索引层合计占比也有限。第三，把这笔账和进程的其他内存开销混在一起：内存池（默认三百兆预算）、签名与脚本缓存、连接缓冲各有各的池子，dbcache 从来不是”节点总内存”的同义词，容器化部署做限额时要把几本账加起来算。

顺序扣减本身也是一种取舍

细读这段代码还会发现一个常被忽略的顺序效应：三项索引的八分之一不是同时从原始总额里切，而是一项扣完才轮到下一项——txindex 先按总预算的八分之一取走并从余额里扣除，txospenderindex 再按扣后余额的八分之一取，过滤器索引最后合并取一份封顶额度、再按活动索引数摊平。这意味着索引开得越多，后开的分到的绝对值略少于先开的，虽然差距在封顶一千兆的现实里通常无感。设计者把顺序写死而不是平分，隐含的判断是：交易索引的点查收益最直接，优先保它；其余按余量弹性供给。对使用者的启示是：别迷信”多开索引互不影响”，每多开一个，除了磁盘与同步时间，内存分配链条上也确实多了一层扣减。

风险提示：本文为节点内存管理机制科普，常量与分配规则以 Bitcoin Core 当前版本源码为准，可能随版本调整；不构成性能承诺或投资建议。