您可以通过多种方式迁移到 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 天。在大多数情况下，对于从 RDS 到 Cloud SQL 的大多数中小型迁移，七天就足够了。在此类情况下，用户可以利用记录完善的流程，其中涉及创建托管 RDS 副本。然后执行一些操作来“破坏”复制，例如使副本可写并删除一行，或者在主实例上注入某种进入二进制日志并中断复制的“毒药”事务。只要副本仍然需要二进制日志，RDS 自动化功能就不会完全清除这些日志（尽管在 RDS “终止”损坏的复制流之前似乎有 30 天的总体限制）。

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

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

例如，存储过程可能具有超特权定义符来运行 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 中修改，或者具有不同于本地或其他云服务提供商的默认值。