--single-transaction是innodb表热备的底线，不加会导致flush tables with read lock全局锁表、写入阻塞；仅对innodb有效，依赖repeatable read隔离级别，长事务会阻塞dump启动。
直接上结论：用 mysqldump 备份 MySQL，核心不是“会不会”，而是“加不加关键参数”——漏掉 --single-transaction 或 --master-data=2，线上备份大概率失效或无法做增量恢复。
备份时为什么必须加 --single-transaction
这是 InnoDB 表热备的底线。不加它，mysqldump 默认会执行 FLUSH TABLES WITH READ LOCK，锁住整个实例，业务写入全部阻塞。尤其在中高并发场景下，几秒锁表都可能触发超时告警。
- 仅对 InnoDB 有效，MyISAM 不支持该参数（得用
--lock-all-tables，但代价更大） - 依赖事务隔离级别，默认
REPEATABLE READ才能保证一致性快照 - 如果备份过程中有长事务运行，
--single-transaction可能等待其结束，需提前检查SHOW PROCESSLIST
还原前必须确认备份文件是否含建库语句
这决定你能不能直接 mysql -u root -p db_name 。关键看备份时有没有用 <code>--databases 或 --all-databases：
- 用了
--databases shop→ 文件开头有CREATE DATABASE IF NOT EXISTS `shop`;和USE `shop`;，可直接导入目标库（即使库不存在） - 只写
mysqldump -u root -p shop > shop.sql→ 文件里没有建库语句，还原前必须手动CREATE DATABASE shop; - 误用
--all-databases备份了mysql系统库 → 还原时会覆盖权限表，极大概率导致账号失效，除非你明确需要迁移整套权限
压缩备份和按条件导出的实际取舍
生产环境几乎必做压缩，但方式选错反而拖慢流程；按条件导出看着灵活，实则容易埋坑：
- 管道压缩：
mysqldump -u root -p --single-transaction shop | gzip > shop_$(date +%Y%m%d).sql.gz—— 内存友好，但失败时无法定位是 dump 还是 gzip 出错 - 先 dump 后压缩更稳妥：
mysqldump -u root -p --single-transaction shop > shop.sql && gzip shop.sql，便于校验 SQL 文件完整性（比如head -n 20 shop.sql看是否有 CREATE TABLE） -
--where "status='active'"只导出活跃数据？注意：WHERE 条件不走索引时会全表扫描，大表慎用；且备份文件不含表结构（除非显式加--create-options），还原时得另配结构文件
最容易被忽略的权限和路径细节
报错 Access denied 或 No such file or directory 往往卡在这几个点：
- 执行用户必须有
SELECT+LOCK TABLES（InnoDB 下可降为--single-transaction免锁）+SHOW VIEW（含视图时）+TRIGGER（含触发器时） -
-p后不要空格接密码（-p123456），否则会被识别为--password=123456明文暴露在ps aux中；推荐交互式输密码或用~/.my.cnf配置 - 输出路径必须是 mysqldump 进程有写权限的目录，不是 MySQL server 的 datadir；常见错误是写成
/var/lib/mysql/backup/—— 这里 MySQL 进程有权限，但 shell 用户通常没权限
真正麻烦的从来不是命令敲不对，而是备份文件生成了却没校验内容、没测试还原、没清理旧备份——三者缺一，等于没备。
