设置 Cloud SQL for MySQL 实例的最佳实践
虽然您可以在自己的物理机甚至虚拟机上手动部署 MySQL 并选择自行管理，但越来越流行的选择是使用云服务提供商提供的代管式产品，用于负责管理 MySQL 的许多操作方面。
相关文章
最佳做法
Cloud SQL for MySQL 是一项全代管式数据库服务，可帮助您在 Google Cloud 上设置、维护、管理和控制 MySQL 关系型数据库。当您准备好创建 Cloud SQL for MySQL 实例时，可以采用几种方式，包括界面控制台、gcloud CLI、Terraform 和 REST API。您可以按照我们的文档详细了解相关路径，但在本文中，我们将使用界面来说明设置实例的各种最佳实践。
实例信息
选择安全系数高的密码
这是将与实例一起创建的默认“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.5GB 内存。
规划 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.48 MB/GB。使用区域 SSD 时，性能数据类似，不同之处在于每个实例的写入 IOPS 和写入吞吐量较低。
请注意，Cloud SQL 实例支持的存储大小上限为 64TB。
启用存储空间自动扩容功能并监控磁盘增长
Cloud SQL 具有存储空间自动扩容功能，可防止实例耗尽磁盘空间 (OOD)。功能启用后，系统会每 30 秒检查一次存储空间，并在需要时增加增量存储容量。
虽然此功能可防止 OOD，但增加的容量是永久性的，您之后无法缩减实例容量。首先为磁盘大小设置提醒，以便您可以管理和规划存储空间容量。
熟悉加密选项
Cloud SQL 默认会对静态数据进行加密。但是，如果客户管理的加密密钥 (CMEK) 更符合您的需求，您可以选择使用该选项，而不是使用默认的 Google 管理的密钥。
配置连接
评估专用 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)。它们默认处于启用状态，并且在具有多个可用区的实例中是必需的。每天进行自动备份，默认保留政策是七份备份和七天的二进制日志（PITR 需要）。您可以在“高级选项”部分中调整保留政策。
配置数据库标志
数据库标志是转到 my.cnf 文件的服务器配置。有一系列数据库标志可配置，某些代管式标志不可配置。最好在创建实例时查看数据库标志并将其配置为适当的值。由于某些数据库标志不是动态的，因此更改这些标志会触发实例重启。
查看 character_set_server
在 Cloud SQL for MySQL 实例上，v5.6 和 v5.7 的默认 character_set_server 为 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。
查看 time_zone
时区默认为 system_time_zone，即世界协调时间 (UTC)。 如果您想使用其他时区，请通过 default_time_zone 进行设置。此标志采用两种格式：时区偏移量（例如 +08:00）和时区名称（例如美国/洛杉矶）。当时区由时区名称定义时，它会自动调整为夏令时（如果相关）。default_time_zone 标志不是动态的，需要重启数据库实例才能进行更改。
启用慢查询日志
默认情况下，slow_query_log 设置为“关闭”。我们强烈建议您启用慢查询日志，并将 long_query_time 设置为适合应用的阈值。慢速查询日志有助于捕获长时间运行的查询，以执行分析和优化。这些信息不仅有助于单个查询，也有助于整体服务器吞吐量和对意外工作负载的回顾性分析。
这是对 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 中，更改此变量需要重启实例。
对于 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 足够大以满足峰值观察时间段的需求量。
在 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 默认处于停用状态，需要重启才能启用。performance_schema 支持各种插桩，并提供丰富的数据集来分析服务器操作，但同时会降低性能、增加内存费用。 默认插桩会导致约 5% 的性能下降，并且随着插桩的增加而增加。对工作负载进行插桩测试，因为内存消耗可能会增加到 1 GB 或更多。您可以在 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 版本创建的。创建后，您可以选择将副本升级到主实例。
规划灾难恢复
高可用性解决方案可在同一区域内的辅助可用区提供数据冗余。在灾难中，一个区域可能会变得不可用。跨区域读取副本是灾难恢复计划中的强大资源，因为它们可以在需要时提升到主实例。如需了解详情，请参阅文档。
相关产品和服务
Google Cloud 提供旨在满足您业务需求的代管式 MySQL 数据库，可以完成包括弃用本地数据中心、运行 SaaS 应用和迁移核心业务系统在内的各种任务。
