前几天，一个做小生意的朋友打电话给我，说他那台用了五年的老电脑终于罢工了，硬盘咔咔响了几声直接黑屏。他急得不行，因为里面存着几百个客户的订单记录，全部在 MySQL 数据库里。这事儿让我想起很多人的一个误区——总觉得数据库迁移是个高大上的技术活，非得找专业 DBA 不可。其实，把 MySQL 数据库从一台电脑搬到另一台，真没那么玄乎，只要弄清楚几个关键步骤，普通人也能搞定。
先说最简单、最常用的办法——用 mysqldump 命令。打开旧电脑的命令行，敲一行，回车后输入密码，系统就会把整个数据库的结构和数据打包成一个 SQL 文件。这个文件其实就是一串建表语句和插入数据的命令，可读性很高。我见过有人直接用记事本打开这个文件，手动修改表名或字段，虽然不推荐这么干，但也说明它没什么神秘感。拿到 SQL 文件后，通过 U 盘或局域网传到新电脑上，再用命令，数据就过去了。整个过程快的话几分钟搞定，慢的话取决于数据量大小。
不过，光会跑命令还不够，你得提前想清楚几个坑。最典型的就是字符集问题。我有个做跨境电商的朋友，数据库里存着大量中文和日文商品描述，迁移后网页上全是乱码。后来一查，发现旧数据库用的是 utf8mb4 编码，新数据库默认是 latin1。解决办法很简单：在 mysqldump 命令后面加上 参数，导出的 SQL 文件头部会自动加上字符集声明。导入前再检查一下新数据库的字符集设置，用 看一眼，确保一致。这多花两分钟，能省下后面几小时的排查时间。
如果你的数据库特别大，比如几百 GB，mysqldump 可能有点吃力。我有个做电商数据分析的朋友，订单表有上亿条记录，用 mysqldump 导出时，电脑内存直接飙满，卡了快半小时还没反应。这种情况下，更靠谱的办法是直接拷贝数据文件。你需要找到 MySQL 的数据目录，Windows 上通常是 ，Linux 上是 。把该目录下对应数据库的文件夹整个复制到新电脑的相同位置，但前提是两台电脑的 MySQL 版本必须一致，或者至少是同一个大版本（比如都是 5.7 系列）。版本差距太大，数据文件格式可能不兼容，导入后会报错。
说到版本兼容性，这里有个容易被忽略的细节。MySQL 的配置文件（my.ini 或 my.cnf）里，有些参数会影响数据文件的读写方式，比如 和 。我见过有人把 Windows 上的 MySQL 数据文件拷到 Linux 上，结果表名大小写乱套，查询时明明存在的表却报 “doesn’t exist”。Windows 默认表名不区分大小写，Linux 则严格区分。解决办法是在新电脑的配置文件中加上 ，让 Linux 也忽略大小写，或者在旧电脑上改成区分大小写再导出。这类问题并不常见，但一旦碰到就非常头疼。
还有一种场景是需要迁移的不止单个数据库，而是整个 MySQL 实例，包括多个数据库、用户权限、存储过程、事件等。这时 mysqldump 的 参数就派上用场了。它能一次性把所有数据库、系统表、用户权限都导出，但要注意，系统表里的用户信息是加密存储的，直接导入到新机器上可能因为加密算法不同而无法识别。我的经验是，最好单独导出权限信息，用命令逐个查看，然后在新实例上手动重建用户。虽然麻烦，但能避免后面登录不上或权限不足的尴尬。
迁移完成后，千万别急着删旧电脑上的数据。先在新电脑上跑几个测试用例，比如查询最近一个月的订单数量，或者更新一条记录看看是否正常。我有个同事，迁移完数据库后，应用跑了两周才发现少了三张表，原因是旧电脑上有几个定时任务在跑，导出的那一刻正好有数据在写入，导致部分记录没来得及导出。所以，稳妥的做法是在导出前先锁表，用 让数据库只读，导出完毕后再解锁。如果业务不允许停机，可以考虑用主从复制的方式，把新电脑配置成旧电脑的从库，等数据同步完成后再切换主库。这需要一定的网络配置和 MySQL 复制知识，但能实现零停机迁移。
说点实在的，数据库迁移本身并不难，难的是你对数据有没有敬畏心。我见过太多人平时不做备份，出了事才想起迁移，结果手忙脚乱把数据搞丢了。其实，无论采用哪种方法，迁移前花十分钟做一次完整备份，迁移后花半小时做一次全面验证，这比任何高深技术都管用。就像我那个朋友，后来我帮他恢复了数据，他第一件事就是买了个移动硬盘，每周自动备份一次。数据库迁移说白了就是一次数据搬家，只要想清楚每一步可能遇到的坑，提前做好准备，它就像从旧房子搬到新房子一样自然。
