mysqldump适合中小规模数据库（≤50gb）、跨版本/平台迁移及sql审计，但大库会锁表、慢且无法秒级恢复；innodb优先用–single-transaction，混合引擎须用–lock-tables；导出可拆分为结构、数据或排除表；优化导入需–extended-insert、禁用unique_checks、用source执行；时间点恢复需结合binlog，操作复杂易错。
直接说结论：用 mysqldump 做逻辑备份，适合中小规模数据库（单库 ≤ 50GB）、需要跨版本/跨平台迁移、或要审计 SQL 内容的场景；但它不是万能方案，大库会锁表、慢、且无法做到秒级恢复。
备份时加 --single-transaction 还是 --lock-tables？
取决于存储引擎和业务容忍度：
- InnoDB 表优先用
--single-transaction：它通过一致性快照避免锁表，备份过程业务可读写；但要求事务不能太长，否则可能触发Error 1205 (HY000): Deadlock found when trying to get lock - 混合引擎（含 MyISAM）必须用
--lock-tables（默认行为）：会逐个FLUSH TABLES WITH READ LOCK，导致写阻塞；备份期间 INSERT/UPDATE/delete 全部卡住 - 绝对不要在主库上用
--lock-all-tables做全库备份——它会全局只读锁，对线上影响极大
导出结构不带数据？还是只导数据不带建表语句？
按需拆分比“一锅端”更可控，尤其做差异部署或数据迁移时：
- 只导结构：
mysqldump --no-data -u root -p mydb > schema.sql - 只导数据（跳过 CREATE TABLE）：
mysqldump --no-create-info -u root -p mydb > data.sql - 排除某张大表（如日志表）：
mysqldump --ignore-table=mydb.log_table -u root -p mydb > backup.sql - 注意：
--no-create-info不影响INSERT语句生成，但若目标库没有对应表，直接导入会报错ERROR 1146 (42S02): Table 'xxx' doesn't exist
备份文件太大，导入慢还容易中断？
mysqldump 默认输出包含大量 INSERT 单行语句，网络或内存波动就容易断；优化方向是减少 IO 和客户端压力：
- 导出时加
--extended-insert（默认开启）：合并多行插入为一条，减小体积、加快导入 - 导入前关掉唯一性检查：
SET UNIQUE_CHECKS=0;，导入后再开；否则每条INSERT都校验索引，性能暴跌 - 大文件别用
mysql -u root -p 直接管道导入——MySQL 客户端可能因超时或内存溢出退出；改用 <code>source /path/to/backup.sql在 mysql shell 里执行，更稳定 - 如果备份含 GB 级 BLOB 字段，考虑先用
--hex-blob导出，避免二进制内容被终端截断或转义错误
真正麻烦的是时间点恢复：你得自己解析 mysqldump 输出里的 CHANGE MASTER TO 或 GTID_PURGED，再结合 binlog 找位置——这一步几乎没人手动做对过三次以上。别低估它，尤其是主从切换后没及时更新备份策略时。