mysqldump工具在灾备恢复、DB间数据同步(含Server实例间同步）、主从搭建等场景下都拥有一席之地。可以说，它是DBA常用工具之一，所以就要求我们对其参数真正的了解掌握，特别是一些常用容易搞混、忽略的参数。因而，对mysqldump 那些被忽略的“摆渡”指令，要常常“淘”出来，Review 下。

一. 影响DB的参数

影响DB的参数，换句话说，DB作用域的参数，那些DB在mysqldump的作用范围内。

1.1 --all-databases

添加此参数就是备份所有的DB，例如

$> mysqldump --all-databases > dump.sql

1.2 --databases

通过此参数指定DB，例如：

$> mysqldump --databases db1 db2 db3 > dump.sql

The --databases option causes all names on the command line to be treated as database names.

1.3 参数中即没有--all-databases也没有--databases

当 mysqldump 命令中既没有 --all-databases 也没有 --databases 参数时，它的行为会根据提供的参数数量而有所不同。

简单来说，第一个参数会被视为数据库名，其后的所有参数则被视为表名。具体来讲，当只提供一个参数时，mysqldump 会备份这个指定的整个数据库；当提供两个或更多参数时，第一个参数是数据库名，后面的参数则是该数据库中需要备份的特定表。

例如：

mysqldump mydb > backup.sql

mysqldump mydb table1 table2 > backup.sql

英文官网的原文

Without this option【指--databases】, mysqldump treats the first name as a database name and those following as table names.

二.使用--all-databases 或 --databases对备份还原的影响

影响很多，在此强调一点：

使用--all-databases 或  --databases：生成的备份文件会包含 CREATE DATABASE 和 USE 语句。

With --all-databases or --databases, mysqldump writes CREATE DATABASE and USE statements prior to the dump output for each database.

不使用 --all-databases 或  --databases：生成的备份文件不包含 CREATE DATABASE 和 USE 语句。

2.1 生成的备份文件会包含 CREATE DATABASE 和 USE 语句

恢复时：可以直接导入，备份文件会自动创建数据库并选择它。例如

mysql -u root -p < backup.sql

优点：适合跨服务器恢复，因为它能确保数据库被创建。

2.2 不包含 CREATE DATABASE 和 USE  语句

恢复时：你必须先手动创建目标数据库（如果它不存在），并在导入时指定该数据库。例如：

mysql -u root -p mydb < backup.sql

或者,通过source的方式

mysql> CREATE DATABASE IF NOT EXISTS db1;
mysql> USE db1;
mysql> source dump.sql

优点：可以将数据导入到一个与原来名字不同的数据库中。

2.3 CREATE DATABASE的解读

生成的主要命令如下：

CREATE DATABASE /*!32312 IF NOT EXISTS */ `mydb` 
/*!40100 DEFAULT CHARACTER SET utf8mb4 */;

（1）/*!32312 IF NOT EXISTS */: 这是一个条件注释。

它的意思是：如果数据库不存在才创建。
前面的数字 32312 代表 MySQL 版本号（3.23.12）。只有当目标数据库版本高于此版本时，才会执行 IF NOT EXISTS。这是一种兼容旧版本的保护机制，防止因数据库已存在而报错。
（2）反引号 mydb : 数据库名会被反引号包裹，防止库名包含特殊字符或与保留字冲突。
（3）/*!40100 DEFAULT CHARACTER SET utf8mb4 */: 这也是一个条件注释。
它会显式指定字符集（如 utf8mb4 或 latin1），确保恢复数据时，新库的字符集与备份时一致，避免乱码。

2.4 回顾自动生成的建表的语句

当使用 mysqldump 默认或加上 --add-drop-table 参数时，生成的 SQL 结构如下：

-- 1. 安全删除旧表（默认 或 使用了 --add-drop-table）
DROP TABLE IF EXISTS `class_students`;

-- 2. 保存当前客户端字符集设置
/*!40101 SET @saved_cs_client     = @@character_set_client */;

-- 3. 设置本次建表的字符集环境（关键！防止乱码）
/*!50503 SET character_set_client = utf8mb4 */;

-- 4. 核心建表语句
CREATE TABLE `class_students` (
  `student_id` int NOT NULL AUTO_INCREMENT,
  `student_name` varchar(50) NOT NULL,
  `gender` enum('男','女') NOT NULL,
  `age` tinyint unsigned NOT NULL,
  `birth_date` date DEFAULT NULL,
  -- ... 其他字段 ...
  `class_id` int NOT NULL,
  PRIMARY KEY (`student_id`),
  KEY `idx_class_id` (`class_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;

-- 5. 恢复之前的客户端字符集设置
/*!40101 SET character_set_client = @saved_cs_client */;

三.参数 --single-transaction

--single-transaction 是一个在进行 MySQL 在线备份时非常关键的参数，它的核心作用是在不锁表的情况下，为 InnoDB 存储引擎的表创建一个数据一致的备份。
这对于生产环境至关重要，因为它可以避免备份操作阻塞正常的业务写入，实现所谓的“热备份”。

--single-transaction 参数通过利用 InnoDB 引擎的 MVCC (多版本并发控制) 特性来工作。

注意：

（1）仅对 InnoDB 表有效.
（2）无法避免元数据锁（MDL）等待
虽然它不锁表，但在备份开始时，它需要获取表的元数据锁。如果此时有长时间未提交的事务，或者有 DDL 操作（如 ALTER TABLE）正在执行，mysqldump 进程可能会因为等待元数据锁而被阻塞，直到这些操作完成。
（3）不能与 --lock-tables 同时使用
--single-transaction 和 --lock-tables 是互斥的。mysqldump 默认会开启 --lock-tables，因此使用 --single-transaction 时，它会自动禁用 --lock-tables。

四.参数--flush-logs

这个参数非常有意思，很有使用价值，但是也往往容易被忽略。关于此参数的使用，简单举几个例子。

例子1，我需要将DB1中的两张表的数据实时同步到DB2。自己通过Python脚本实现，实时同步借助模块python-mysql-replication。脚本启动时需要告诉从那个地方开始监控（收听）变更，即需要传递两个参数 log_file 和 log_pos。

            log_file: Set replication start log file
            log_pos: Set replication start log pos (resume_stream should be
                     true)

如果在通过mysqldump做全量同步时，指定了--flush-logs，参数 log_file 和 log_pos就非常容易获取了。 log_file 就是执行命令新产生的binlog文件；log_pos就是4。

例子2，如果是基于 mysqldump 搭建搭的建备份还原的机制（针对不太大的关键数据表），在每次mysqldump中做一个--flush-logs，对【Establishing a Backup Policy】、【Point-in-Time (Incremental) Recovery】都很有帮助。---可快速定位 log_file 和 log_pos。

此外，--flush-logs对搭建主从、故障隔离（或者说对故障现场隔离，某一个文件前后），都有一定的帮助。

当然，此参数不是万能，但是最好在一定场景下可以想到，恰好出现。

五.参数--set-gtid-purged

是 一个与 GTID（全局事务标识符） 复制模式紧密相关的关键参数。它的核心作用是控制备份文件中是否包含用于设置目标服务器 GTID 状态的语句，这直接决定了备份数据导入后，是否会参与或影响现有的主从复制环境。

当 MySQL 开启了 GTID 模式 (gtid_mode=ON) 时，mysqldump 的默认行为（AUTO）会在导出的 SQL 文件中自动添加两条关键语句：

语句1

SET @@SESSION.SQL_LOG_BIN= 0;

作用：在当前会话中关闭二进制日志（binlog）的记录。

后果：导入这些数据时产生的所有操作都不会被记录到 binlog 中。由于从库是通过读取主库的 binlog 来同步数据的，这意味着这次导入的数据不会同步到任何从库。

语句2

SET @@GLOBAL.GTID_PURGED='...';

作用：将源数据库的 GTID 执行集合设置到目标数据库中。
后果：这会让目标数据库“认为”这些 GTID 对应的事务已经被执行过了。

--set-gtid-purged 参数就是用来控制是否在备份文件中包含上述两条语句的。

六.参数--master-data

--master-data 参数是搭建 MySQL 主从复制（Master-Slave Replication）时的神器。它的核心作用非常明确：在备份文件中自动记录当前二进制日志（Binlog）的文件名和位置（Position）。

当使用 --master-data 时，mysqldump 会在生成的 SQL 文件头部插入一条 CHANGE MASTER TO 语句。

说明：

（1）mysqldump 的 --master-data 参数的默认值是 1。这意味着，如果你在命令中只写了 --master-data 而没有指定具体的数值（例如 --master-data=2），系统会自动按照 --master-data=1 的逻辑执行。

（2）为了保证获取坐标时数据的一致性，默认情况下它会执行 FLUSH TABLES WITH READ LOCK（全局读锁）。如果你同时使用了 --single-transaction，则不会锁表，而是利用 InnoDB 的事务特性来获取一致性坐标。可以理解为加上 --single-transaction 后，mysqldump 会在 InnoDB 事务开启的瞬间获取 Binlog 坐标，既保证了坐标与数据的一致性，又避免了锁表。

（3）DB实例如果已经开启了GTID，那么搭建主从，就不要考虑--master-data了；mysqldump中也就不要出现--master-data了。