是的，innodb单库备份必须加--single-transaction；否则会导致写入不一致、部分表失败或数据丢失，且仅对innodb有效，myisam需改用--lock-all-tables。
mysqldump 备份还原不是“配好就能跑”，关键看参数组合是否匹配业务场景和引擎类型；InnoDB 库漏加 --single-transaction，备份期间写入就可能丢数据。
备份单库时必须加 --single-transaction 吗？
是的，只要数据库用的是 InnoDB（线上几乎全是），就必须加。不加会导致备份过程中新写入的数据不一致，甚至出现部分表导出成功、部分失败的静默错误。
常见错误现象：mysqldump: Got error: 1146: Table 'xxx' doesn't exist（表在备份中途被删）、或还原后发现订单表少了最后几分钟的数据。
-
--single-transaction依赖事务快照，仅对 InnoDB 有效；MyISAM 必须配合--lock-all-tables（会锁全库） - 如果备份含存储过程/触发器，还得补上
--routines和--triggers，否则还原后功能缺失 - 本地备份可省略
-h，但远程备份必须带-h和-P（如-h192.168.5.10 -P3307）
还原前要不要手动建库？
取决于备份时有没有用 --databases 或 --all-databases。
用了就不用建——文件里自带 CREATE DATABASE 和 USE 语句；没用就一定要先执行 mysql -u root -p -e "CREATE DATABASE IF NOT EXISTS shop;"，否则还原报错 ERROR 1049 (42000): Unknown database 'shop'。
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 只备份单库不加
--databases（如mysqldump -uroot -p shop > shop.sql），还原命令必须指定库名：mysql -uroot -p shop - 加了
--databases（如mysqldump -uroot -p --databases shop > shop.sql），还原时不能指定库名，直接mysql -uroot -p - 用
--add-drop-database可让还原自动删旧库重建，但生产环境慎用，避免误删
压缩备份怎么还原？
压缩不是可选项，是线上必备操作；10GB 的库不压缩，备份文件占空间、传输慢、IO 压力大。
典型命令：mysqldump -uroot -p --single-transaction --routines --triggers --events --databases shop | gzip > shop_$(date +%Y%m%d).sql.gz
- 还原时不能直接
mysql ，会报语法错误——gzip 文件不是 SQL 文本 - 正确方式：用管道解压直输，
zcat shop_20260903.sql.gz | mysql -uroot -p（zcat是 Linux 标准命令，无需额外安装） - 如果用
bzip2压缩，对应用bzcat；用xz就用xzcat
字符集乱码、时间戳错位这些细节容易被忽略
备份文件默认用服务器 character_set_server 编码，若库是 utf8mb4 而 mysqldump 没显式指定，还原后中文变问号或截断。
时间字段（DATETIME）在跨时区还原时可能偏移，尤其用了 --master-data=2 记录 binlog 位点的场景。
- 强制指定编码：
--default-character-set=utf8mb4，且确保 MySQL 客户端和服务端配置一致 - 还原前检查备份文件头：
head -n 20 shop.sql | grep "CHARSET"，确认是否含DEFAULT CHARSET=utf8mb4 -
--master-data=2生成的注释行（如-- CHANGE MASTER TO MASTER_LOG_FILE='binlog.000001', MASTER_LOG_POS=1234;）别手动删，主从恢复时依赖它
