迷茫的新客接手过一次老项目迁移，客户要求把整套 MySQL 数据库从自建机房迁到云上。两台机器之间只开放了有限端口，图形化工具基本没法用，唯一可靠的方式就是把数据导成 SQL 脚本，再拿到目标端去执行。那次迁移前前后后踩了十来个坑，从版本差异到隐蔽对象漏导再到导入中途报错，每一类都够人喝一壶的。后来我把这套“MySQL 数据库迁移（SQL脚本版）”的流程整理成了自己的标准操作手册，这篇文章就把完整的思路、命令以及实际踩坑记录分享出来。
我们先明确一个概念：这里说的“SQL脚本版”，指的是通过逻辑导出/导入的方式完成迁移，和直接拷贝 data 目录的物理迁移是两条完全不同的路线。对很多开发、运维以及临时被拉去负责迁库的“救火队员”来说，掌握这套方法，意味着你在没有图形界面、没有专业备份工具、甚至没有完整主机权限的环境里仍然能完成交付。下面按实际操作的先后顺序来拆解。
1. 为什么是“SQL脚本版”：逻辑备份的适用边界先搞清楚
1.1 逻辑备份和物理备份到底差在哪
数据库迁移的第一步不是敲命令，而是判断“我该用哪种迁移方式”。MySQL 的迁移备份大方向上分两类：
- 逻辑备份：把表结构、索引、数据、视图、存储过程、触发器、事件等全部翻译成 SQL 文本，然后在新库中重新执行。
- 物理备份：直接拷贝 MySQL 的数据文件、表空间文件、redo log 等底层文件。
用 SQL 脚本迁移属于逻辑备份，类比的话，相当于把一栋大楼拆成一张张图纸，然后在新地基上照着图纸重新盖。物理备份则更像把整栋楼连同地基下面的管道一起平移过去，速度确实快，但限制也多。
我整理过一张对比表，做迁移选型时可以当成参考：
| 对比项 | SQL脚本逻辑迁移 | 物理备份迁移 |
|---|---|---|
| 跨 MySQL 版本升级 | 一般可行，旧版本结构由新版本重新解析 | 风险大，版本间文件格式可能不兼容 |
| 跨操作系统 | 一般可行 | 容易踩 lower_case_table_names 等差异的坑 |
| 云数据库 / RDS | 通用，能连上就能导入 | 通常接触不到底层物理文件 |
| 迁移速度 | 相对慢，有解析和重新执行成本 | 快得多 |
| 能否选择性迁移 | 可以灵活选择库、表、对象 | 通常只能整个实例/整个库搬迁 |
| 对源库影响 | 单事务快照下基本无锁，MyISAM 表除外 | 往往需要停机拷贝 |
从这张表可以看出来，SQL脚本迁移最大的优势是“通用”和“灵活”。尤其当你面对的是跨版本、跨平台、云数据库这类物理文件根本无从下手的环境，SQL脚本几乎是唯一能保证可控的方式。
1.2 什么场景适合用 SQL脚本迁移
可能有人会说，直接 mysqldump 一下不就行了吗？这里说的“SQL脚本迁移”其实是一整套流程，不是