Cloud Spanner表特定范围出现热点：是否因架构或查询导致？

Cloud Spanner的特定范围热点问题，基本都和架构设计（核心是主键、索引）或读写模式直接相关，结合你已经定位到热点范围的情况，以下是具体分析：

架构设计层面的可能问题 #

• 主键前缀单调有序：如果主键用了自增ID、连续时间戳这类单调递增/递减的字段作为前缀，所有新写入的记录都会集中到Spanner的同一个（或连续几个）分片上——因为Spanner是按主键范围分片的，单调主键会把所有流量导向最新的分片，直接形成热点。比如订单表用order_id BIGINT AUTO_INCREMENT做主键，新订单全往同一个分片写，负载必然集中。
• 热点范围对应高频业务数据段：如果你的热点范围刚好是业务上高访问的数据集，比如热门商品的订单记录、高活跃用户的行为数据，这些数据的主键集中在某个区间，所有针对它们的读写都会打在同一个分片上，超出分片的处理能力就会出现热点。
• 二级索引设计缺陷：如果二级索引的前缀列存在高度集中的取值（比如状态列只有ACTIVE/INACTIVE，而90%的查询都针对ACTIVE），索引会按这个前缀列的取值分片，导致ACTIVE对应的索引分片成为热点——所有查询都会扫描这个索引分片，造成负载集中。

查询/写入模式层面的可能问题 #

• 高频集中读写同一范围：短时间内大量请求都命中同一个主键区间，比如批量导出某小时的所有订单、高频更新某个热门商品的库存记录，这类操作会把流量全部压在对应的分片上，形成热点。
• 未合理利用分片键的查询：如果查询时不指定主键前缀，或者用了过大的范围查询且刚好覆盖热点分片，会导致Spanner反复扫描该分片；甚至有些看似分散的查询，实际大部分结果都来自热点分片，也会间接推高该分片的负载。
• 批量操作不合理：比如批量插入大量主键落在同一范围的记录，或者批量更新同一区间的多条数据，这类操作会瞬间把分片的CPU、IO打满，触发热点。

快速排查方向 #

• 先检查主键结构：确认是否有单调有序的字段作为主键前缀，或者热点范围的主键是否有明显的集中特征（比如都是某个用户ID的记录）。
• 统计读写操作日志：找出命中热点范围的高频查询/写入语句，看是否有重复的大范围查询、单点高频更新这类操作。
• 查看Spanner监控：聚焦热点分片的CPU利用率、读写QPS指标，确认负载来源是读还是写，再针对性排查。

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