--single-transaction是InnoDB单库导出必备参数，通过一致性快照避免锁表；不加则默认启用--lock-tables导致全库只读阻塞，且该参数与--lock-tables互斥。
直接用 mysqldump 就能导出，但不加关键参数容易导致备份不一致、锁表、恢复失败或权限混乱——尤其是生产环境。
导出单库时必须加 --single-transaction
这是 InnoDB 表避免锁表的核心参数。不加的话，默认触发 --lock-tables，整个库所有表会被锁住，写操作全部阻塞，业务可能卡顿甚至超时。
-
--single-transaction依赖事务一致性快照（MVCC），只对 InnoDB 有效；MyISAM 表无法使用，只能锁表 - 如果备份期间有长事务运行（比如 > 30 秒的 UPDATE），快照可能失效，导致部分数据不一致
- 不要和
--lock-tables同时用，会冲突报错 - 示例：
mysqldump -u root -p'123' --single-transaction myapp_db > myapp_db_$(date +%Y%m%d).sql
导出命令里密码不能带空格
-p 和密码之间**绝对不能有空格**，否则 MySQL 会认为密码是空，然后报错 Access denied for user。
Linux Ai Server
下载
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
- 错误写法：
mysqldump -u root -p '123' mydb→ 密码被忽略 - 正确写法一（推荐）：
mysqldump -u root -p'123' mydb - 正确写法二（更安全）：省略密码，执行后交互输入，避免密码泄露到 bash history
- 进阶方案：用
~/.my.cnf配置文件存凭证，加--defaults-extra-file指定路径，彻底规避命令行暴露
--databases 参数决定是否自动建库
这个参数看着不起眼，但直接影响恢复流程——它控制 dump 文件里是否包含 CREATE DATABASE IF NOT EXISTS 语句。
- 加了
--databases（如mysqldump ... --databases myapp_db）：恢复时可直接mysql -u root -p ，无需提前建库 - 没加（如
mysqldump ... myapp_db）：恢复前必须手动CREATE DATABASE myapp_db，否则报错Unknown database - 注意：
--all-databases自动包含--databases行为，但会导出mysql系统库，恢复时可能覆盖用户权限表，生产慎用
大库导出必须压缩，且别用 tar 二次打包
导出大库（>1GB）时，磁盘 I/O 和空间是瓶颈，边导出边压缩最高效；用 tar 先生成 .sql 再打包，等于写两遍磁盘，纯属浪费。
- 正确做法：
mysqldump -u root -p'123' --single-transaction myapp_db | gzip > myapp_db.sql.gz - 恢复时直接：
gunzip - 别用
zip或tar -z包裹已存在的 .sql 文件——既慢又占空间 - 如果网络传输，gzip 后体积通常降到 20%~30%，明显加快上传/下载
真正麻烦的不是导出动作本身，而是备份后没人验证能否恢复。哪怕只跑一次 mysql -u test -e "CREATE DATABASE tmp; use tmp; source backup.sql"，也能提前发现字符集、权限、语法兼容性等隐藏问题。
