您可以通过多种方式迁移到 Cloud SQL 上的 MySQL。给定源的迁移策略取决于若干因素，包括数据库大小、停机时间预期以及工程师执行迁移的经验。我们来了解一些最常见的迁移策略。

如果您正在迁移一个只有几 GB 大小或包含静态数据的小型数据库，最简单的方法是通过 mysqldump 实用程序转储数据库。将转储文件上传到 Cloud Storage，然后按照有关使用 SQL 转储文件导出和导入的文章中的说明将其导入 Cloud SQL 实例。

由于转储文件包含逻辑 SQL 语句，因此这种方法的一个优点是，可以在将转储文件加载到 Cloud Storage 之前对其进行修改。但是，鉴于特定的 Cloud SQL 限制，请避免在转储文件中包含任何可能破坏导入的内容，如导入和导出数据的最佳实践中所述。

如果要迁移多个 MySQL 实例或者进行更大规模的迁移，最好使用 Database Migration Service (DMS)。该服务提供各种迁移路径，包括向 MySQL 的同构和异构迁移路径，还支持将 SQL Server 和 PostgreSQL 作为迁移目标位置。

对于大多数中型到大型数据库迁移，使用 DMS 应该已足够。DMS 可能不适用的情形包括超大型数据库（例如数 TB 大小），或者您的 MySQL 工程师具备复制知识，并且希望使用原生 MySQL 复制对迁移过程进行更精细的控制。

如果最大限度地减少停机时间是迁移期间的首要任务，并且您的团队中有经验丰富的 MySQL 工程师，那么可以选择使用基于原生二进制日志的复制从外部源 (ES) 进行复制。这种方法利用 Cloud Storage 导入等方法导入数据库的基准快照。

然后，您可以使用 Cloud SQL 实例上已有的一组预先创建的存储过程，配置从源实例到目标 Cloud SQL 实例的 MySQL 复制。如需查看完整说明，请参阅标题为使用自定义导入设置从大型外部数据库复制的文章。

使用基于二进制日志的复制功能进行迁移时，一个关键细节是源实例上的二进制日志会一直可用，直到目标 Cloud SQL 实例不再需要为止。运行本地 MySQL 或自行管理的 MySQL 时，可以配置 expire_logs_days 等参数来控制二进制日志的完全清除。但是，其他云供应商托管式服务在二进制日志保留方面有自己的限制。

例如，Amazon Relational Database Service (RDS) 可通过存储过程名称 mysql.rds_set_configuration 配置二进制日志保留。保留期限最长为 7 天。在大多数情况下，7 天就足以完成大多数从 RDS 到 Cloud SQL 的中小型迁移。在这种情况下，用户可以利用有详尽文档记录的流程，其中涉及创建托管式 RDS 副本。然后执行一些操作来“中断”复制，例如使副本可写入并删除行，或在主实例注射某种“毒药”事务，以写入二进制日志并中断复制。只要副本仍需要二进制日志，RDS 自动化功能就不会完全清除这些日志（不过，在 RDS “终止”中断的复制流之前，似乎会有 30 天的总体限制）。

另一种解决方法是使用 mysqlbinlog 客户端将二进制日志下载到另一个中间 MySQL 实例上，以防止过早完全清除二进制日志。例如，在 RDS 中，有一个名为 mysql.rds_set_configuration 的存储过程，可设置以小时为单位的保留期限，以确保二进制日志在主机上保留足够长的时间可供下载。在这种情况下，您不需要将 MySQL 实例设置为中间实例，因为任何服务器（如“Binlog Server”）看起来就像 MySQL 实例一样，都可以存储和转发二进制日志。

MySQL 在最流行的关系型数据库系统中独一无二，因为它支持多个可插入存储引擎。MySQL 最初支持一个名为 MyISAM 的存储引擎，在 MySQL 8.0 之前，大多数系统表都使用此存储引擎。但是，MyISAM 缺乏对事务的支持，在系统突然关闭或数据库崩溃时不具备崩溃安全性。

此后，由于 InnoDB 具有崩溃安全架构和对事务的支持，因此它已成为大多数 MySQL 用户表的存储引擎。MySQL 社区中还有一些常见的其他存储引擎（在本地和其他云服务提供商），其中包括：

• 归档 - 以高度压缩的格式存储数据，以进行归档
• CSV - 以英文逗号分隔格式 (CSV) 存储数据，用于常规查询日志和慢查询日志的日志记录表
• 内存 - 将表存储在内存中

就 Cloud SQL 而言，我们需要一个事务性且具备崩溃安全性的存储引擎，以支持复制和时间点恢复等增值功能。因此，迁移到 Cloud SQL 的所有用户表都需要使用 InnoDB 存储引擎，或者在迁移过程中转换为 InnoDB。

在执行从外部来源到 Cloud SQL 的原生 MySQL 复制时，这一点尤为重要。虽然 Cloud SQL 不允许用户通过 CREATE TABLE 等数据定义语言 (DDL) 命令直接在 Cloud SQL 实例上创建 MyISAM 表，但目前 MyISAM 表可以从外部源复制到 Cloud SQL。

但是，在 Cloud SQL 上导入这些 MyISAM 表可能会导致以后在复制、时间点恢复和故障切换等操作期间出现稳定性和可靠性问题。因此，建议在执行迁移之前将所有 MyISAM 用户表转换为 InnoDB。

以下查询将列出所有非系统 MyISAM 表。

作为一项托管式服务，MySQL for Cloud SQL 不允许用户账号的 SUPER 权限。这与大多数本地安装的 MySQL 不同，这种安装方式允许根用户拥有此类权限。同样，大多数其他云服务提供商也不在托管式 MySQL 环境中提供此 SUPER 权限。

无论在什么情况下，Cloud SQL 用户都是一个名为“root”@“%”的默认 MySQL 用户，该用户拥有 MySQL 提供的大多数特权，除了那些会影响 Google 管理服务的能力的特权，例如上述 SUPER 以及 FILE 和 SHUTDOWN。如需详细了解 Cloud SQL 中提供的使用特权，请参阅有关 MySQL 用户的文档。

准备迁移时，请查看源实例上的所有用户账号。例如，针对每个用户运行 SHOW GRANTS 命令，以查看当前的一组权限，并了解是否有任何权限在 Cloud SQL 中受到限制。同样，Percona 提供的 pt-show-grants 工具也可以列出授权。

在迁移具有 DEFINER 属性的数据库对象时，Cloud SQL 中对用户权限的限制可能会影响迁移。存储过程、触发器、用户定义的函数和视图通常就属于这种情况。如果源实例上数据库对象的 definer 是具有 Cloud SQL 不支持的权限的用户，则在迁移期间或之后可能会出现此问题。

例如，存储过程可能具有超级特权 definer 来运行 SQL 命令，例如更改 Cloud SQL 中不允许的全局变量。对于此类情况，可能需要重写存储过程代码，或者将非表对象（如存储过程）作为单独的迁移步骤进行迁移。

我们的文档中包含一个标题为包含带有 DEFINER 子句的元数据的 MySQL 导入和迁移作业的部分，其中详细介绍了与数据库对象的定义者子句相关的其他问题。

由于前面提到的用户特权限制，用户无法原生调用 SET GLOBAL 命令来更改数据库参数。Cloud SQL 提供了一组预定义的“标志”，可通过界面控制台、gcloud CLI 和 REST API 对其进行修改，从而修改参数。

如需查看 MySQL 支持的 Cloud SQL 标志的完整列表，请参阅公开文档中支持的标志部分。在迁移到 Cloud SQL 之前，请先查看支持的标志列表与来源环境中当前使用的标志列表。例如，一种好的做法是创建一个 CPU 和内存设置与源实例类似的测试 Cloud SQL 实例，然后对源实例和 Cloud SQL 实例运行 SHOW GLOBAL VARIABLES 并比较差异。

与 Cloud SQL for MySQL 相比，在本地或云提供商中可以具有不同设置的常见标志包括：

• 字符集和排序规则设置，例如 character_set_server 和 collation_server。默认值可能会因安装而异，并会导致存储空间和性能上的差异。例如，latin1 与 utf8。
• 二进制日志设置，例如 binlog_format。Cloud SQL 目前仅支持二进制日志中的基于行的日志记录。
• 高级复制设置。例如，Cloud SQL 不支持 复制过滤条件 参数，例如 replicate-do-table 和 replicate-do-db。
• 高级 InnoDB 设置。Cloud SQL 支持修改大多数 InnoDB 相关参数，例如通过更改 innodb_buffer_pool_size 来调整 InnoDB 缓冲区池的大小。但是，还有一些更精细的 InnoDB 设置无法在 Cloud SQL 中修改，或者采用与本地或其他云服务提供商不同的默认值。