不是必须，但对innodb表强烈建议加--single-transaction；它通过一致性快照避免锁表并保证时间点一致性，而myisam表不支持该参数，仍需锁表。
直接说结论：用 mysqldump 备份、mysql 命令还原，是最稳妥的通用方案，但必须注意字符集、事务一致性、权限和目标库是否存在这四个关键点。
备份时加 --single-transaction 是不是必须？
对 InnoDB 表是强烈建议的。它能启动一个一致性快照，避免备份过程中被写入导致数据不一致。不加的话，mysqldump 默认会对每个表执行 LOCK TABLES ... READ，可能阻塞写操作，尤其在业务高峰期。
- MyISAM 表不支持
--single-transaction，只能靠--lock-all-tables或--lock-tables（但会锁更久） - 如果备份脚本要兼容多种引擎，且不能接受长时间锁表，优先确认引擎类型再选参数
- 加了
--single-transaction后，--lock-tables会被自动禁用，两者不可共存
还原前为什么一定要手动创建数据库？
因为 mysql -u user -p DBNAME 命令要求 <code>DBNAME 已存在。如果数据库不存在，会报错：ERROR 1049 (42000): Unknown database 'xxx'。
- 可以用
mysql -u root -p -e "CREATE DATABASE IF NOT EXISTS mydb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"预创建，注意显式指定字符集，否则可能和备份文件不一致 - 如果备份文件里含
CREATE DATABASE（比如用了--databases或--all-databases），那还原时就不能指定库名，得用mysql -u user -p ，否则会冲突 - 用
--add-drop-database生成的备份，还原前删库再建库也行，但生产环境慎用
备份文件乱码或中文变问号怎么办？
根本原因是客户端、连接、数据库、表、备份文件五层字符集不统一，最常见的是备份时没指定 --default-character-set，而服务端默认是 latin1。
- 导出时强制指定：加上
--default-character-set=utf8mb4（推荐，不是utf8） - 检查备份文件头是否含
SET NAMES utf8mb4或类似语句；没有的话，手动加一行再导入 - 还原时也要确保 mysql 客户端连接用的是同字符集：
mysql --default-character-set=utf8mb4 -u user -p mydb - 别依赖
.my.cnf里的default-character-set，它只影响部分客户端行为，mysqldump不读这个配置
大库备份慢、恢复卡住，怎么优化？
纯 SQL 导出导入本身有性能瓶颈，mysqldump 适合中小规模（单库 ≤ 5GB），超过这个量级就得组合其他手段。
- 备份时加
--quick（默认开启）防止内存溢出；加--compress减少网络传输量（仅限远程备份） - 用
gzip实时压缩：mysqldump -u user -p db | gzip > db_$(date +%F).sql.gz；还原时：gunzip - 跳过注释和元信息可提速：
--compact或--skip-comments，但会丢失版本、时间戳等调试信息 - 真正上 TB 级别，
mysqldump就不该是首选——该切到Percona XtraBackup或 LVM 快照
最容易被忽略的是：备份文件本身没校验。导出后至少跑一次 head -n 20 backup.sql 看开头有没有 CREATE TABLE 和正确字符集声明；还原后别只看命令不报错，一定连进 MySQL 执行 SELECT COUNT(*) FROM some_table; 确认数据真进去了。
