单节点Spanner CPU达100%仅支撑近1K QPS问题排查求助

一、排查查询执行计划与主键扫描逻辑 #

• 用EXPLAIN分析SELECT * FROM foo WHERE ID IN(...)语句，确认Spanner是否执行主键点查而非全表/范围扫描。SHA256主键虽能随机分布，但如果Postgres方言下存在类型不匹配、隐式转换（比如ID字段是BYTEA但传入字符串），会导致主键索引失效，触发全表扫描，直接拉高扫描行数与CPU占用。
• 尝试用Spanner原生批量读取API（Go客户端的Read/BatchRead方法）替代SQL的IN查询。SQL IN子句处理多主键时，效率可能不如原生批量读取，尤其当IN列表长度动态变化时。

二、优化客户端实现 #

• 确保会话池高效复用：100个协程不要独占会话，使用GetSession/ReleaseSession逻辑循环利用会话池资源，避免频繁创建销毁会话带来的开销。
• 预编译SQL语句：将SELECT * FROM foo WHERE ID IN(...)预编译为PreparedStatement，避免每次查询重复解析SQL，减少Spanner端的CPU消耗。
• 调整gRPC配置：可显式设置WithNumChannels优化通道数，同时启用gRPC流式复用与连接池，提升请求传输效率。

三、Spanner实例与表结构优化 #

• 检查实例资源节流：在Spanner控制台查看实例监控，确认1000PU的单节点是否存在资源节流（Throttling），是否有备份、统计信息更新等后台任务占用CPU。
• 避免全字段查询：如果表中存在大字段、数组等宽列，SELECT *会导致大量数据传输，增加两端CPU开销，改为只查询所需字段。
• 启用查询缓存：若查询存在重复主键组合，可开启结果缓存减少重复计算（仅适用于只读、数据更新不频繁的场景）。

四、扫描行数异常排查 #

• 查看查询执行详情：在控制台查询监控中定位目标SQL，查看执行计划的扫描逻辑。若为全表扫描则说明索引未生效；若为主键扫描，扫描行数应等于IN子句ID数量，否则需检查主键唯一性（是否存在重复ID数据）。
• 隔离读写流量：测试期间若有写入操作，Spanner的MVCC机制会导致读取时扫描多版本数据，增加扫描行数，确保测试环境为只读状态。

五、其他排查方向 #

• 确认网络环境：确保Go客户端与Spanner实例在同一GCP区域，避免跨区域网络延迟成为瓶颈。
• 分析客户端性能：用Go的pprof工具排查客户端CPU使用率，若客户端CPU也满负荷，可能是序列化/反序列化逻辑低效或协程调度开销过大。

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