Ponder查询为什么还是旧部署？核schema、views与serve读取目标
链小知 · 进阶 · 核验 · 依官方文档整理
把索引写入部署与只读查询副本分开，核回填就绪后views实际指向的表。
开始前准备
- 准备自己已有的脱敏配置、日志或状态回执，保留产品版本、对象、字段和日期；缺值不补成成功或零。
1. 先核数据库与运行模式
PGlite默认在同一Node进程及.ponder目录，适合本地开发；生产须Postgres。记录DATABASE_URL所指对象但不抄凭据，并核mode：dev本地热重载，start生产索引，serve仅Postgres HTTP服务且不索引。不要把一个仍响应查询的serve当正在推进链高的start。
检查结果：数据库类型、运行模式和版本已定位；查询存活未当索引推进。
2. 核每个start部署自己的schema
以DATABASE_SCHEMA或--schema定位实际部署；并发Ponder索引部署不能共用schema。dev默认public，start无默认须显式指定；start创建的表不会自动删除。查旧记录时不能只按公共库名判断读的是最新部署，缺部署schema映射保持未知。
检查结果：start部署与schema一一定位，dev默认值未套到生产。
3. 稳定views只在发布条件满足后换目标
views pattern用稳定schema代理具体部署表。ponder db create-views可手动创建/更新，start --views-schema会在backfill完成、部署ready时自动做；缺执行回执或views定义时不能据新进程启动就说指针已切换。/health立即200只说明进程存活，/ready要所有链到实时后200、回填中503；按已有材料核切换时点。
检查结果：稳定views schema、目标部署schema、回填与发布回执对应；health与ready未混用。
4. 只读查询按目标schema解释
Direct SQL支持SELECT，不应INSERT/UPDATE/DELETE Ponder表，也不支持表trigger。显式schema.table、search_path或Drizzle setDatabaseSchema都可能决定目标，须以原配置核；API中ponder:api的db为只读Drizzle，publicClients另按ponder.config.ts transports做RPC，链上getBalance不等数据库索引余额。
检查结果：SQL schema路径与API数据来源明确；外部RPC结果未当索引表结果。
5. 核查询副本与按链覆盖后收口
serve需与目标start同schema，可以多个serve副本；start负责索引，查询负载分离并不会替它补旧范围。按/status或GraphQL _meta.status看每条chain id/block，block=null表示backfill尚未完成，不能填0；缺实例目标/当前views映射/状态材料时不认定旧结果已经消除。
检查结果：serve的schema与start对应；各链覆盖和null分支有记录，未宣称缺证的切换成功。
怎样确认完成
- 形成输入、官方判定方法、已知结果和未知分支的对照；方法已核，实际运行与本人权限未验证。
常见错误与边界
- 稳定schema名不证明views已指最新表；使用同库不同schema时尤其要核实际目标。
- db prune会删除不活动部署的表/函数/schema，属于维护删除，不能拿来替代本篇只读排错。