能直接用，但必须确认权限、字符集和版本三件事，否则导入后大概率乱码或失败；需验证mysqldump可用性及版本兼容性，导出时必加--single-transaction和--default-character-set=utf8mb4，导入前须创建同字符集目标库并指定字符集导入。
能直接用，但必须确认权限、字符集和版本三件事，否则导入后大概率乱码或失败。
确认 mysqldump 是否可用且版本匹配
别急着导出，先验证工具本身是否就位、版本是否与目标 MySQL 兼容。生产环境最常踩的坑是源端用 mysqldump 8.0 导出，目标 MySQL 是 5.7，结果 CREATE TABLE 语句里带了 8.0 特有的语法（比如 JSON 默认值或新字段属性），导入直接报错。
- 运行
mysqldump --version查看本地版本；在目标库执行SELECT VERSION();确认 MySQL 版本 - 若版本跨大版本（如 5.7 → 8.0），加
--compatible=mysql56参数导出，避免语法不兼容 - Windows 用户注意：如果安装的是 MySQL Installer 但没勾选 “MySQL Client”，
mysqldump不会自动加入 PATH，需手动添加bin目录到系统环境变量
导出时必须加 --single-transaction 和 --default-character-set
不加 --single-transaction，InnoDB 表可能被锁死，业务写入中断；不指定字符集，mysqldump 默认用客户端连接字符集（通常是 latin1），哪怕源库是 utf8mb4，导出文件也会变成乱码。
- 正确命令示例：
mysqldump -u root -p --single-transaction --default-character-set=utf8mb4 --databases myapp > myapp_full.sql - 不要用
-p密码连写（如-p123456），密码会暴露在进程列表和 shell 历史中；省略密码，回车后手动输入更安全 - 如果导出全库，用
--all-databases，但注意系统库（mysql、information_schema）通常不能直接导入云数据库，建议显式列出业务库名
导入前必须创建同字符集的目标库
目标库如果用默认字符集（latin1 或 utf8）建库，再导入 utf8mb4 内容，表结构能建，数据一插入就变问号或截断——这是迁移后查不到数据的最常见原因。
- 导入前务必执行：
mysql -u root -p -e "CREATE DATABASE myapp CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;" - 导入命令本身也要带字符集：
mysql -u root -p --default-character-set=utf8mb4 myapp - 导入大文件时，建议加
--force参数跳过单条语句错误（如重复主键），避免整个导入中断；但事后必须人工检查日志确认跳过了哪些行
导入后验证不能只看表数量
表建完了、行数对上了，不代表数据正确。中文乱码、时间字段偏移、自增 ID 断层、触发器/存储过程缺失——这些都得单独验。
- 快速验证：在源库和目标库各执行
SELECT COUNT(*), MD5(GROUP_CONCAT(id)) FROM users;，比对行数和哈希值 - 查一条含中文、emoji、时间戳的记录，用
HEX()对比原始字节，确认没被转义或截断 - 运行
SHOW CREATE TABLE users;，确认索引、外键、存储引擎（InnoDB）、字符集三项完全一致 - 如果导出时用了
--routines，导入后执行SHOW PROCEDURE STATUS WHERE Db='myapp';确认存储过程存在
真正麻烦的不是命令敲几遍，而是字符集隐式转换、版本语法差异、权限粒度控制这些细节——它们不会报错，但会让数据“看起来正常，实际已损”。每次迁移前花 10 分钟跑一遍 SHOW VARIABLES LIKE 'character_set%'; 和 SELECT VERSION();，比重导三次都省事。
