Google Cloud Spanner是一个全球分布式关系型数据库，提供强一致性、水平扩展和高可用性。从架构设计到性能优化，可以按照以下步骤实施：1. 架构设计：选择合适的实例配置（如Regional或Multi-region），设计分片键（Split Key）以均匀分布数据，避免热点；使用Interleaved Tables和Secondary Indexes优化查询路径。2. 数据建模：优先使用复合主键，确保查询基于主键或索引；控制行大小在2KB以内。3. 性能优化：批量写入使用Mutation API，监控CPU和存储利用率，通过调整节点数扩展；使用Read-Only Transactions减少锁争用；实施连接池和查询缓存。完整方案见下文聚合内容。

Google Cloud官方文档 - Spanner入门与架构

Cloud Spanner provides a SQL interface for managing schemata (tables, indexes, and views), writing and querying data, and managing transactions. Spanner is a relational database service that is globally distributed and strongly consistent. Spanner provides horizontal scalability and strong consistency within and across regions, low-latency reads and writes, and automatic multi-site replication and failover.

To get started: Create an instance using gcloud spanner instances create my-instance --config=regional-us-central1 --description="My instance" --nodes=3. Then create a database: gcloud spanner databases create my-database --instance=my-instance. Key architecture: Spanner uses TrueTime for external consistency, with splits (tablets) distributed across zones.

Google Cloud博客 - Spanner架构设计最佳实践

In Spanner, the primary key choice is critical for performance. Choose primary keys that distribute data evenly and match common query patterns. For example, use a hash of user_id combined with timestamp for time-series data to avoid hotspots. Interleaving child tables under parent tables colocates related data, reducing latency for joins.

Multi-region configurations provide higher availability but higher cost. Use them for globally distributed apps. For schema design: Keep rows small (< 2 MB, ideally < 10 KB), limit indexes to high-cardinality columns, and use GIN indexes sparingly as they increase write latency.

Spanner性能优化指南（官方白皮书摘录）

Performance best practices: 1. Batch mutations for writes (up to 20,000 per batch). 2. Use read-write transactions sparingly; prefer read-only scans. 3. Monitor with Cloud Monitoring: Aim for CPU <60%, storage <400 GB/node. 4. Scale by adding nodes or using autoscaling. 5. For high QPS, use Query Optimizer hints and avoid SELECT *. Index covering reduces data scanned.

Query performance troubleshooting: Use EXPLAIN to analyze plans. Common issues: Hotspots from poor key choice (use Key Visualizer), index scans instead of seeks, excessive locking from long transactions (<5s recommended).

实际案例 - 从MySQL迁移到Spanner的架构优化

在迁移项目中，我们将MySQL sharding方案替换为Spanner的原生分片：原主键user_id改为SHA256(user_id) + user_id，确保均匀分布。结果QPS从10k提升到100k+。优化点：引入TTL列自动清理历史数据，使用PGAdapter兼容Postgres客户端；批量导入用Dataflow pipeline，减少了90%加载时间。

社区分享 - Spanner高级性能调优

连接池配置至关重要：使用HikariCP，maxPoolSize=100，idleTimeout=10min。针对OLTP负载，启用 statement cache。备份策略：每日全备 + 增量 PITR。成本优化：用reserved nodes节省30%，监控未用节点并right-size实例。

FAQ

Q: Spanner适合什么场景？
A: 适合需要强一致性、高可用、全球分布的OLTP/OLAP混合负载，如金融交易、电商库存、游戏排行榜。不适合低成本日志存储（用BigQuery更好）。

Q: 如何避免数据热点？
A: 选择高基数分片键，如hash(id)+timestamp；使用Key Visualizer工具检测热点并调整schema。

Q: Spanner的定价怎么算？
A: 按节点数（$0.90/小时Regional）、存储（$0.30/GB/月）、备份、网络出口计费。Multi-region节点$3/小时。

Q: Spanner支持SQL标准吗？
A: 支持ANSI 2011 SQL + Spanner扩展（如ARRAY、STRUCT），兼容Postgres via PGAdapter，但无存储过程（用Cloud Functions替代）。