设置 Cloud SQL for MySQL 实例的最佳实践

Cloud SQL for MySQL 是一项全托管式数据库服务，可帮助您在 Google Cloud 上设置、维护、管理和控制 MySQL 关系型数据库。准备好创建 Cloud SQL for MySQL 实例后，您有几种选择，包括界面控制台、gcloud CLI、Terraform 和 REST API。您可以参阅我们的文档，详细了解各个路径；但在本文中，我们将通过界面进行举例说明，介绍设置实例的各种最佳实践。

选择安全系数高的密码

这是将随实例创建的默认“root”@”%”数据库用户的密码。如果您打算保留根用户作为管理员用户，请务必在此处选择一个安全系数高的密码。出于安全问题考虑，最好使用不太常见的管理员用户，而不是“root”。请参阅“管理数据库用户”部分。

创建实例级密码政策

密码政策功能可增强数据库安全性。它可让您配置有关密码长度、复杂度、有效期和限制重复使用的政策。如需了解详情，请参阅强化 MySQL 实例。

建议使用 8.0 以提升性能

Cloud SQL MySQL 支持多个 8.0 次要版本，其中 v8.0.26 是当前默认版本。一系列机器类型的基准测试显示 8.0 默认版本比 5.7 和 5.6 版本有更好的查询吞吐量。  

不要将生产实例置于最新的正式版上 

尽管 Oracle 和 Cloud SQL 进行了所有测试，但 MySQL 的更新版本尚未经过复杂的真实场景的全面审查。因此，我们建议您将生产实例保留为稳定版，并使用开发和预演实例在 Cloud SQL for MySQL 中测试最新的次要版本升级。

为生产实例配置多个可用区

Cloud SQL for MySQL 作为高可用性解决方案，通过自动故障切换到第二个可用区，从而实现区域可用性。为获得最佳可用性，请为生产实例配置多可用区选项，以便能够自动拥有每日备份和时间点恢复（如需了解详情，请参阅“备份时间表”部分）。

评估当前的 CPU/内存用量，以便做出明智的迁移决策

将现有实例迁移到 Cloud SQL 时，当前工作负载可以帮助您选择适当的虚拟机大小。

• CPU：在正常工作负载条件下，您的 CPU 使用率是多少？工作负载峰值如何？实例受 CPU 限制还是受 I/O 限制？如果用户和/或系统的 CPU 百分比相对较高，则表示工作负载受 CPU 限制。如果 I/O 的百分比相对较高，则表示工作负载受 I/O 限制。
• 内存：同样，实例的正常内存用量和峰值内存用量是多少？

作为参考，Cloud SQL for MySQL 中的 1 个 vCPU 最多可支持 6.5 GB 的内存。

计划 20%-50% 的额外 CPU 和内存空间

即使在一般稳定的实例中，也请计划至少 20% 的额外 CPU 和内存空间来应对计划外的高峰。这对于不断增长的企业而言更重要，不妨考虑再增加 50%。

Cloud SQL 可让您轻松升级机器类型。请注意，升级会导致停机。

使用 SSD 提高数据库性能

Cloud SQL for MySQL 提供 HDD 这一经济实惠的存储方案，但如果您知道自己需要高性能数据库，请选择 SSD 方案。以下是 I/O 性能的比较。

计划在存储容量方面均衡性能与成本

磁盘 IOPS 和吞吐量与永久性磁盘大小相关。较大的容量可在实例限制范围内提供较高的 IOPS 和吞吐量。

对于 SSD，可用区级和区域级配置会影响性能。如需了解详情，请参阅可用区级和区域级 SSD 性能数据。如果您选择了多个可用区的可用性，请参阅区域 SSD 性能数据。简而言之，读写 IOPS 均为 30/GB，吞吐量为 0.48MB/GB。使用区域 SSD 时，性能数据类似，但每个实例的写入 IOPS 和写入吞吐量较低。

请注意，一个 Cloud SQL 实例支持的最大存储空间大小为 64TB。

启用存储空间自动扩容功能并监控磁盘增长情况

Cloud SQL 提供存储空间自动扩容功能，以防止实例耗尽磁盘空间 (OOD)。启用该功能后，系统会每 30 秒检查一次存储空间，并在需要时增加增量存储容量。

虽然此功能可防止 OOD，但增加的容量是永久性的，您之后无法缩减实例大小。首先针对磁盘大小设置提醒，以便管理和规划存储容量。

熟悉加密选项

默认情况下，Cloud SQL 会加密静态数据。不过，您可以选择使用客户管理的加密密钥 (CMEK)，而不是默认的 Google 拥有和 Google 管理的密钥（如果 CMEK 更符合您的需求）。

评估专用 IP 地址和公共 IP 地址之间的权衡

专用 IP 地址和公共 IP 地址是指网络中设备使用的地址类型。与公共 IP 地址相比，专用 IP 地址可提高网络安全性并缩短网络延迟时间。 但是，专用 IP 地址需要额外的 API 和 IAM 配置来设置，有时还需要公共 IP 地址。如果您知道需要使用公共 IP 地址但想要提高安全性，则可以选择要求设置已获授权的网络或使用 Cloud SQL Auth 代理。

考虑使用 Cloud SQL Auth 代理实现安全连接

Cloud SQL Auth 代理可提供对 Cloud SQL 实例的安全访问，而无需配置 SSL 或已获授权的网络。应用与 Auth 代理客户端进行通信，该客户端在本地环境中运行，并使用安全隧道与 Cloud SQL 实例上的代理服务器进行通信。

启用备份和时间点恢复，并查看您的保留政策 

定期数据备份和可验证的数据恢复对于健康的数据库管理至关重要。这些做法在数据损坏或意外数据操作等情况下非常有用，而这两种情况都无法通过高可用性来缓解。

Cloud SQL 提供自动备份、备份验证和时间点恢复 (PITR)。它们默认启用，并且在具有多个可用区的实例上是必需的。自动备份每天进行一次，默认保留政策为 7 个备份副本和 7 天的二进制日志（对于 PITR 是必需的）。您可以在“高级选项”部分调整保留政策。

数据库标志是会转到 my.cnf 文件的服务器配置。有一系列 db 标志是可配置的，某些托管式标志是不可配置的。最好在创建实例时查看数据库标志并将其配置为适当的值。因为某些数据库标志不是动态的，这意味着更改这些标志会触发实例重启。

查看 character_set_server 

在 Cloud SQL for MySQL 实例上，默认 character_set_server 在 v5.6 和 v5.7 上为 utf8，在 v8.0 上为 utf8mb4。character_set_server 将 character_set_client、character_set_connection、character_set_database 和 character_set_results 设置为相同的值。对于 character_set_system，在 v8.0 上默认为 utf8mb3。

如果要迁移实例，并且当前配置使用其他字符集（例如 latin1），请务必在新实例上明确设置 character_set_server。

查看时区

时区默认设置为 system_time_zone，即世界协调时间 (UTC)。如果您想使用其他时区，请通过 default_time_zone 进行设置。此标志采用两种格式：时区偏移量（例如 +08:00）和时区名称（例如 America/Los_Angeles）。如果时区是由时区名称定义的，则系统会自动将时区调整为夏令时（如果相关）。default_time_zone 标志不是动态的，需要重启数据库实例才能进行更改。

启用慢查询日志 

默认情况下，slow_query_log 设置为“OFF”。我们强烈建议您启用慢查询日志，并将 long_query_time 设置为对应用有意义的阈值。慢查询日志有助于捕获长时间运行的查询，以用于分析和优化。这些信息不仅有助于单个查询，还有助于提升整体服务器吞吐量和对意外工作负载的回顾性分析。

查看 innodb_buffer_pool_size

这是提升 InnoDB 性能的最有效配置。内存中可缓冲的数据越多，服务器性能就越好。同时，还需要为全局缓冲区和线程级动态缓冲区预留足够的内存。

在 Cloud SQL 中，innodb_buffer_pool_size 标志的默认值、最小允许值和最大允许值取决于实例的内存，如文档中所述。

良好的 innodb_buffer_pool_size 不一定包含所有数据，只需包含经常访问的数据。反映缓冲区池效率的状态变量是 Innodb_buffer_pool_reads/Innodb_buffer_pool_read_requests。Innodb_buffer_pool_read_requests 是逻辑读取请求的数量，Innodb_buffer_pool_reads 是未满足缓冲区池且必须从磁盘读取的逻辑读取数。在数据完全位于缓冲区池的理想情况下，Innodb_buffer_pool_reads/Innodb_buffer_pool_read_requests 的比率将接近零。监控这些变量可让您了解 InnoDB 缓冲区池的效率。如果 innodb_buffer_pool_size 已达到允许的最大值，但缓冲区池效率不理想，且应用出现查询性能问题，请考虑升级实例以增加内存。

此变量在 MySQL v5.7 和 v8.0 中会变为动态变量，而在 v5.6 中，更改此变量需要重启实例。

查看 innodb_log_file_size

在 8.0.30 之前，innodb_log_file_size 和 innodb_log_files_in_group 不是动态的，并且更改 innodb_log_file_size 需要彻底的关停操作。8.0.30 中引入了 innodb_redo_log_capacity 来取代 innodb_log_file_size 和 innodb_log_files_in_group。  

Cloud SQL for MySQL 实例配置为 innodb_log_file_size=512MB、innodb_log_files_in_group=2（或 innodb_redo_log_capacity=1GB）。这让 InnoDB 可在缓冲区池中保存更多更改，而无需同步到磁盘，从而提高服务器性能。大型重做日志文件的缺点是崩溃恢复时间延长。根据实例的高可用性要求和设置，此决策需要在性能和可用性之间取得平衡。

通常，我们建议让重做日志文件具有足够大小，以容纳一小时写入活动的数据量。衡量方式的一种方法是，全天观察 Innodb_os_log_written，然后确保 innodb_log_file_size * innodb_log_files_in_group 足够大，足以应对观察到的高峰时段。

查看 innodb_log_buffer_size 

在 MySQL v5.6 和 v5.7 中，innodb_log_buffer_size 不是动态的，更改它需要重启实例。因此，最好在初始化时进行设置。

如果 innodb_log_buffer_size 足够大，能够容纳整个事务，则在事务执行期间，不会额外刷新磁盘。默认情况下，innodb_log_buffer_size 设为 16MB，这通常已经足够。不过，若要了解大型事务是否需要更大的缓冲区，请在发出大型事务时监控 Innodb_log_waits 状态变量。如果 innodb_log_buffer_size 太小且需要等待刷新，则 Innodb_log_waits 会增加 1。

随时调整动态变量

某些与性能相关的数据库标志是动态的，例如：table_open_cache、thread_cache_size。 开始时先使用正确的大小，但建议您建立测量结果并根据需要进行调整。

table_open_cache 用于计算打开的表数量。有足够的缓存有助于缩短表的打开时间，从而提高查询性能。状态变量 Opened_tables 会显示已打开的表的数量。如果 Opened_tables 不断增加，请考虑增加 table_open_cache。

thread_cache_size 适用于缓存线程，以便在客户端断开连接后重复使用。如果实例需要同时有大量新连接，请设置更大的大小。状态变量 Threads_created 和 Connections 的比率显示了线程缓存的效率。比率越低越好。

保守地使用每个线程的内存标志

存在会影响查询性能的线程级内存缓冲区，例如 tmp_table_size、max_heap_table_size、join_buffer_size、sort_buffer_size等。这些变量同时具有全局范围和会话范围。全局范围用于为所有新连接设置每个线程的值，而会话范围适用于当前会话中的后续查询。为此类设置使用更大的内存有助于提升查询性能。但是，由于它们是动态的，并且会为每个线程分配一个或多个，因此可能会导致内存不足 (OOM)。

最好为全局值使用适中的数值，并为特定会话预留较大的数值，以便以可控方式取得更好的效果。

考虑 performance_schema 

在 MySQL v8.0.26 之前，performance_schema 默认为“OFF”，并且需要重启以将其开启。performance_schema 支持各种插桩，并提供丰富的数据用于分析服务器操作，但性能会受到影响，内存消耗量也会增加。默认插桩会导致性能下降约 5%，并且随着更多插桩的添加，下降幅度还会更大。使用工作负载对插桩进行基准测试，因为内存消耗量可能会增至 1GB 或更多。您可以在 memory_summary_global_by_event_name 表中观察此内存消耗情况。

创建 Cloud SQL 实例后，可以使用一个数据库用户，即 'root'@'%'。您可能需要创建其他数据库用户。

限制用户对所需操作的访问权限

始终限制用户访问最基本的必需资源。

通过 MySQL CLI 创建用户时，您需要明确授予权限。

通过 Cloud 控制台创建用户时，该用户将拥有与 'root'@'%' 用户相同的权限。在 MySQL v5.6 和 v5.7 中，默认权限包括所有具有授权选项的权限，但 SUPER 和 FILE 权限除外。在 v8.0 中，用户拥有动态权限，虽然 SUPER 和 FILE 权限仍然受限，但是用户可以拥有更多管理员角色（例如，APPLICATION_PASSWORD_ADMIN、CONNECTION_ADMIN、ROLE_ADMIN、SET_USER_ID 和 XA_RECOVER_ADMIN）。您需要通过 MySQL CLI 撤消任何不必要的权限。在 v8.0 实例上，启用了 partial_revokes 变量。

考虑将 'root'@'%' 替换为特定管理员用户

'root'@'%' 用户是默认且最受欢迎的超级用户，因此经常成为黑客的攻击目标。我们建议您创建自己的管理员用户，并为其授予与 'root'@'%' 用户相同的一组权限，然后将其替换掉，以提高安全性。

监控和跟踪数据库操作和系统资源的各个方面非常重要。通过它，您可以查看和分析实例随时间的运行状况，这也有助于进行资源规划。

• Cloud 控制台概览页面提供了核心指标列表。
• Cloud Monitoring 提供了其他指标。您可以为数据库实例创建一个包含所选指标的信息中心。在 Cloud 控制台左上角的导航菜单中，选择“操作”-->“监控”，以访问 Cloud Monitoring。
• 使用 Cloud SQL 中的 Query Insights 进行查询性能分析。其概览部分显示按数据库、用户或客户端地址划分的 CPU 负载。CPU 使用率也会细分，以显示 I/O 等待和锁定等待。它还会按查询摘要列出热门查询。对于每个查询摘要，您都可以查看平均执行时间、查询数量以及扫描和返回的平均行数。这些指标非常有助于找出要优化的热点和查询。
• 您还可以使用自有的监控工具和/或第三方工具作为补充。主要目标是了解可能影响服务器和查询优化及问题排查的数据库操作。

适当的提醒对服务器的运行状况至关重要。它们有助于防止服务中断，例如由于 CPU 饱和度而导致内存不足 (OOM) 或系统暂停。

如果您使用 Cloud Monitoring，则可以创建基于指标的提醒。如需了解详情，请参阅相关文档。

如果您使用其他监控工具，请务必配置提醒。

如需扩缩读取，请考虑添加读取副本。您可以使用 HAProxy、ProxySQL 或其他负载均衡器，在多个读取副本之间分配读取。

Cloud SQL 还支持链式复制，相关信息请参阅级联副本。  

使用与主实例相同的 MySQL 版本创建读取副本。创建后，您可以选择将副本升级为主实例。

高可用性解决方案在同一区域内的次要可用区提供数据冗余。如果发生灾难，一个区域可能不可用。跨区域读取副本是灾难恢复计划中的一项强有力的资源，因为可以在需要时将其提升为主实例。如需了解详情，请参阅文档。