为什么我对Firebase Realtime Database的读取查询速度这么慢？

核心原因 #

• 嵌套数据全量拉取开销过大
  你调用once("value")时会把所有匹配到的n节点的完整嵌套子树全部加载、序列化后返回，每个n节点有60+键、最深5层嵌套，哪怕单节点体积不大，225个节点累计的序列化体积、传输开销、SDK侧反序列化开销就是2-3秒耗时的主要来源。orderByKey本身是默认有索引的，300个节点的过滤操作在RTDB服务端耗时几乎可以忽略，开销基本都在数据处理和传输环节。
• 云函数冷启动/连接建立开销
  无匹配结果时仍有500ms耗时，基本是云函数冷启动或者RTDB连接首次建立的开销：冷启动的函数需要初始化运行环境、加载代码、初始化Admin SDK、和RTDB建立TLS连接并完成鉴权，这一系列步骤本身就需要几百毫秒，和查询逻辑无关。如果你的函数请求量不高、经常被回收，冷启动的占比会非常高。
• 耗时统计包含全链路开销
  你用performance.now()统计的是从发起请求到拿到结果的全链路耗时，包含了云函数到RTDB的网络往返、服务端处理、数据传输、SDK反序列化的全部时间，不是RTDB纯查询的耗时。

优化方案 #

• 数据结构扁平化拆分
  把批量查询需要用到的n节点精简字段单独拆到独立路径存储，比如/history_summary/${userId}/${n}下只存查询需要的核心字段，需要查看单条记录详情时再单独拉取/history/${userId}/${n}的全量数据，大幅降低批量查询时的数据传输量。
• 按需拉取字段
  如果使用的是最新版Admin SDK，可以在查询后链式调用.select('所需字段1', '所需字段2')，仅拉取需要的字段，避免无关的嵌套数据被返回。
• 降低冷启动影响
  将Admin SDK的初始化逻辑放在函数全局作用域，不要放在函数处理逻辑内部，复用已有连接；如果对延时要求高，可以给云函数配置预留实例，消除冷启动开销。
• 优化无结果查询逻辑
  如果只是需要判断是否存在匹配的节点，不要直接拉取全部匹配结果，追加.limitToFirst(1)，只要查到1条匹配结果就会返回，无结果的查询耗时会大幅降低。

内容的提问来源于stack exchange，提问作者Wing