先标明报表到底查询哪一层
区块链大数据平台常把交易记录与统计图表放在同一页面，但它们未必由同一个数据服务直接返回。Fabric文档为看板和聚合分析提出一种做法：根据区块或链码事件，把数据送入适合分析的链下数据库。这为查询与交易处理分工提供了思路，不代表每个平台已经采用或正确实现。
阅读架构说明时，应找出数据从哪里来、分析库处理到哪里、何时刷新。假设账本已有一条新记录，而报表尚未同步，两个页面暂时不同不能仅凭这一点判断账本丢失。反过来，分析副本中的一行数据也不应不经核对就当成已生效交易；同步位置和来源说明需要保留。
写了索引名称不等于实际使用
CouchDB的_find接口说明，查询可以使用自定义索引，缺少合适索引且允许回退时也可能采用内置索引。use_index是请求使用某个索引的提示，并非无条件保证；若该索引不适合查询条件，可能发生回退，响应中的warning会说明相关情况。
因此，检查查询报告不能只截取请求里写了哪个名称。还应核对响应警告以及查询解释所反映的实际选择，再判断索引是否发挥作用。这里说的是所引CouchDB接口的行为，不假设所有区块链平台都暴露同样字段，也不要求对正在运行的生产数据库临时改配置。
返回得少不代表数据库工作得少
同一接口的执行统计分别列出检查过的索引键、读取过的文档、返回结果数量和数据库测得的执行时间。返回十行只是结果规模；若期间检查了大量候选资料，查询工作量仍可能很大。不能仅凭页面只显示十行就宣称访问成本很低。
可把相同筛选条件下的检查量、返回量和执行时间一起记录，并注明数据集及软件版本。这个比较表是本文的阅读建议，不是性能认证。数据库内部执行时间也不是用户点击到页面完整显示的全部耗时；网络、服务处理和前端渲染不应被无声省略。
分页属于查询流程，不是交易提交凭证
CouchDB分页使用bookmark继续请求，文档要求保持选择条件一致，并提醒有书签不保证还有更多结果。Fabric链码分页则由其专门API管理，不能以为在底层查询里写limit就能替代Fabric的pageSize。阅读文档时要先确认调用层次，避免把两套接口参数混在同一结论里。
Fabric还将分页API限定为只读事务使用，提醒JSON查询结果在链码执行至提交之间未必保持稳定。因而，把一页报表查出来与把其中所有对象完成一次更新是两件事。本篇未运行查询或测试平台，最终应分别验收数据同步、查询响应和交易提交，不能用大屏流畅度替代这些独立结果。