为何Google Cloud Spanner首次查询响应时间远慢于查询编辑器运行结果？

你遇到的首次查询耗时高的问题核心是Spanner Python客户端的会话池懒加载机制：
Spanner所有查询都需要通过会话（Session）执行，默认配置下会话池仅在第一次需要使用会话时才会主动向Spanner后端发起RPC请求创建新会话，你性能分析中_pool.get()占用100%耗时正是首次创建会话的RPC开销。后续查询直接复用池内已创建的会话，所以耗时大幅降低。

• 调整会话池配置，提前保留最小会话数
  初始化数据库实例时指定min_sessions参数，让应用启动阶段就完成指定数量会话的预创建，避免请求阶段才创建会话：

  # 初始化时指定会话池最小保留会话数，根据实际业务QPS调整，一般设为峰值QPS的1/10即可
  db = i.database("my-database", pool_opts={"min_sessions": 10})
  

• 应用启动时预热会话池
  初始化完成数据库实例后主动触发会话池填充，完全把会话创建开销移到启动阶段：

  # 数据库初始化完成后执行一次预热
  db._pool.fill()
  

• 全局复用数据库实例
  不要在每次请求中重复创建client、instance、database对象，将db实例设为全局单例复用，保证会话池可以跨请求共享，避免重复初始化池导致反复创建会话。
• 排查本地网络影响
  你当前在本地Mac环境测试跨公网访问Spanner，RPC延迟本身就比云端同区域访问高很多，部署到和Spanner同区域的GAE后，首次创建会话的耗时会大幅降低，结合上述配置优化后基本可以消除首次查询慢的问题。

如果优化后仍有异常，可以排查是否开启了客户端额外的日志/埋点逻辑，或者升级google-cloud-spanner到最新稳定版，排除旧版本客户端的性能bug。

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