如何判断数据迁移任务可以停止？
在手动结束迁移任务之前，您需要确认完成以下几点：
至少有过一次完整的数据对比。
完成业务割接：
先中断业务（如果业务负载非常轻，也可以尝试不中断业务）。
在源数据库端执行如下“show processlist”语句（以MySQL为例），并观察在1-5分钟内若无任何新会话执行SQL ，则可认为业务已经完全停止。
实时同步时延为0，并稳定保持一段时间；同时，您可以使用数据稽查功能，进行割接前的最后一次数据级对比，耗时可参考之前的对比记录。
确定系统割接时机，业务系统指向目标数据库，业务对外恢复使用。
结束迁移任务，该操作仅删除了迁移实例，迁移任务仍显示在任务列表中，您可以进行查看或删除。
DTS如何迁移MySQL中的存储过程？
DTS在对MySQL的存储过程进行迁移时，会做一些特殊处理。具体说来包含以下几项：
变更Definer
DTS完成MySQL的存储过程迁移后，会将它的Definer变更为当前实施迁移的用户。也就是说，假设原始存储过程在源库的Definer为userA，实施本次迁移的用户为userD，则迁移完成后目标端该存储过程的Definer会变成userD。
变更Invoker
续上面，存储过程迁移至目标端之后，原来源库的userA在目标端会变成Invoker，只具备调用权限，不再具备针对该存储过程的管理权限。如果需要维持userA的Definer属性，请手工在目标端执行变更。
如何确认增量迁移/同步过程中源库数据变更已结束？
要确认增量迁移/同步过程中，源库数据变更是否已终止，可以通过如下2个方式实现：
方式一：通过查看DTS增量迁移/同步位点的变化情况
登录天翼云官网门户，进入DTS控制台页面。通过“数据迁移/同步列表”->“实例管理”->“实例详情”->“迁移/同步详情”->“增量数据迁移/同步”查看当前任务的运行情况。
刷新页面，如果源库、DTS拉取位点多次均不变更，且无延迟，说明源库数据变更已结束。
如果源库位点不断变更，但DTS拉取位点多次均不变更，且延迟逐渐增大，需要参照下面的说明部分来做进一步确认。
方式二：通过查询数据库是否还有迁移/同步任务关联的DDL或DML语句
登录数据库，执行如下sql语句，并记录语句的输出结果。
show binlog events limit 10;
分析上述结果中是否有DTS迁移/同步任务关联的库表DDL或DML语句。
多次重复执行步骤1和2。
确认输出结果中没有任何DTS迁移/同步任务关联的任何库表DDL或DML语句，表示当前源库数据变更已结束。
数据迁移至MySQL时，为什么会提示索引超长？
MySQL中字符集不同，单个字符所能包含的最大字节数也不相同。当前天翼云RDS for MySQL默认的字符集为utf8mb4，存储引擎为InnoDB，在此情况下，不同索引所能容忍的最大长度如下：
单字段索引，字段长度不应超过767个字节（字符数=767/最大字节数）；
联合索引，每个字段长度除应满足“单字段索引”的要求外，同时所有字段长度之和应不超过联合索引合计最大字符数的3072个字节。
详细说明可参照MySQL官方文档：
https://dev.mysql.com/doc/refman/5.7/en/innodb-limits.html
https://dev.mysql.com/doc/refman/8.0/en/innodb-limits.html
故此，要顺利完成数据迁移至MYSQL，请合理设置源端索引的长度。
DTS如何迁移MySQL中的MYISAM表？
如果源库是天翼云RDS for MYSQL，则默认的存储引擎为InnoDB，不存在需要迁移MYISAM表的情况。如果源库是他云MySQL产品或用户本地自建MySQL，此时如果源端存在待迁移的MYISAM表，DTS会将其迁移至目标端，同时在目标端和源表保持一致，仍然为MYISAM。
如何将数据迁移至MySQL8.0？
当前DTS在实施MySQL的数据迁移时，支持从低版本迁移至高版本的8.0。具体说来就是：
MySQL 5.6 -> MySQL 8.0
MySQL 5.7 -> MySQL 8.0
另外，由于DTS支持MySQL的表、索引、存储过程、视图、函数、事件、触发器等的迁移，所以在实施MySQL 5.6/5.7数据迁移至MySQL 8.0时，用户需要做一些额外的确认工作，具体如下：
待迁移对象中是否有被移除的函数？
在MySQL8.0中，有一些原本存在于低版本中的内置函数已经被废除，具体可参照如下MySQL官方连接。
https://dev.mysql.com/doc/refman/5.7/en/encryption-functions.html
所以在迁移一些复合对象时，请确保源对象中没有引用一些已经被废除的函数。如果有，待DTS迁移完成之后，用户需自行修改目标端的已迁移对象，做一些适配。具体如下表：
| 名称 | 作用 | 是否已废除 |
|---|---|---|
| DECODE() | 字符串解码 | 是 |
| DES_DECRYPT() | 字符串解密 | 是 |
| DES_ENCRYPT() | 字符串加密 | 是 |
| ENCODE() | 字符串编码 | 是 |
| ENCRYPT() | 字符串加密 | 是 |
| PASSWORD() | 返回密码串 | 是 |
待迁移表是否使用了已被废除的字符集UTF8MB3？
在MySQL 8.0.29之前，UTF8是UTF8MB3的别名，两者是等同的，所有语句中的UTF8MB3会被默认转换成UTF8。
https://dev.mysql.com/doc/refman/5.7/en/charset-unicode-utf8.html
MySQL 8.0.30及之后的版本中，情况相反。SHOW CREATE TABLE或SELECT CHARACTER_SET_NAME FROM INFORMATION_SCHEMA.COLUMNS或SELECT COLLATION_NAME FROM INFORMATION_SCHEMA.COLUMNS这样的语句中，用户会看到以UTF8MB3或MTF8MB3_为前缀的字符集或排序规则名称。
由于DTS在执行MySQL -> MySQL的结构迁移时，会直接保留源库/表字符集。此时如果源库/表字符集是UTF8MB3，那么到了目标端仍然是UTF8MB3。考虑到后续的兼容性，建议用户在迁移完成后，手工将字符集修改为官方建议的UTF8MB4。
DTS如何处理MySQL的事件和触发器迁移？
为保证迁移后的数据一致性，DTS在执行MySQL的事件/触发器迁移时，会采取如下处理措施：
和不同的表、视图、存储过程等不同，所有的事件/触发器均被划分为后向迁移对象（Post Migration Object）；
所有的后向迁移对象，均在全量数据迁移完成之后，增量迁移开始之前才开始；
如果迁移任务不包含全量，则后向迁移对象在结构迁移阶段最后开始；
迁移开始后，后向迁移对象和普通对象一样执行结构迁移。
执行MySQL数据迁移时，如何正确配置lower_case_table_names参数？
lower_case_table_names配置参数会影响数据库表在系统中的存储以及对比方式，具体可参照MySQL官方文档。
https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html
https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html
为确保在使用DTS执行MySQL的数据迁移时，数据一致性得到保障，用户需要将源库和目标库的lower_case_table_names设置成一样。
在预检查阶段，DTS如果发现源库、目标库的lower_case_table_names值不一致，会产生错误提示，用户需按照指引修改配置项。