执行SELECT table_schema, table_name FROM information_schema.tables WHERE table_name REGEXP '_tmp$|__old$|__new$|^mysql_migrate_' AND table_schema NOT IN ('mysql','information_schema','performance_schema','sys')可定位残留临时表。
MySQL迁移失败后残留的临时表怎么找出来
迁移任务中断时，MySQL可能已创建了以 _tmp、__old、__new 或 mysql_migrate_ 为前缀/后缀的临时表，但未完成清理。这些表不会自动删除，会占用空间并干扰后续迁移。
执行以下语句定位：
SELECT table_schema, table_name FROM information_schema.tables WHERE table_name REGEXP '_tmp$|__old$|__new$|^mysql_migrate_' AND table_schema NOT IN ('mysql', 'information_schema', 'performance_schema', 'sys');
- 注意检查
table_schema—— 有些工具（如 gh-ost、pt-online-schema-change）会在目标库建临时表，有些则在mysql系统库建控制表（如gho_*表），后者需额外确认是否可删 - 若迁移工具使用了自定义库名（如
migration_temp），也要加入WHERE条件排查 - 不要仅靠表名猜测用途，先
SHOW CREATE TABLE `db`.`table_name`;看结构，确认无业务数据或触发器依赖
手动 DROP 临时表时遇到 ERROR 1051 是什么情况
ERROR 1051 (42S02): Unknown table 'xxx' 表示表已不存在，但迁移工具元数据里还记着它——这说明清理动作已部分执行，或表被其他流程（如自动清理脚本、DBA误操作）提前删过。
- 该错误本身可忽略，不影响后续操作，但提示你得回头核对迁移日志，确认失败点是否真卡在“删旧表”阶段
- 如果反复出现该错误，可能是工具重试逻辑缺陷，建议停掉所有相关迁移进程再操作
- 别用
DROP TABLE IF EXISTS掩盖问题：它会掩盖真实缺失状态，不利于定位哪一步真正没执行
迁移日志文件（binlog / relay log）要不要删
一般不用手动删。MySQL 的 binlog 和 relay log 由服务器自身管理，迁移失败不会导致它们异常增长；但如果你用了基于 binlog 的在线迁移工具（如 Maxwell、Canal 或某些自研同步链路），其消费位点（offset）可能卡在失败事务处，造成假性积压。
- 先查位点：比如 Canal 对应
meta.dat，Maxwell 存在positions表，确认是否停留在迁移事务内 - binlog 文件本身不建议手动
PURGE BINARY LOGS，除非磁盘告急且确认无下游依赖——误删会导致从库无法追平或闪回失败 - relay log 更不能手删：从库重启后会自动重建，强行删除可能引发
Relay log read failure
清理后必须验证的两个状态
删完表、确认日志无误后，最容易被跳过的其实是状态一致性校验：
- 查
SELECT COUNT(*) FROM information_schema.INNODB_TRX;—— 确保没有长事务残留（迁移失败常伴随未提交事务） - 运行
SHOW PROCESSLIST;过滤出State含Waiting for table metadata lock或Copying to tmp table的连接，强制KILL掉，否则新迁移仍会被阻塞
临时表和日志只是表象，真正卡住下一次迁移的，往往是这些看不见的锁和事务状态。
