Google Cloud 架构框架中的这一文档提供了一些建议，可帮助您优化 Google Cloud 中数据库的性能。
Cloud SQL
以下建议可帮助您优化运行 SQL Server、MySQL 和 PostgreSQL 数据库的 Cloud SQL 实例的性能。
- 对于 SQL Server 数据库，Google 建议您修改特定参数并保留某些参数的默认值。
- 为 MySQL 或 PostgreSQL 数据库选择存储类型时，请考虑 SSD 和 HDD 存储空间之间的费用性能权衡取舍。
- 如需确定和分析 PostgreSQL 数据库的性能问题，请使用 Cloud SQL Insights 信息中心。
- 如需诊断运行 SQL 查询时性能不佳的问题，请使用
EXPLAIN语句。
如需了解详情，请参阅以下文档：
Bigtable
本部分提供了一些建议来帮助您优化 Bigtable 实例的性能。
根据性能要求规划容量
您可以在多个应用中使用 Bigtable，每个应用具有不同的优化目标。例如，对于批量数据处理作业，吞吐量可能比延迟时间更重要。对于响应用户请求的在线服务，您可能需要优先考虑较短的延迟时间，而不是吞吐量。在规划 Bigtable 集群的容量时，请考虑吞吐量和延迟时间之间的权衡取舍。如需了解详情，请参阅规划 Bigtable 容量。
遵循架构设计最佳实践
表可以扩容到数十亿行和数千列，使您能够存储 PB 级的数据。为 Bigtable 表设计架构时，请考虑架构设计最佳实践。
监控性能并进行调整
监控实例的 CPU 和磁盘使用情况，分析每个集群的性能，并查看监控图表中显示的容量建议。
Spanner
本部分提供了一些建议来帮助您优化 Spanner 实例的性能。
选择一个主键以避免热点
热点是指单个服务器，它会被强制处理许多请求。为数据库选择主键后，请遵循架构设计最佳实践以避免热点。
遵循 SQL 编码的最佳实践
Spanner 中的 SQL 编译器会将您写入的每个声明式 SQL 语句转换为命令式���询���行计划。Spanner 使用该执行计划运行 SQL 语句。构建 SQL 语句时，请遵循 SQL 最佳实践以确保 Spanner 使用可获得最佳性能的执行计划。
使用查询选项来管理 SQL 查询优化器
Spanner 会使用 SQL 查询优化器将 SQL 语句转换为高效的查询执行计划。当查询优化器本身发生变化或数据库统计信息更新时，该优化器生成的查询执行计划可能会略有不同。通过使用查询选项，您可以在查询优化器或数据库统计信息发生变化时最大限度地降低性能下降的可能性。
直观呈现和调整查询执行计划的结构
如需分析查询性能问题，您可以使用查询计划可视化工具直观呈现和调整查询执行计划的结构。
使用操作 API 来管理长时间运行的操作
对于某些方法调用，Spanner 会创建长时间运行的操作，可能需要大量时间才能完成。例如，恢复数据库时，Spanner 会创建长时间运行的操作来跟踪恢复进度。为了帮助您监控和管理长时间运行的操作，Spanner 提供了操作 API。如需了解详情，请参阅管理长时间运行的操作。
遵循批量加载的最佳实践
Spanner 支持多种用于批量加载大量数据的选项。批量加载操作的性能取决于分区、写入请求数和每个请求的大小等因素。为了高效地加载大量数据，请遵循批量加载最佳实践。
监控和控制 CPU 利用率
Spanner 实例的 CPU 利用率可能会影响请求延迟时间。后端服务器过载可能会导致较长的请求延迟时间。Spanner 提供了 CPU 利用率指标来帮助您调查高 CPU 利用率。对于性能敏感型应用，您可能需要通过��加计算容量来降低 CPU 利用率。
分析和解决延迟时间问题
当客户端对 Spanner 进行远程过程调用时，客户端库首先会准备 API 请求。然后，该请求会经过 Google Front End 和 Cloud Spanner API 前端，然后再到达 Spanner 数据库。如需分析和解决延迟时间问题，您必须衡量和分析 API 请求遍历的每段路径的延迟时间。如需了解详情，请参阅 Spanner 端到端延迟时间指南。
在数据库达到热状态后启动应用
随着 Spanner 数据库不断增长，它会将数据的键空间划分为分块。每个分块是一系列行，其中包含表的子集。如需平衡数据库的整体负载，Spanner 会单独动态移动各个分块并将其分配给不同的服务器。当分块分布在多个服务器上时，数据库会被视为处于热状态。处于热状态的数据库可以最大限度提高并行性并提升性能。在启动应用之前，我们建议您先使用测试数据负载预热数据库。
后续步骤
查看优化计算、存储、网络和分析资源的性能的最佳实践：