MySQL 架构迁移是一项新功能，允许用户迁移数据库、表、视图、触发器、事件、存储过程和函数等对象的架构。 此功能适用于在开始迁移之前自动执行准备目标数据库所需的一些工作。
当前实现
在当前实施中，用户可以在配置 DMS 迁移项目时，在“选择服务器对象”部分下的“选择数据库”选项卡中选择要迁移的服务器对象（视图、触发器、事件、例程）。 此外，他们还可以在“选择数据库”部分下选择要迁移其架构的数据库。
若要迁移表对象的架构，请导航到 “选择表 ”选项卡。在选项卡填充之前，DMS 将从源和目标上的所选数据库提取表，然后确定表是否存在并包含数据。 如果在源数据库中选择的表不存在于目标数据库中，则默认会选中“迁移架构”下的框。 对于确实存在于目标数据库中的表，会有一条备注指出所选的表已包含数据并将被截断。 此外，如果目标服务器上的表架构与源上的架构不匹配，则在迁移继续之前会删除该表。
继续前往下一个选项卡时，DMS 会验证你的输入，并确认所选表是否匹配（前提是选择的这些表没有架构迁移输入）。 验证通过后，即可开始迁移方案。
开始迁移后，随着迁移的进行，每个表都会先创建，然后再将其数据从源迁移到目标。 除了触发器和视图是在数据迁移完成后迁移之外，其他对象都是在数据迁移之前为表创建的。
架构迁移的工作原理
MySQL 的 SHOW CREATE 语法支持架构迁移，以便从源中收集对象的架构信息。 将对象架构从源迁移到目标时，DMS 会处理输入并单独迁移对象。 DMS 还会包装查询提供给 SHOW CREATE 创建查询的排序规则、字符集和其他相关信息，然后处理到目标。
在迁移任何数据之前，会先迁移例程和事件。 表的数据在每个表的架构迁移后立即开始移动。 触发器在数据迁移部分之后迁移。 对于视图，由于 MySQL 会验证视图的内容，并且可以依赖于其他表，因此 DMS 会在开始数据库数据移动之前先为视图创建表，然后删除临时表并创建视图。
查询源和目标时，如果发生暂时性错误，DMS 会重试查询。 但是，如果发生 DMS 无法恢复的错误（例如，在执行版本升级迁移时语法无效），DMS 会失败，并在完成时报告该错误消息。 如果在创建表时失败，则不会迁移该表的数据，但会尝试其他迁移选定表的数据和架构。 如果事件、例程或创建视图临时表时发生不可恢复的错误，则迁移在运行所选表以及在数据迁移部分之后迁移的对象之前将失败。
由于为视图创建了临时表，因此如果迁移视图失败，临时表将保留在目标上。 修复基础问题并重试迁移后，DMS 会先删除该表，然后再创建视图。 或者，如果选择在将来的迁移中不对视图使用架构迁移，则需要在手动迁移视图之前先手动删除临时表。
先决条件
为了成功完成架构迁移，请确保满足以下先决条件。
READ对源数据库的权限。SELECT用于从数据库中选择对象的权限用户若要迁移视图，必须具有
SHOW VIEW权限。如果迁移触发器，用户必须具有
TRIGGER权限。如果要迁移例程（过程和/或函数），必须在例程的 definer 子句中命名用户。 或者，根据版本，用户必须拥有以下特权：
对于 5.7，有权
SELECT访问mysql.proc表。对于 8.0，具有
SHOW_ROUTINE特权，或具有在包含例程的范围内授予CREATE ROUTINE、ALTER ROUTINE或EXECUTE特权。
如果迁移事件，用户必须具有
EVENT要从中显示事件的数据库的权限。
限制
迁移非表对象时，DMS 不支持重命名数据库。
迁移到启用了 bin_log 的目标服务器时，应启用 log_bin_trust_function_creators 以允许创建例程和触发器。
目前不支持迁移对象的 DEFINER 子句。 源上具有定义器的所有对象类型都将被删除，迁移后，表的默认定义器将设置为用于运行迁移的登录名。
如果版本兼容性发生重大更改，某些版本升级将不受支持。 有关版本升级的详细信息，请参阅 MySQL 文档。
目前只能在数据移动过程中迁移架构。 如果未为数据移动选择任何内容，则不会发生架构迁移。 如果选择了某个表来进行架构迁移，则该表将被选择用于数据移动。