开发者进阶中级992 次阅读
链上索引：为什么不能直接遍历链上数据
RPC 只提供点查询，没有筛选与聚合。理解链上数据的组织方式，以及自建索引、Subgraph 与数据 API 三条路线。
#索引#链上数据#事件日志#RPC#架构
一句话结论
链上数据天生是按时间顺序排列的事件流，不是可查询的数据库。应用里任何"按条件检索""按用户聚合"的需求，都必须先有人把它转换成索引。
RPC 能做什么、不能做什么
RPC 提供的是点查询：给定区块号或地址，返回对应结果。它没有条件筛选、没有排序、没有跨合约聚合，也不能一次返回"某个用户在所有合约里的全部历史动作"。想拿到这些数据，只能从某个高度开始逐块拉取、解码、入库——这正是索引器在做的事。
为什么链上检索这么贵
- 状态只保存"当前值"，历史状态默认被裁剪，条件回溯几乎不可行。
- 事件日志可以按地址与主题过滤，这是链上唯一原生的"索引"，但检索维度有限，也拿不到合约没有发出来的内部数据。
- 逐块遍历全网数据意味着海量 RPC 请求，成本高、耗时长，而且很快会被限流。
索引的三条路线
- 自己写索引器：订阅新块、回填历史、写入自己的数据库。最灵活，但要自己处理重组、漏块与断点续跑。
- 用通用索引服务：以 The Graph 的 Subgraph 为代表，你只声明实体与处理逻辑，同步与存储交给网络（或托管方）。
- 用第三方数据 API：接入成本最低，但受制于对方的覆盖范围、配额与口径。
三条路线的本质相同：把事件流转成关系型或文档型数据，再用熟悉的查询方式消费。
给你的教训
- 别在生产环境用 RPC 撑列表页与统计：那不是它的设计目标，性能与额度都撑不住。
- 索引数据的新鲜度要显式告诉用户（"数据截至某个区块"），否则用户会以为看到的是实时状态。
- 索引器必须能从任意高度重放：链重组、逻辑改错、字段新增都需要重跑历史。
- 评估第三方索引服务时，先确认它覆盖哪些链、索引哪些合约、出错时怎么降级。