MySQL 8.0 OCP 1z0-908 Exam Questions

Stone大约 447 分钟

MySQL 8.0 OCP 1z0-908 Exam Questions

题目 1

Examine the command, which execute successfully:

shell> mysqld --initialize-insecure.

Which statement is true?

A. The installation creates a temporary test environment with data in the /tmp directory.

B. The root password is created in the error log in plain text.

C. The installation is created without enforcing or generating SSL certificates.

D. The root password is not created allowing easy access from the same host.

正确答案：D（The root password is not created allowing easy access from the same host）

关键分析

1. --initialize-insecure 的核心行为

密码生成机制：使用 mysqld --initialize-insecure 初始化 MySQL 时，不会生成 root 用户的随机密码，而是直接设置为空密码。这与 --initialize 命令形成鲜明对比（后者会生成随机密码并记录在错误日志中）。

示例验证：若初始化后尝试登录，可直接执行 mysql -u root -p 并直接回车（无需输入密码），验证空密码状态。
安全影响：空密码允许本地用户无需认证即可访问数据库，存在安全隐患，因此仅推荐在测试环境或临时场景中使用此参数。

2. 排除其他选项的依据

选项 B（root 密码明文记录在错误日志）：此描述适用于 --initialize 命令，而非 --initialize-insecure。--initialize 生成的随机密码会写入错误日志（如 error.log），但 --initialize-insecure 明确跳过此步骤。
选项 C（不生成或强制 SSL 证书）：SSL 证书的生成由 --ssl 系列参数控制（如 --ssl-ca、--ssl-cert），与 --initialize-insecure 无关。初始化命令本身不涉及 SSL 证书的生成逻辑。默认行为：即使使用 --initialize-insecure，若配置文件中启用了 SSL 参数，仍会生成证书。
选项 A（在 /tmp 创建临时测试环境）：--initialize-insecure 的默认数据目录由 datadir 参数决定（通常为 /var/lib/mysql），与 /tmp 无关。临时文件目录由 tmpdir 或 innodb_tmpdir 参数控制。

3. 初始化流程验证

典型操作步骤：

执行命令：

mysqld --initialize-insecure --user=mysql --datadir=/var/lib/mysql

直接登录验证：

mysql -u root -p  # 直接回车，无需输入密码

后续安全加固：

ALTER USER 'root'@'localhost' IDENTIFIED BY 'new_password';

此流程验证了空密码的存在。

操作建议

测试环境适用性：仅在需要快速搭建临时数据库时使用 --initialize-insecure，生产环境必须使用 --initialize 生成随机密码。
日志检查：即使使用空密码初始化，仍建议检查错误日志（默认路径为 datadir/hostname.err），确认无其他初始化错误。
权限控制：确保数据目录（如 /var/lib/mysql）的属主为 mysql 用户，避免权限冲突。

参数对比

参数	密码行为	SSL 证书	适用场景
`--initialize`	生成随机密码（记录在日志）	根据配置文件生成	生产环境
`--initialize-insecure`	空密码	不干预 SSL 配置	测试/临时环境

题目 2

You are upgrading a MySQL instance to the latest 8.0 version.

Examine this output:

mysql> SHOW GLOBAL VARIABLES LIKE '%dir';
| Variable_name                  | Value                |
|--------------------------------|----------------------|
| basedir                        | /usr                 |
....
| datadir                        | /var/lib/mysql       |
| innodb_data_home_dir           | /innodb_data         |
| innodb_log_group_home_dir      | ./                   |
| innodb_temp_tablespaces_dir    | ./#innodb_temp/      |
| innodb_tmpdir                  |                      |
....
| plugin_dir                     | /usr/lib/plugin      |
....
| tmpdir                         | /tmp:/var/tmp        |

You plan to add this parameter to the configuration:

innodb_directories=’/innodb_extras’

Which statement is true?

A. It defines all innodb tablespace options relative to a starting parent directory.

B. It is not necessary because innodb_data_home_dir is already defined.

C. It allows scanning of other locations to discover more innodb tablespaces.

D. It moves all innodb tablespaces to the /innodb_extras directory to enable a new innodb_data_home_dir to be defined.

E. It adds more temporary workspace in addition to the innodb_tmpdir location.

正确答案：C（It allows scanning of other locations to discover more innodb tablespaces）

关键分析

1. innodb_directories 的核心作用：

根据题目配置 innodb_directories=’/innodb_extras’，其核心功能是在 MySQL 启动时扫描指定目录以发现 InnoDB 表空间文件。具体表现为：

扫描机制：InnoDB 会检查 /innodb_extras 目录下的 .ibd 文件（如独立表空间或通用表空间文件），并在数据字典中更新这些文件的路径。
与默认目录的关系：即使未显式设置 innodb_directories，系统也会自动附加 innodb_data_home_dir、datadir 等目录到扫描列表中，但新增的 /innodb_extras 需显式声明才能被识别。

2. 排除其他选项的依据

选项 A（定义相对路径的父目录）：innodb_directories 要求绝对路径，而非相对路径。例如，题目中 /innodb_extras 是绝对路径，与“父目录”无关。
选项 B（因 innodb_data_home_dir 已定义而不必要）：虽然 innodb_data_home_dir 会自动附加到 innodb_directories，但仅适用于系统表空间和默认数据目录。若用户将表空间文件移动到 /innodb_extras（不在默认目录内），必须显式声明该路径。
选项 D（移动表空间到新目录以启用新 innodb_data_home_dir）：innodb_directories 仅负责扫描现有文件，不会移动表空间。若需修改数据目录，应直接更新 datadir 或 innodb_data_home_dir 参数。
选项 E（增加临时工作空间）：临时文件由 innodb_tmpdir 或 tmpdir 控制，与 innodb_directories 无关。题目中 innodb_tmpdir 为空，临时文件默认使用 tmpdir（/tmp:/var/tmp）。

配置场景验证

假设用户在升级时将表空间文件移动到 /innodb_extras，但未配置 innodb_directories：

启动失败：InnoDB 无法找到这些文件，导致表空间丢失或崩溃恢复失败。
显式声明路径后：
```
[mysqld]
innodb_directories = "/innodb_extras"
```
InnoDB 启动时会扫描该目录，加载所有 .ibd 文件并更新数据字典。

操作建议

路径权限检查：确保 MySQL 用户对 /innodb_extras 有读写权限。
跨平台兼容性：若从 Windows 迁移到 Linux，需注意文件名大小写和路径分隔符（如将 \ 改为 /）。
日志验证：启动时观察日志，确认表空间文件已正确加载：
```
tail -f /var/log/mysql/error.log | grep "Loading tablespace"
```

总结

通过显式声明 innodb_directories，用户可扩展 InnoDB 表空间的扫描范围，支持灵活的文件迁移和恢复需求。此参数与现有目录配置互补，而非替代关系。

题目 3

Choose the best answer.

You plan to take daily full backups, which include the ndbinfo and sys (internal) databases. Which command will back up the databases in parallel?

A. mysqldump --all-databases > full-backup-$(date + %Y%m%d).sql

B. mysqlpump --include-databases=% > full-backup-$(date + %Y%m%d).sql

C. mysqlpump --all-databases > full-backup-$(date + %Y%m%d).sql

D. mysqldump --single-transaction > full-backup-$(date + %Y%m%d).sql

正确答案：B（mysqlpump --include-databases=% > full-backup-$(date +%Y%m%d).sql）

关键分析

1. 工具选择与并行能力

mysqlpump 是 MySQL 5.7+ 提供的逻辑备份工具，支持多线程并行备份（通过 --default-parallelism 参数），适合快速全量备份。
mysqldump 是单线程工具，无法满足并行需求，排除选项 A 和 D。

2. 参数要求与语法验证

备份范围：需包含 ndbinfo（NDB 集群元数据库）和 sys（性能监控数据库）。
--include-databases=%：% 是通配符，表示备份所有数据库（包括系统库）。
--all-databases：在 mysqlpump 中无效，其正确参数应为 --include-databases=%，排除选项 C。

3. 选项逐项排除

选项	问题
A. `mysqldump --all-databases`	`mysqldump` 是单线程工具，无法并行备份。
B. `mysqlpump --include-databases=%`	正确：`mysqlpump` 支持多线程，`%` 通配符覆盖所有数据库，包括 `ndbinfo` 和 `sys`。
C. `mysqlpump --all-databases`	语法错误：`mysqlpump` 无 `--all-databases` 参数，正确参数是 `--include-databases=%`。
D. `mysqldump --single-transaction`	单线程且参数不完整（未指定 `--all-databases` 或数据库列表）。

参数行为总结

mysqlpump 的优势：
- 并行备份：默认启用 2 线程（可调整 --default-parallelism 参数）。
- 高效压缩：支持 LZ4 或 ZLIB 压缩算法。
- 系统库兼容性：通过 % 通配符覆盖 ndbinfo 和 sys，无需额外配置。
mysqldump 的局限：单线程、速度慢，且默认不备份 ndbinfo。

操作建议

验证备份文件：

# 检查备份文件是否包含系统库
grep 'CREATE DATABASE .*sys\|ndbinfo' full-backup-20250512.sql

性能优化：

# 增加并行线程数（例如 4 线程）
mysqlpump --include-databases=% --default-parallelism=4 > full-backup-$(date +%Y%m%d).sql

自动备份：通过 cron 定时执行命令，并监控日志。

扩展对比

工具	并行备份	系统库支持	语法示例
`mysqlpump`	支持	`--include-databases=%`	`mysqlpump --include-databases=% > backup.sql`
`mysqldump`	不支持	需显式指定系统库	`mysqldump --databases sys ndbinfo > backup.sql`

若需更高性能或物理备份，可结合 Percona XtraBackup（支持热备与增量备份）。

题目 4

The languages table uses MyISAM and the countries table uses the InnoDB storage engine. Both tables are empty Examine these statements:

BEGIN;
INSERT INTO languages(lang) VALUES (“Italian”); 
INSERT INTO countries(country) VALUES(“Italy”); 
ROLLBACK;

What is the content of both tables after executing these statements?

A. countries has one row, languages has none

B. Both tables have one row

C. Both tables are empty

D. languages has one row, coutries has none

正确答案：D（languages has one row, coutries has none）

关键分析

1. 存储引擎对事务的支持差异

MyISAM（languages 表）：MyISAM 不支持事务，所有操作（如 INSERT）会立即自动提交，无法通过 ROLLBACK 回滚。即使语句包含在显式事务块（BEGIN...ROLLBACK）中，插入操作也会直接持久化到磁盘。
InnoDB（countries 表）：InnoDB 支持事务，所有操作在事务中默认处于未提交状态，直到执行 COMMIT 或事务隐式提交。执行 ROLLBACK 时，事务内的操作会被撤销，数据恢复到事务开始前的状态。

2. 事务执行过程解析

BEGIN：开启一个显式事务。仅对 InnoDB 表生效，MyISAM 表的操作不受事务控制。
INSERT INTO languages：MyISAM 引擎直接执行并提交，数据立即写入表中。即使后续执行 ROLLBACK，该操作无法回滚。
INSERT INTO countries：InnoDB 引擎将操作记录到事务日志中，但数据未提交（仅在内存中）。此时其他事务无法看到该行数据。
ROLLBACK：对 InnoDB 表（countries）撤销插入操作，数据不持久化。对 MyISAM 表（languages）无影响，数据已永久存在。

3. 选项排除依据

选项	分析
A. countries 有 1 行，languages 为空	错误：MyISAM 表不受事务回滚影响，插入操作已提交。
B. 两表均有 1 行	错误：InnoDB 表的插入操作被回滚，不会持久化。
C. 两表均为空	错误：MyISAM 表的插入操作已提交。
D. languages 有 1 行，countries 为空	正确：MyISAM 无法回滚，InnoDB 回滚成功。

扩展：事务支持的底层机制

MyISAM 的局限性：

无事务日志：MyISAM 直接修改数据文件，不记录 UNDO/REDO 日志，因此无法回滚。
表级锁：仅支持表级锁，高并发场景下性能受限，且无法保证事务隔离性。

InnoDB 的事务实现：
- UNDO Log：记录事务修改前的数据状态，用于回滚操作。
- REDO Log：确保事务的持久性，即使系统崩溃也能恢复已提交的数据。
- 多版本并发控制（MVCC）：通过版本链和一致性视图实现事务隔离性（如可重复读）。

操作建议

生产环境存储引擎选择：
- 优先使用 InnoDB 以保证事务支持和数据一致性。
- 仅当需要全表扫描的只读场景（如日志表）才考虑 MyISAM。
事务设计注意事项：
- 避免混合引擎：同一事务中操作不同引擎的表可能导致部分操作无法回滚（如本题中的 MyISAM 表）。
- 显式提交/回滚：手动控制事务边界，减少隐式提交的风险。

总结

本题通过对比 MyISAM 和 InnoDB 的事务支持特性，揭示了存储引擎对事务回滚行为的影响。MyISAM 的插入操作不受事务控制，而 InnoDB 的操作可通过 ROLLBACK 撤销。正确答案为 D，即 languages 表有数据，countries 表为空。

题目 5

What does the slave I/O thread do?

A. reads the relay log and executes the envents contained in them

B. connects to the master and requests it to send updates recoded in its binary logs

C. acquires a lock on the binary log for reading each event to be sent to the slave

D. monitors and schedules I/O calls to the subsystem for the relay logs

正确答案：B（connects to the master and requests it to send updates recoded in its binary logs）

关键分析

1. Slave I/O 线程的核心职责

Slave I/O 线程是 MySQL 主从复制架构中的关键组件，主要负责从主库（Master）获取二进制日志（Binlog）的更新内容，并将其写入从库（Slave）的中继日志（Relay Log）。具体行为包括：

建立与主库的连接：使用 CHANGE MASTER TO 命令配置的主库信息（如 IP、用户名、密码、Binlog 文件名及位置）建立网络连接。
请求并接收 Binlog：向主库发送 Binlog 请求，主库的 Dump 线程会将 Binlog 内容传输给从库的 I/O 线程。
写入中继日志：将接收到的 Binlog 内容按顺序写入从库的 Relay Log 文件，确保日志的完整性和顺序性。

2. 与其他线程的协作关系

主库的 Dump 线程：负责响应从库的 I/O 线程请求，发送 Binlog 内容。
从库的 SQL 线程：独立于 I/O 线程，负责读取 Relay Log 中的事件并执行，完成数据同步。

3. 选项排除依据

选项	分析
A. 读取中继日志并执行事件	错误：此任务由从库的 SQL 线程完成，而非 I/O 线程。
B. 连接到主库并请求 Binlog 更新	正确：符合 I/O 线程的核心职责描述。
C. 获取二进制日志锁以读取事件	错误：主库的 Binlog 读取由 dump 线程完成，无需从库 I/O 线程加锁。
D. 监控并调度中继日志的 I/O 调用	错误：I/O 线程仅负责 Binlog 的传输与写入，不涉及底层 I/O 子系统的调度。

扩展：I/O 线程的工作流程与优化

1. 工作流程

初始化连接：从库启动复制时，I/O 线程根据配置连接主库。
请求 Binlog：基于 SHOW MASTER STATUS 记录的 Binlog 文件名及位置，请求增量日志内容。
接收与写入：通过异步 I/O 机制接收数据，写入 Relay Log 文件。
状态维护：更新 master.info 文件，记录当前同步的 Binlog 位置。

2. 性能优化建议

网络稳定性：确保主从库之间的低延迟、高带宽连接，避免 I/O 线程因网络中断而频繁重连。
异步 I/O 配置：调整 innodb_read_io_threads 和 innodb_write_io_threads 参数，优化 I/O 吞吐量。
监控指标：通过 SHOW SLAVE STATUS 观察 Slave_IO_Running 状态，检查 Last_IO_Error 排查故障。

主从复制架构中的线程分工总结

线程	角色	关键行为
主库 Dump 线程	主库发送 Binlog 的代理线程	响应从库请求，推送 Binlog 内容。
从库 I/O 线程	从库获取 Binlog 的接收线程	连接主库、写入 Relay Log。
从库 SQL 线程	从库执行数据同步的操作线程	解析 Relay Log 并执行 SQL 事件。

总结

Slave I/O 线程的核心作用是建立与主库的连接，请求并接收 Binlog 更新内容，写入从库的中继日志。这一过程是主从复制实现数据同步的基础环节，而 SQL 线程负责后续的数据应用。正确答案为 B。

题目 6

Choose the best answer.

Examine these commands and results:

mysql> SHOW GRANTS FOR jane;
+-----------------------------------------+
| Grants for jane@%                       |
+-----------------------------------------+
| GRANT USAGE ON *.* TO `jane`@`%`        |
| GRANT SELECT ON `SALES`.* TO `jane`@`%` |
+-----------------------------------------+
2 rows in set (0.00 sec)

Jane must create a temporary table named TOTALSALES in the SALES database.

Which statement will provide Jane with the required privileges based on the principle of least privilege?

A. GRANT CREATE TEMPORARY TABLES, INSERT, UPDATE, DELETE, SELECT ON sales.totalsales TO jane;

B. GRANT CREATE TEMPORARY TABLES ON sales.* TO jane;

C. GRANT CREATE TEMPORARY TABLES ON sales.totalsales TO jane;

D. GRANT ALL ON sales.* TO jane;

正确答案：B（GRANT CREATE TEMPORARY TABLES ON sales.* TO jane;）

关键分析

1. 最小权限原则的核心要求

根据最小权限原则，用户仅应获得完成特定任务所需的最小权限范围。Jane 需要创建临时表 TOTALSALES，但无需其他操作权限（如修改数据、删除表等）。当前她的权限仅包含 SELECT，因此只需补充创建临时表的权限。

2. 临时表权限的语法规则

权限名称：在 MySQL 中，创建临时表需明确授予 CREATE TEMPORARY TABLES 权限。此权限与普通 CREATE 权限独立，需单独授权。

作用范围：临时表属于数据库对象，权限需作用于数据库级别（如 sales.*），而非具体表名（如 sales.totalsales）。选项 C 的 ON sales.totalsales 语法错误，因临时表不依赖预先存在的表结构。

3. 选项排除依据

选项	问题
A. `CREATE TEMPORARY TABLES, INSERT, UPDATE, DELETE...`	冗余权限：包含非必要的 `INSERT`、`UPDATE`、`DELETE`，违反最小权限原则。
B. `CREATE TEMPORARY TABLES ON sales.*`	正确：仅授予必需的临时表创建权限，且作用范围精确到数据库级别。
C. `CREATE TEMPORARY TABLES ON sales.totalsales`	语法错误：临时表权限无法限定到具体表名（如 `totalsales`），必须作用于数据库（`sales.*`）。
D. `ALL ON sales.*`	权限过度：授予全部权限（包括 `DROP`、`ALTER` 等），存在安全风险。

4. 权限生效验证

执行选项 B 后，Jane 的权限如下：

mysql> SHOW GRANTS FOR jane;
+------------------------------------------------------------------+
| Grants for jane@%                                                |
+------------------------------------------------------------------+
| GRANT USAGE ON *.* TO `jane`@`%`                                 |
| GRANT SELECT, CREATE TEMPORARY TABLES ON `sales`.* TO `jane`@`%` |
+------------------------------------------------------------------+

此时，Jane 可在 SALES 数据库内创建临时表，例如：

CREATE TEMPORARY TABLE SALES.TOTALSALES (id INT, amount DECIMAL(10,2));

无需其他额外权限即可完成操作。

操作建议

权限回收：若后续不再需要创建临时表，应立即撤销权限：
```
REVOKE CREATE TEMPORARY TABLES ON sales.* FROM jane;
```
临时表生命周期管理：
临时表仅在当前会话存在，会话结束后自动删除。
避免在连接池中长期持有临时表，防止资源泄漏。
安全审计：定期检查用户权限，确保符合最小权限原则。

总结正确答案为 B，因其精准授予 CREATE TEMPORARY TABLES 权限且作用范围合理，符合安全规范。其他选项或冗余或语法错误，均不适用。

题目 7

Choose the best answer.

Where is the default data directory located after installing MySQL using RPM on Oracle Linux 7?

A. /usr

B. /usr/mysql

C. /etc/my.cnf

D. /var/lib/mysql

E. /usr/bin

正确答案：D（/var/lib/mysql）

关键分析

1. MySQL RPM 安装的默认数据目录

在 Oracle Linux 7 系统中，通过 RPM 包安装 MySQL 后，默认数据目录（Data Directory）为 /var/lib/mysql。这一路径是 MySQL 存储所有数据库文件（如表数据、日志文件、元数据等）的核心位置。

2. 相关验证方法

命令行查询：登录 MySQL 后执行 SHOW VARIABLES LIKE 'datadir';，结果会直接显示数据目录路径为 /var/lib/mysql/。

配置文件确认：MySQL 的配置文件 /etc/my.cnf 中通常包含 datadir=/var/lib/mysql 配置项，明确指定数据存储位置。

系统文档与安装日志：RPM 安装过程中生成的文档和日志也会记录默认数据目录。

3. 选项排除依据

选项	分析
A. `/usr`	错误：`/usr` 是 MySQL 安装目录（存放二进制文件、库文件等），而非数据目录。
B. `/usr/mysql`	错误：非标准路径，RPM 安装的 MySQL 不会自动创建此目录。
C. `/etc/my.cnf`	错误：这是 MySQL 配置文件的路径，不存储数据文件。
D. `/var/lib/mysql`	正确：符合所有文档和安装实践的默认数据目录。
E. `/usr/bin`	错误：存放 MySQL 客户端工具（如 `mysql`、`mysqldump`），与数据无关。

总结通过 RPM 包在 Oracle Linux 7 安装 MySQL 后，默认数据目录为 /var/lib/mysql，所有数据库文件（包括系统库和用户库）均存储于此。正确答案为 D。

题目 8

Choose the best answer.

Binary log events for the ‘mydb1‘ schema must be copied to a different schema name ‘mydb2‘. Which command will do this?

A. mysqlbinlog --read- from-remote-server --raw | sed ‘s/mydb1/mydb2/g‘ | mysql

B. mysqlbinlog --rewrite-db= ‘mydb1->mydb2‘ | mysql

C. mysqlbinlog --datebase=mydb1 --database=mnydb2 | mysql

D. mysqlbinlog --rewrite-db=‘mydb1‘ --rewrite-db=‘mydb2‘ | mysql B

正确答案：B（mysqlbinlog --rewrite-db='mydb1->mydb2' | mysql）

关键分析

1. 问题核心与需求

题目要求将二进制日志（Binary Log）中涉及 mydb1 模式（schema）的事件全部复制到 mydb2 模式，并保持事件内容的一致性。这需要通过重写数据库名实现，而非简单的数据复制或过滤。

2. mysqlbinlog 的 --rewrite-db 选项

功能解析：--rewrite-db='olddb->newdb' 是 MySQL 5.7+ 提供的参数，用于在解析二进制日志时动态替换数据库名。它会将事件中的元数据（如表名、库名）和 SQL 语句中的库名统一替换为目标库名。

适用场景：当需要跨库迁移数据、修复主从复制中的库名不一致问题，或在多租户场景下动态映射数据库时使用。

3. 选项排除依据

选项	分析
A. `mysqlbinlog --read-from-remote-server --raw \| sed 's/mydb1/mydb2/g' \| mysql`	错误：`sed` 命令仅对文本进行简单替换，可能破坏二进制日志的事件结构（如行格式的 base64 编码数据），导致执行失败。
B. `mysqlbinlog --rewrite-db='mydb1->mydb2' \| mysql`	正确：直接通过 MySQL 原生支持的重写功能替换库名，确保事件完整性。
C. `mysqlbinlog --database=mydb1 --database=mydb2 \| mysql`	错误：`--database` 参数仅用于过滤日志事件（仅处理指定库的事件），无法实现库名重写。
D. `mysqlbinlog --rewrite-db='mydb1' --rewrite-db='mydb2' \| mysql`	错误：`--rewrite-db` 的语法需明确指定原库与目标库的映射关系（`olddb->newdb`），而非单独设置。

扩展：重写机制与实现原理

事件类型支持：

Row-Based 格式：--rewrite-db 会修改 Table_map 事件中的库名，并调整对应行数据的映射逻辑
Statement-Based 格式：直接替换 SQL 语句中的库名（如 USE mydb1 → USE mydb2）。
Mixed 格式：根据实际事件类型动态处理。

操作验证步骤：

# 1. 生成重写后的 SQL 文件（对比验证）
mysqlbinlog --rewrite-db='mydb1->mydb2' binlog.000001 > modified.sql
mysqlbinlog binlog.000001 > original.sql

# 2. 对比差异（确认库名替换）
diff modified.sql original.sql

输出中应显示所有 mydb1 被替换为 mydb2（如 USE 语句、表映射事件等）。

注意事项：
- 权限要求：执行用户需对目标库（mydb2）有完整操作权限。
- 跨库依赖：若事件涉及跨库操作（如联合查询），需额外处理其他库的映射。
- 版本兼容性：需 MySQL 5.7+ 版本支持。

总结

正确答案为 B，因其通过 --rewrite-db 参数直接实现库名的精准替换，符合 MySQL 官方功能设计，且能保证二进制日志事件的完整性和可执行性。其他选项或语法错误或功能不匹配，均不适用。

题目 9

Examine this snippet from the binary log file named binlog.000036:

# at 500324
#191120 14:55:16 server id 1  end_log_pos 500453 CRC32 0x98159515  Query  thread_id=9  exec_time=2  error_code=0  Xid = 1106
SET TIMESTAMP=1574222116/*!*/;
DROP TABLE `rental` /* generated by server */ 
/*!*/;

The rental table was accidentally dropped, and you must recover the table.

You have restored the last backup, which corresponds to the start of the binlog.000036 binary log.

Which command will complete the recovery?

A. mysqlbinlog --stop-position=500324 binlog.000036 | mysql

B. mysqlbinlog --stop-datetime='2019-11-20 14:55:18' binlog.000036 | mysql

C. mysqlbinlog --stop-position=500453 binlog.000036 | mysql

D. mysqlbinlog --stop-datetime='2019-11-20 14:55:16' binlog.000036 | mysql

正确答案：A（mysqlbinlog --stop-position=500324 binlog.000036 | mysql）

关键分析

1. 恢复逻辑与核心需求

题目要求恢复被意外删除的 rental 表，且已通过全量备份恢复到 binlog.000036 的起始状态。此时需通过增量应用 Binlog 日志来恢复备份后的数据变更，但需跳过 DROP TABLE 操作。

关键点：DROP TABLE 事件在 Binlog 中的起始位置是 500324（见日志片段 # at 500324），终止位置是 500453（end_log_pos 500453）。要避免该事件被执行，恢复时必须在起始位置前停止。

2. --stop-position 参数的作用

--stop-position=500324 表示仅应用 Binlog 中位置小于 500324 的事件，不包含 DROP TABLE 事件（起始于 500324）。

若使用 --stop-position=500453（选项 C），则会应用完整的事件（包括 DROP TABLE 操作），导致恢复失败。

3. 选项排除依据

选项	分析
A. `--stop-position=500324`	正确：精准排除 `DROP TABLE` 事件，仅恢复备份后到删除前的数据变更。
B. `--stop-datetime='2019-11-20 14:55:18'`	错误：时间参数精度不足，若日志中后续有其他事件在 14:55:16 至 14:55:18 之间，可能导致包含 `DROP` 事件或漏掉关键数据。
C. `--stop-position=500453`	错误：终止位置覆盖了 `DROP` 事件的完整范围（500324–500453），会执行删除操作。
D. `--stop-datetime='2019-11-20 14:55:16'`	错误：虽然时间戳与事件匹配，但 Binlog 中事件的时间戳可能包含多个操作，且 `datetime` 参数的精度不如 `position` 可靠。

扩展：Binlog 恢复的最佳实践

定位事件位点：
- 使用 SHOW BINLOG EVENTS IN 'binlog.000036' 确认 DROP TABLE 的精确起始位置。
- 避免依赖时间参数，因同一秒内可能存在多个事件。
恢复命令执行：
```
mysqlbinlog --stop-position=500324 binlog.000036 | mysql -u root -p
```
该命令将 Binlog 中 500324 之前的所有事件应用到数据库，跳过删除操作。
验证恢复结果：
- 执行 SHOW TABLES LIKE 'rental'; 确认表已恢复。
- 查询表数据是否完整（如 SELECT COUNT(*) FROM rental;）。

总结

正确答案为 A，因其通过 --stop-position 精确排除误删除事件，符合 Binlog 增量恢复的最小风险原则。其他选项或因参数精度不足，或因覆盖范围错误，均不适用。

题目 10

You recently upgraded your MySQL installation to MySQL 8.0.

Examine this client error:

ERROR 2059 (HY000): Authentication plugin 'caching_sha2_password' cannot be 
loaded: /usr/local/mysql/lib/plugin/caching_sha2_password.so: cannot open shared object file: No such file or 
directory

Which option will allow this client to connect to MySQL Server?

A. [mysqld]

default_authentication_plugin=sha256_password

B. ALTER USER user IDENTIFIED WITH mysql_native_password BY 'password';

C. [mysqld]

default_authentication_plugin=caching_sha2_password

D. ALTER USER user IDENTIFIED WITH caching_sha2_password BY 'password';

E. ALTER USER user IDENTIFIED WITH sha256_password BY 'password';

F. [mysqld]

default_authentication_plugin=mysql_native_password

正确答案：B. ALTER USER user IDENTIFIED WITH mysql_native_password BY 'password';

关键分析

1. 错误根源与选项筛选

错误 ERROR 2059 表明客户端或服务器无法加载 caching_sha2_password 插件。具体来说，caching_sha2_password.so 文件缺失（路径 /usr/local/mysql/lib/plugin/ 下不存在该文件）。此问题通常由以下原因导致：

MySQL 安装不完整：升级到 8.0 时未正确安装插件文件。
权限问题：插件文件存在但服务进程无权访问。
客户端不兼容：旧版客户端（如 PHP 7.2 以下、MySQL Workbench 旧版）不支持新插件。

2. 解决方案的核心逻辑

需绕过对 caching_sha2_password 插件的依赖，有两种途径：

修复插件文件问题：重新安装 MySQL 或手动补充插件文件（复杂且需服务器操作权限）。
修改用户认证方式：将用户认证插件切换为旧版 mysql_native_password（无需 caching_sha2_password 文件，兼容性更高）。

选项 B 直接通过 SQL 命令修改用户认证插件，是最直接且符合最小权限原则的解决方案。

3. 选项排除依据

选项	分析
A. `default_authentication_plugin=sha256_password`	错误：`sha256_password` 同样需要客户端支持，且需要 `sha256_password.so` 文件，若文件缺失仍会报错。
B. `ALTER USER ... mysql_native_password`	正确：切换用户认证方式为旧版插件，无需依赖缺失的 `caching_sha2_password` 文件。
C. `default_authentication_plugin=caching_sha2_password`	错误：此选项强制使用问题插件，但文件缺失会导致配置无效。
D. `ALTER USER ... caching_sha2_password`	错误：与当前错误直接冲突，无法修复。
E. `ALTER USER ... sha256_password`	错误：需 `sha256_password.so` 文件支持，若该文件缺失仍会报类似错误。
F. `default_authentication_plugin=mysql_native_password`	部分有效但非最优：修改默认插件仅影响新用户，已有用户仍需单独修改（如选项 B）。

操作验证与扩展建议

执行选项 B：
```
ALTER USER 'user'@'host' IDENTIFIED WITH mysql_native_password BY 'password';
FLUSH PRIVILEGES;
```
- 替换 user、host、password 为实际值。
- 此操作会更新 mysql.user 表的 plugin 字段为 mysql_native_password，兼容性恢复至旧版认证方式。
验证连接：
```
mysql -u user -p
```
输入密码后应可正常连接，不再触发 ERROR 2059。
长期安全建议：
- 修复插件文件：重新安装 MySQL 确保插件目录完整，或从其他实例复制 caching_sha2_password.so 到 /usr/local/mysql/lib/plugin/。
- 升级客户端：若环境允许，升级客户端工具（如 Navicat、JDBC 驱动）以支持新插件。

总结

正确答案为 B，因其直接解决插件缺失导致的认证失败问题，且不依赖服务器配置变更。其他选项或无效或需额外条件，均不适用。

题目 11

Examine this SQL statement:

UPDATE world.city
SET Population = Population * 1.1
WHERE CountryCode IN (SELECT Code FROM world.country WHERE Continent = 'Asia')

Which set of privileges will allow Tom to execute this SQL statement?

A. GRANT ALL PRIVILEGES ON ‘world’.‘city’ TO ‘tom’@’%’; GRANT SELECT (‘code’) ON ‘world’.‘country’ TO ‘tom’@’%’;

B. GRANT UPDATE ON ‘world’.* TO ‘tom’@’%’; GRANT ALL PRIVILEGES ON ‘world’.‘country’ TO ‘tom’@’%’;

C. GRANT UPDATE ON ‘world’.‘city’ TO ‘tom’@’%’; GRANT SELECT ON ‘world’.* TO ‘tom’@’%’;

D. GRANT UPDATE ON ‘world’.‘city’ TO ‘tom’@’%’; GRANT SELECT ON ‘world’.‘country’ TO ‘tom’@’%’;

正确答案：D（GRANT UPDATE ON ‘world’.‘city’ TO ‘tom’@’%’; GRANT SELECT ON ‘world’.‘country’ TO ‘tom’@’%’;）

关键分析

1. SQL 语句的权限需求

题目中的 UPDATE 语句需要满足以下权限：

world.city 表的 UPDATE 权限：因为该语句直接修改 world.city 表的 Population 字段。
world.country 表的 SELECT 权限：子查询 SELECT Code FROM world.country WHERE Continent = 'Asia' 需要读取 world.country 表的 Code 列，因此至少需要该表的 SELECT 权限。

2. 选项排除依据

选项	分析
A	错误：`GRANT SELECT ('Code')` 仅授予 `Code` 列的查询权限，但 MySQL 的子查询需要表的 `SELECT` 权限（而非仅列权限）。此外，`GRANT ALL PRIVILEGES ON city` 权限过宽，不符合最小权限原则。
B	错误：`GRANT UPDATE ON world.*` 允许 Tom 更新 `world` 下的所有表（超出需求），而 `GRANT ALL PRIVILEGES ON country` 赋予不必要的权限（如删除表），存在安全隐患。
C	错误：`GRANT SELECT ON world.*` 授予对 `world` 下所有表的查询权限（包括无关表），权限范围过大，且题目仅需访问 `country` 表。
D	正确：精准授予 `world.city` 的 `UPDATE` 权限和 `world.country` 的 `SELECT` 权限，完全覆盖 SQL 语句的操作需求，符合最小权限原则。

扩展：MySQL 权限机制与最佳实践

权限粒度控制
- 表级权限：如 GRANT UPDATE ON world.city 仅允许操作特定表，避免权限扩散。
- 列级权限：虽然 MySQL 支持列级权限（如 GRANT SELECT (Code)），但子查询中仍需表的 SELECT 权限。
子查询的权限要求
- 子查询中的表需显式授予 SELECT 权限，即使仅涉及部分列。例如，SELECT Code FROM country 需要 country 表的 SELECT 权限，而非仅 Code 列。
安全建议
- 最小权限原则：仅授予必要的权限（如选项 D），避免 ALL PRIVILEGES 或通配符 *。
- 定期审计权限：使用 SHOW GRANTS FOR 'tom'@'%' 验证权限配置。

总结

正确答案为 D，因其精准匹配 SQL 语句的权限需求，既满足功能要求，又符合安全规范。其他选项或因权限不足、或因权限冗余被排除。

题目 12

Choose the best answer.

Which command enables rule -based MySQL Auditing capabilities?

A. shell> mysql < audit_ log_ filter_ linux_ install.sql

B. shell> mysqld --initialize --log-raw=audit. log

C. mysql>INSTALL PLUGIN audit_ log;

D. mysql>INSTALL COMPONENT audit_ log;

正确答案：A（ shell> mysql < audit_log_filter_linux_install.sql）

关键分析

1. 基于规则的审计功能依赖插件安装与初始化

MySQL 企业版的基于规则审计功能需要通过安装插件并初始化相关表结构来实现。

选项 A 通过执行 SQL 脚本 audit_log_filter_linux_install.sql，会完成以下操作：

加载 audit_log 插件。
创建审计规则表（如 mysql.audit_log_filter 和 mysql.audit_log_user）。
初始化审计规则管理函数（如 audit_log_filter_set_filter()）。

这一过程是启用规则化审计的核心步骤。

2. 其他选项排除依据

选项	分析
B. `mysqld --initialize --log-raw=audit.log`	错误：`--log-raw` 参数用于指定错误日志路径，与审计功能无关。
C. `INSTALL PLUGIN audit_log;`	错误：仅执行插件安装，但未初始化规则表与函数，无法直接启用规则化审计。需通过脚本完成完整配置。
D. `INSTALL COMPONENT audit_log;`	错误：MySQL 企业版审计功能通过插件（Plugin）而非组件（Component）实现。`INSTALL COMPONENT` 语法不适用于此场景。

扩展：规则化审计的运作机制

规则表与函数的作用：
- audit_log_filter 表：存储自定义审计规则（如过滤特定用户、操作类型）。
- audit_log_user 表：关联用户与规则，实现精细化控制。
- audit_log_filter_set_filter()：动态设置规则的核心函数。
验证审计功能：
执行脚本后，查询插件状态和规则表是否生效：
```
SHOW PLUGINS;  
SELECT * FROM mysql.audit_log_filter;  
```
若结果包含 audit_log 插件及规则表，则功能已启用。

总结

正确答案为 A，因其通过执行安装脚本完整初始化规则化审计所需的插件、表结构及函数，而其他选项或语法错误或功能不完整，均无法满足需求。

题目 13

Choose the best answer.

You are having performance issues with MySQL instances. Those servers are monitored with MySQL Enterprise Monitor. Using Query Analyzer, where do you begin to look for problem queries?

A. Sort the "Exec" column and check for SQL queries with low Query Response Time index (QRTi) values.

B. Look for queries with low total latency times in the Latency section in the times series graph.

C. Sort the "Exec" column and check for SQL queries with high Query Response Time index (QRTi) values.

D. Look for queries with big prolonged spikes in row activity/access graph in the times series graph.

正确答案：A. Sort the "Exec" column and check for SQL queries with low Query Response Time index (QRTi) values.

关键分析

1. QRTi 指标的核心作用

Query Response Time Index (QRTi) 是 MySQL Query Analyzer 的核心性能指标，用于量化查询的响应时间分布。其取值范围为 0~1：

1：表示查询的响应时间全部在“最佳”范围内（如默认 ≤100ms）。
0.5：表示查询响应时间处于“可接受”范围（如 100ms~400ms）。
0：表示响应时间超出可接受范围（如 >400ms）。

低 QRTi 值意味着该查询在不可接受的时间范围内执行的次数较多，是潜在的性能瓶颈或慢查询。因此，通过排序 "Exec" 列（执行次数）并筛选低 QRTi 值的查询，可以直接定位到高频且性能差的 SQL 语句。

2. 选项排除依据

选项	分析
A	正确：QRTi 是 Query Analyzer 的核心分析指标，低值直接反映查询性能问题。按 "Exec" 排序可优先优化高频低效的查询。
B	错误：低总延迟时间（Latency）的查询本身性能良好，无需优先优化，与问题场景无关。
C	错误：高 QRTi 值表示查询性能良好，与题目要求的“问题查询”矛盾。
D	错误：行活动尖峰可能反映资源瞬时压力，但无法直接关联具体 SQL 的性能问题，需结合其他指标分析。

扩展：Query Analyzer 的使用逻辑

QRTi 的界面展示
- Query Analyzer 的界面会以彩色饼图展示 QRTi 分布：绿色（最佳）、黄色（可接受）、红色（不可接受）。
- 点击具体查询可查看其执行趋势图、历史 QRTi 波动及详细执行计划（如扫描行数、临时表使用等）。
优化建议的生成
- Query Analyzer 会根据 QRTi 和性能数据提供索引建议、查询重写提示等。例如，若某查询因全表扫描导致低 QRTi，系统可能提示“添加复合索引”或“优化 WHERE 条件”。
最佳实践
- 优先优化高频低 QRTi 查询：这类查询对系统整体性能影响最大。
- 结合其他指标：如 Rows Examined（扫描行数）、Lock Time（锁等待时间）验证性能瓶颈来源。

总结

正确答案为 A，因其直接利用 Query Analyzer 的核心指标 QRTi，精准定位高频低效查询，符合 MySQL 官方文档和性能优化逻辑。其他选项或逻辑错误，或未聚焦核心问题，均不适用。

题目 14

Examine this command and output:

mysql> SHOW GLOBAL STATUS LIKE 'Firewall$';
+---------------------------+-------+
| Variable_name             | Value |
+---------------------------+-------+
| Firewall_access_denied    | 7     |
| Firewall_access_granted   | 4     |
| Firewall_access_suspicious| 3     |
| Firewall_cached_entries   | 11    |
+---------------------------+-------+

Which statement is true?

A. Firewall_cached_entries is the number of statements found in the query cache for users in DETECTING mode.

B. Firewall_access_denied is the number of connection attempts from prohibited hosts that are denied.

C. Firewall_access_suspicious is the number of statements logged as suspicious for users in DETECTING mode.

D. Firewall_access_granted is the number of connections granted from whitelisted hosts.

正确答案：C. Firewall_access_suspicious is the number of statements logged as suspicious for users in DETECTING mode.

关键分析

1. 状态变量的核心定义

根据 MySQL 企业版防火墙的官方文档与用户手册，题目中的四个状态变量含义如下：

Firewall_access_denied：被防火墙明确拒绝的 SQL 语句数量（例如在 PROTECTING 模式下执行未在白名单中的语句）。
Firewall_access_granted：防火墙允许执行的 SQL 语句数量（完全匹配白名单规则的语句）。
Firewall_access_suspicious：在 DETECTING 模式下，执行未在白名单中但未被拒绝的 SQL 语句数量（仅记录为可疑，不影响执行）。
Firewall_cached_entries：当前缓存中存储的白名单规则条目数（与查询缓存无关）。

2. 选项排除依据

选项	分析
A	错误：`Firewall_cached_entries` 记录的是防火墙白名单缓存的条目数量，而非查询缓存或特定模式（如 DETECTING）下的语句。
B	错误：`Firewall_access_denied` 统计的是 SQL 语句被拒绝的次数，而非连接尝试的拦截（防火墙的访问控制与连接层面的拦截无关）。
C	正确：`Firewall_access_suspicious` 明确对应 DETECTING 模式下记录的可疑 SQL 语句数量，符合官方定义。
D	错误：`Firewall_access_granted` 统计的是通过防火墙验证的 SQL 语句数量，而非来自白名单主机的连接数（连接控制由网络层防火墙实现，非 MySQL 企业版防火墙功能）。

扩展：防火墙模式与状态变量关系

DETECTING 模式的作用
- 当用户账户的防火墙模式设置为 DETECTING 时，防火墙不会拒绝未在白名单中的 SQL 语句，但会将其记录为“可疑”（Firewall_access_suspicious 递增）。
- 此模式常用于灰度测试阶段，用于识别潜在恶意语句而无需中断业务。
状态变量的实际应用场景
- 监控性能瓶颈：若 Firewall_access_denied 值较高，说明大量非法 SQL 被拦截，需检查业务逻辑或白名单完整性。
- 优化白名单：高 Firewall_access_suspicious 值表明需扩展白名单规则（通过 RECORDING 模式重新训练）。
- 缓存管理：Firewall_cached_entries 异常增长可能需调整内存配置或清理过期规则。

总结

正确答案为 C，因其精准匹配官方文档对 Firewall_access_suspicious 的定义。其他选项或混淆了概念（如连接与语句），或错误关联了缓存类型，均不符合实际功能。

题目 15

Examine this output:

mysql>SELECT FORMAT_BYTES(@global.innodb_buffer_pool_size) AS BufferPoolSize, 
       @global.innodb_buffer_pool_instances AS NumInstances, 
       FORMAT_BYTES(@global.innodb_buffer_pool_chunk_size) AS ChunkSize;
+-----------------+--------------+------------+
| BufferPoolSize  | NumInstances | ChunkSize  |
+-----------------+--------------+------------+
| 12.00 GiB       |           8  | 128.00 MiB |
+-----------------+--------------+------------+

mysql>SELECT * FROM sys.metrics WHERE Variable_name LIKE 'Thread%';
+-------------------+----------------+---------------+---------+
| Variable_name     | Variable_value | Type          | Enabled |
+-------------------+----------------+---------------+---------+
| threads_cached    |              4 | Global Status | YES     |
| threads_connected |             32 | Global Status | YES     |
| threads_created   |            112 | Global Status | YES     |
| threads_running   |             16 | Global Status | YES     |
+-------------------+----------------+---------------+---------+
4 rows in set (0.06 sec)

Which change should optimize the number of buffer pool instances for this workload?

A. Increase the number of buffer pool instances to 16.

B. Increase the number of buffer pool instances to 32.

C. Decrease the number of buffer pool instances to 1.

D. Increase the number of buffer pool instances to 12.

E. Decrease the number of buffer pool instances to 4.

正确答案：A. Increase the number of buffer pool instances to 16.

关键分析

1. 当前配置的瓶颈与优化方向

根据题目中的配置信息：

缓冲池总大小：12 GB（innodb_buffer_pool_size）
缓冲池实例数：8（innodb_buffer_pool_instances）
块大小：128 MB（innodb_buffer_pool_chunk_size）

结合线程监控数据：

threads_connected：32（活跃连接数）
threads_running：16（并发执行线程数）

可以看出当前系统处于高并发负载状态，而 innodb_buffer_pool_instances=8 可能导致锁争用（Lock Contention），影响并发性能。

2. 缓冲池实例的调优逻辑

InnoDB 缓冲池实例的核心作用是通过减少全局锁竞争提高并发性能。以下调优原则适用：

CPU 核心数与实例数的关系：通常建议 innodb_buffer_pool_instances 设置为 CPU核心数的倍数（例如 2 倍）。若服务器有 16 核心，则实例数设为 16 或 32 更合理。
每个实例的最小推荐大小：每个实例应至少 1 GB 以避免碎片化和管理开销。当前每个实例大小为 12 GB / 8 = 1.5 GB，符合要求。若增至 16 实例，则每个实例大小为 12 GB / 16 = 0.75 GB，略低于推荐值，但高并发场景下仍可能通过减少锁争用提升性能。

3. 选项排除依据

选项	分析
A. 增至 16	正确：在 12 GB 缓冲池下，16 实例（每个 0.75 GB）虽略低于 1 GB 推荐值，但高并发下可显著减少锁争用，提升吞吐量。
B. 增至 32	错误：每个实例大小仅 `12 GB / 32 = 0.375 GB`，碎片化风险高，可能抵消并发优势。
C. 减至 1	错误：单实例会加剧锁竞争，导致高并发性能急剧下降。
D. 增至 12	次优：每个实例大小 `1 GB` 符合推荐，但 12 可能未充分利用 CPU 核心数（例如 16 核心时）。
E. 减至 4	错误：减少实例数会进一步增加锁争用，恶化性能。

扩展：缓冲池实例调优的最佳实践

CPU 核心数与实例数的平衡
- 若服务器有 16 核心，建议设置 innodb_buffer_pool_instances=16 或 32（2 倍核心数）。
- 若核心数未知，可通过 SHOW VARIABLES LIKE 'innodb_buffer_pool_instances' 结合系统监控工具推断。
实例大小与碎片化控制
- 每个实例应至少 1 GB。若因总内存限制无法满足，可优先保证高并发场景下的锁竞争最小化，容忍轻度碎片化。
- 例如，在 12 GB 缓冲池下，16 实例的碎片化风险可控，且锁争用减少带来的收益可能超过碎片化损失。
动态调整与验证
- 使用 SET GLOBAL innodb_buffer_pool_instances=16 在线调整，并监控性能指标（如 SHOW ENGINE INNODB STATUS 中的 Buffer Pool hit rate 和 Row operations）。
- 若吞吐量提升且 threads_running 等待减少，则验证优化有效。

总结

正确答案为 A，因其在高并发负载下通过增加缓冲池实例数减少锁争用，尽管单个实例略小于推荐值，但综合性能收益更显著。其他选项或加剧竞争（C、E）、或碎片化风险过高（B）、或未充分利用硬件资源（D）。

题目 16

Choose the best answer.

You encountered an insufficient privilege error in the middle of a long transaction.

The database administrator is informed and immediately grants the required privilege:

GRANT UPDATE ON world.city TO ‘user1’;

How can you proceed with your transaction with the least interruption?

A. Roll back the transaction and start the transaction again in the same session.

B. Re-execute the failed statement in your transaction.

C. Change the default database and re-execute the failed statement in your transaction.

D. Close the connection, reconnect, and start the transaction again.

正确答案：B. Re-execute the failed statement in your transaction.

关键分析

1. MySQL 权限变更的生效机制

在 MySQL 中，权限变更（如 GRANT 或 REVOKE）不会立即影响已存在的会话。已建立的连接会保留旧的权限缓存，直到会话结束或重新加载权限。因此，即使管理员已授予权限，当前会话仍需通过特定操作触发权限更新。

2. 事务与权限的交互逻辑

事务的隔离性：事务在执行过程中会保留开始时的权限状态，即使中途权限被修改，事务内部仍基于原有权限运行。
失败语句的重试：若事务中某条语句因权限不足失败，重新执行该语句（而非重启事务）会触发 MySQL 重新检查当前会话的权限缓存。此时，若权限已更新，操作将成功。

3. 选项排除依据

选项	分析
A. 回滚并重启事务	错误：回滚会导致事务中所有操作丢失，需完全重新执行，中断时间长。
B. 重试失败语句	正确：重试会触发权限检查更新，无需断开连接或重启事务，中断最小。
C. 切换默认数据库	无关：权限作用于表而非数据库，切换默认数据库不影响已授权的表权限。
D. 断开重连	次优：断开连接会终止当前事务，需重新执行所有操作，不符合“最小中断”要求。

扩展：权限更新后的验证步骤

检查权限缓存：执行 SHOW GRANTS FOR 'user1'@'host'; 确认权限已生效。
重试失败语句：在事务内直接重新执行因权限失败的操作（如 UPDATE world.city ...），MySQL 会重新加载权限配置并应用新权限。
监控事务状态：通过 SHOW ENGINE INNODB STATUS 确认事务未因锁冲突或超时终止。

总结

正确答案为 B。MySQL 在重试失败语句时会动态加载更新后的权限，无需回滚或断开连接，最大程度减少事务中断。其他选项或导致数据丢失（A、D），或与权限机制无关（C）。

题目 17

Choose the best answer.

There has been an accidental deletion of data in one of your MySQL databases.You determine that all entries in the binary log file after position 1797 must be replayed.

Examine this partial command:

mysqlbinlog binlog.000008 --start-position=1798

Which operation will complete the command?

A. --write-to-remote-server must be added to the command line to update the database tables.

B. No changes required. It automatically updates the MySQL Server with the data.

C. It can be piped into the MySQL Server via the command-line client.

D. You must use --stop position=1797 to avoid the DELETE statement that caused the initial problem.

正确答案：C. It can be piped into the MySQL Server via the command-line client.

关键分析

1. mysqlbinlog 工具的核心功能与用法

mysqlbinlog 是 MySQL 提供的用于解析二进制日志（Binlog）的工具，其本身不会直接修改数据库数据。要恢复数据，需将解析后的 SQL 语句通过管道（|）传递给 mysql 客户端执行。例如：

mysqlbinlog binlog.000008 --start-position=1798 | mysql -u root -p

此命令将解析 binlog.000008 中从位置 1798 开始的所有事件，并自动应用到 MySQL 服务器中。

2. 选项排除依据

选项	分析
A. `--write-to-remote-server`	错误：MySQL 官方文档中无此参数。实际恢复需通过管道或输出文件手动执行 SQL。
B. 无需修改	错误：`mysqlbinlog` 默认仅输出 SQL 文本，需手动或通过管道将其输入到 `mysql` 客户端执行。
C. 管道输入 MySQL 客户端	正确：符合官方推荐流程，解析后通过管道直接执行。
D. `--stop-position=1797`	错误：题目要求恢复 1797 之后的操作，设置 `--stop-position=1797` 会排除需恢复的日志范围。

扩展：二进制日志恢复的完整流程

定位误操作位置，使用 mysqlbinlog 结合 --start-datetime 或 --start-position 分析日志，确定误删除事件的位置。例如：
```
mysqlbinlog --no-defaults --base64-output=decode-rows -v binlog.000008
```
生成恢复脚本，解析指定范围的日志并输出到 SQL 文件：
```
mysqlbinlog binlog.000008 --start-position=1798 > recovery.sql
```

执行恢复操作，通过 mysql 客户端执行脚本或直接管道输入：

mysql -u root -p < recovery.sql   # 文件方式
mysqlbinlog ... | mysql -u root -p  # 管道方式

验证数据完整性，检查目标表数据是否恢复，并确认事务一致性。

总结

正确答案为 C。通过管道将 mysqlbinlog 解析结果传递给 mysql 客户端是标准恢复流程的核心步骤。其他选项或参数错误（A、D），或违背恢复逻辑（B）。

题目 18

Choose the best answer.

The mysqld instance has the connection control plugin enabled with these settings:

connection_control_min_connection_delay=1000
connection_control_max_connection_delay=2000

The minimum and maximum delays need to be increased to 3000 and 5000, respectively.

A command is executed:

mysql> SET GLOBAL connection_control_min_connection_delay=3000;

What is the result?

A. Only the minimum connection value is increased to 3000.

B. The minimum connection value is changed to 2000.

C. The minimum value increases to 3000 and the maximum value increases to 4000.

D. An error is returned.

正确答案：D. An error is returned.

关键分析

1. 参数修改的依赖关系

根据 MySQL 连接控制插件的设计规则：

connection_control_min_connection_delay 的值不能大于当前 connection_control_max_connection_delay 的值。

修改这两个参数时，必须先增大最大值，再增大最小值，否则会导致冲突。

题目中的初始配置为：

最小延迟 = 1000 ms
最大延迟 = 2000 ms

当直接尝试将最小延迟设置为 3000 ms（超过当前最大延迟 2000 ms）时，违反了上述规则，MySQL 会拒绝此操作并返回错误。

2. 正确修改顺序

若要将最小延迟和最大延迟分别调整为 3000 ms 和 5000 ms，正确的操作顺序应为：

先设置最大延迟：

SET GLOBAL connection_control_max_connection_delay = 5000;

再设置最小延迟：
```
SET GLOBAL connection_control_min_connection_delay = 3000;  
```
若未按此顺序操作，直接修改最小延迟会导致错误。

3. 选项排除依据

选项	分析
A	错误：由于最小延迟无法超过当前最大延迟，设置会失败。
B	错误：参数不会自动调整为 2000，而是直接报错。
C	错误：最大值不会被动调整为 4000，需显式设置。
D	正确：违反依赖规则导致 MySQL 返回错误。

总结

答案 D 正确，因为直接提高最小延迟至超过当前最大延迟时，MySQL 会因参数冲突拒绝操作。必须遵循先增大最大值、再增大最小值的顺序才能成功配置。

题目 19

How can mysql_multi be configured to allow MySQL instances to use the same port number?

A. The instances use different user accounts unique to each instance.

B. The instances listen on different IP addresses.

C. The instances use different socket names.

D. The instances have appropriate net masks set.

正确答案：B. The instances listen on different IP addresses.

关键分析

1. MySQL 多实例端口冲突的核心限制

默认情况下，每个 MySQL 实例必须使用唯一的端口号，否则会因端口占用导致服务启动失败。但在特定场景下，可通过网络层隔离绕过这一限制。

2. 选项解析

选项	分析
A. 使用不同用户账户	错误：用户账户权限与端口无关，无法解决端口冲突问题。
B. 监听不同 IP 地址	正确：若每个 MySQL 实例绑定到不同的 IP 地址（通过 `bind-address` 参数），即使使用相同端口号，网络层会根据目标 IP 路由请求，避免冲突。例如：实例 1 配置 `bind-address=192.168.1.100`，端口 3306。实例 2 配置 `bind-address=192.168.1.101`，端口 3306。
C. 使用不同 Socket名称	错误：Socket文件仅影响本地连接（如Unix域套接字），而端口用于网络通信。不同socket无法解决同一IP下端口冲突的问题。
D. 设置合适的网络掩码	错误：网络掩码（Netmask）用于 IP 子网划分，与端口分配无关。

3. 实现条件与注意事项

多 IP 配置：服务器需分配多个 IP 地址（如虚拟 IP 或物理网卡多 IP 绑定）。

配置文件调整：在每个实例的配置文件中指定唯一的 bind-address 和端口（例如）：

[mysqld1]
bind-address = 192.168.1.100
port = 3306

[mysqld2]
bind-address = 192.168.1.101
port = 3306

网络隔离验证：通过 netstat -tuln 检查各实例是否成功监听对应 IP + 端口组合。

总结

正确答案为 B。通过为每个 MySQL 实例绑定不同的 IP 地址，即使使用相同端口号，网络层会根据目标 IP 将请求路由到对应实例，从而规避端口冲突。其他选项（如用户账户、Socket 名称）均无法解决端口占用问题。

题目 20

Choose the best answer.

MySQL is installed on a Linux server with this configuration:

[mysqld]
user=mysql
datadir=/data/mysql

Which method sets the default authentication to SHA-256 hashing for authenticating user account passwords?

A. Define CREATE USER ' '@'%' IDENTIFIED WITH sha256_password in the MySQL instance.

B. Add default_authentication_plugin=sha256_password in the configuration file.

C. Add default_authentication_plugin=mysql_native_password in the configuration file.

D. Set validate-user-plugins=caching_sha2_password in the configuration file.

正确答案：B. Add default_authentication_plugin=sha256_password in the configuration file.

关键分析

1. MySQL 认证插件的配置逻辑

MySQL 通过 default_authentication_plugin 系统变量控制新用户的默认认证方式。要全局启用 SHA-256 哈希认证，需在配置文件中显式设置此参数为对应的插件名称。根据题目要求，需将默认认证方式改为 SHA-256，因此需在 [mysqld] 段添加 default_authentication_plugin=sha256_password。

2. 选项排除依据

选项	分析
A. `CREATE USER ... IDENTIFIED WITH sha256_password`	错误：此语法仅针对单个用户设置认证插件，而非全局默认值。题目要求的是全局配置，而非用户级临时修改。
B. 配置文件中添加 `default_authentication_plugin=sha256_password`	正确：通过修改配置文件（如 `my.cnf`）设置全局默认认证插件为 SHA-256，所有新用户将自动使用此认证方式。
C. 配置文件中添加 `default_authentication_plugin=mysql_native_password`	错误：`mysql_native_password` 是旧版默认插件，使用 SHA-1 哈希，与题目要求的 SHA-256 无关。
D. 设置 `validate-user-plugins=caching_sha2_password`	错误：`validate-user-plugins` 参数不存在。正确参数为 `default_authentication_plugin`，且 `caching_sha2_password` 是 MySQL 8.0 的默认插件，但题目明确要求使用 SHA-256，需匹配插件名称。

扩展：MySQL 认证插件与配置文件操作

配置文件生效方式
- 修改配置文件后需重启 MySQL 服务，例如：
```
systemctl restart mysqld  
```
- 重启后新连接的用户将默认使用 SHA-256 认证。
验证配置生效
- 执行以下 SQL 查询验证全局默认插件：
```
SHOW VARIABLES LIKE 'default_authentication_plugin';  
```
  预期输出应为 sha256_password。
兼容性注意事项
- 旧版客户端可能不支持 sha256_password 插件，需确保客户端库（如 Connector/J、PHP PDO）兼容此认证方式。
- 若需回退到旧认证方式（如 mysql_native_password），需在配置文件中修改对应参数并重启服务。

总结

正确答案为 B。通过修改 MySQL 配置文件中的 default_authentication_plugin 参数为 sha256_password，可全局启用 SHA-256 哈希认证。其他选项或仅限用户级配置（A）、或使用错误参数（C、D），均不符合题目要求。

题目 21

Examine these two reports taken 100 seconds apart:

GLOBAL STATUS 1:

Com_create_table=500005
Com_drop_table=500003
Com_flush=23
Create_tmp_disk_tables=400000
Create_tmp_tables=1200000
Max_used_connections=92
Open_files=5000
Opened_files=5000
Open_table_definitions=3000
Open_tables=1024
Opened_table_definitions=2369
Opened_tables=3500000
Threads_connected=62
Threads_running=58
Uptime=100000

GLOBAL STATUS 2:

Com_create_table=500505
Com_drop_table=500498
Com_flush=31
Create_tmp_disk_tables=400400
Create_tmp_tables=1201200
Max_used_connections=92
Open_files=5000
Opened_files=7505
Open_table_definitions=3000
Open_tables=1024
Opened_table_definitions=2873
Opened_tables=3503500
Threads_connected=67
Threads_running=64
Uptime=100000

Your MySQL system normally supports 50-75 concurrent connections. Which configuration change will improve performance?

A. decrease table_definition_cache

B. decrease open_files_limit

C. increase table_open_cache

D. increase max_connections

正确答案：C. increase table_open_cache

关键分析

1. 问题核心：表缓存不足导致频繁开表

从两次状态报告的对比中，关键指标 Opened_tables 在 100 秒内从 3,500,000 增长到 3,503,500（增加了 3,500 次），而 Open_tables 始终为 1024。这表明：

表缓存不足：Open_tables 是当前已缓存的表数量，而 Opened_tables 是历史累计打开表的总次数。频繁的 Opened_tables 增长说明表缓存无法容纳频繁访问的表，导致 MySQL 需要不断重新打开表。
表缓存命中率低：如果缓存足够，Opened_tables 的增长应趋缓，但当前配置下缓存无法满足需求，导致 I/O 和线程资源浪费。

2. table_open_cache 的作用与当前瓶颈

参数定义：table_open_cache 控制 MySQL 可缓存的表描述符数量。每个表被访问时，其元信息会被缓存以加速后续操作。
当前问题：Open_tables 稳定在 1024，而系统允许的并发连接数为 50-75。假设每个连接需要打开多个表（如复杂查询涉及多表 JOIN），当前 table_open_cache=1024 可能接近极限，无法缓存所有活跃表的元信息，导致频繁开表。
性能影响：频繁开表会增加文件描述符消耗、磁盘 I/O 和线程争用，降低查询效率。

3. 其他选项排除

选项	分析
A. 减少 `table_definition_cache`	错误：`Open_table_definitions` 稳定在 3000，说明表定义缓存未溢出。减少此参数会降低表结构元信息的缓存能力，可能加剧性能问题。
B. 减少 `open_files_limit`	错误：当前 `Open_files=5000` 未达到系统文件描述符限制（`open_files_limit`），且 `Opened_files` 增长与文件句柄无关，调整此参数无意义。
D. 增加 `max_connections`	错误：`Max_used_connections=92` 表明当前连接数未超过系统支持的 75 上限（可能配置为更高值）。增加连接数会消耗更多内存，但无法解决表缓存不足的核心问题。

4. 优化建议：调整 table_open_cache

调整逻辑：将 table_open_cache 设置为并发连接数与每个连接平均涉及表数的乘积。例如，若每个连接涉及 20 张表，则设置为 75×20=1500，并留一定冗余（如 2000）。
验证指标：调整后监控 Opened_tables 增速是否降低，且 Open_tables 接近新设置的缓存大小，说明缓存命中率提升。

总结

正确答案为 C。通过增加 table_open_cache 可显著减少频繁开表的开销，提升查询性能。其他选项或与当前瓶颈无关（A、B），或无法解决核心问题（D）。建议结合业务场景逐步调整参数并监控性能变化。

题目 22

Choose the best answer.

A colleague complains about slow response time on your website.

Examine this query and output:

mysql> show global status like 'Table_lock%';
+-----------------------+-------+
| Variable_name         | Value |
+-----------------------+-------+
| Table_locks_immediate | 53148 |
| Table_locks_waited    | 17716 |
+-----------------------+-------+
2 rows in set (0.00 sec)

What is the most likely cause for the high number of lock waits?

A. You use the InnoDB storage engine and statements wait while data is inserted.

B. The Innodb Buffer pool is full.

C. You use the MyISAM storage engine for most common tables.

D. Your table accesses wait for the operating system level flush.

正确答案：C. You use the MyISAM storage engine for most common tables.

关键分析

1. 表锁机制与存储引擎的关系

MySQL 的 Table_locks_waited 状态变量表示因表锁争用而需要等待的次数。其值高通常与存储引擎的锁机制直接相关：

MyISAM 引擎仅支持表级锁（读锁与写锁互斥），任何写入操作（INSERT/UPDATE/DELETE）都会独占表锁，阻塞其他读写操作。例如，若系统中有频繁的并发写入，MyISAM 表的 Table_locks_waited 会显著增加。
InnoDB 引擎默认使用行级锁，仅在少数场景（如显式执行 LOCK TABLES 或元数据锁）触发表级锁。因此，InnoDB 的表锁争用概率远低于 MyISAM。

2. 选项排除依据

选项	分析
A. InnoDB 存储引擎导致插入等待	错误：InnoDB 的插入操作通常使用行锁，仅锁定特定数据行，不会触发表级锁争用。`Table_locks_waited` 高与 InnoDB 无关。
B. InnoDB 缓冲池满	错误：缓冲池（Buffer Pool）满会影响数据读写性能，但不会直接导致表锁等待。表锁是存储引擎层的锁机制，与缓冲池无关。
C. MyISAM 引擎为主	正确：MyISAM 的表锁设计在高并发写入场景下必然导致大量锁等待。例如，若多个线程同时更新同一表，后续线程必须等待前序线程释放表锁，导致 `Table_locks_waited` 累积。
D. 操作系统级刷新等待	错误：表锁等待是数据库内部资源争用问题，与操作系统级别的文件刷新无关。此选项混淆了存储引擎锁与 I/O 操作。

3. 数据验证与优化建议

验证存储引擎类型：

SELECT TABLE_NAME, ENGINE  
FROM information_schema.TABLES  
WHERE TABLE_SCHEMA = 'your_database';

若结果中大部分表为 MyISAM，则选项 C 成立。

优化方向：
- 迁移表到 InnoDB：通过 ALTER TABLE table_name ENGINE=InnoDB 转换存储引擎，利用行级锁提升并发性。
- 调整 MyISAM 并发参数：若必须保留 MyISAM表，可设置 concurrent_insert=2 允许尾部并发插入，或降低写入优先级（low-priority-updates）缓解争用。
- 监控锁状态：持续观察 Table_locks_immediate 与 Table_locks_waited 比值。若后者持续增长，需优先优化表引擎。

总结

正确答案为 C。MyISAM 的表级锁机制在高并发场景下极易引发锁争用，导致 Table_locks_waited 显著升高。相比之下，InnoDB 的行级锁能有效减少此类问题。建议结合业务需求逐步迁移表引擎，并优化并发控制参数。

题目 23

Choose the best answer.

You have configured a working MySQL InnoDB Cluster in single-primary mode. What happens when the primary instance goes down due to a network problem?

A. The cluster will continue to function with read-only members.

B. A new primary is automatically elected.

C. The cluster goes into wait mode until a new member is manually promoted as primary.

D. The cluster detects network partitioning and shuts down to remain consistent.

E. All remaining members in the cluster are automatically set to read-write mode.

正确答案：B. A new primary is automatically elected.

关键分析

1. InnoDB Cluster 的自动故障转移机制

InnoDB Cluster 基于 Group Replication 实现高可用性。在单主模式（Single-Primary Mode）下，集群通过 Paxos 协议维护一致性，并具备以下特性：

主节点选举：当主节点（Primary）因网络问题或宕机不可用时，剩余的在线节点会通过多数派（Quorum）机制自动选举新的主节点。例如，在 3 节点集群中，若主节点失效，剩余两个节点可以形成多数（2/3 > 50%），触发自动选举。
Quorum 要求：选举的前提是剩余的在线节点必须构成网络主分区（Primary Partition），即满足节点数 > 总节点数/2。例如，3 节点集群需至少 2 个节点在线，5 节点集群需至少 3 个节点在线。

2. 选项排除依据

选项	分析
A. 集群继续以只读模式运行	错误：若剩余节点满足 Quorum，则会选举新主；若无法满足 Quorum（如仅剩 1 个节点），集群会进入 `NO_QUORUM` 状态，拒绝所有读写请求，而非仅允许只读。
B. 自动选举新主节点	正确：在单主模式下，只要剩余节点构成多数派，集群会自动触发选举流程，无需人工干预。例如，3 节点集群的主节点宕机后，剩余两个节点会快速选出新主。
C. 等待手动提升新主	错误：此情况仅在无法满足 Quorum（如网络分裂导致剩余节点不足半数）时发生。若 Quorum 存在，选举是自动的。
D. 集群关闭以保持一致性	错误：InnoDB Cluster 的设计目标是高可用性，即使部分节点失效，剩余节点仍会尝试维持服务。仅在所有节点无法达成共识时才会停止服务。
E. 剩余节点自动切换为读写模式	错误：单主模式下，仅主节点可读写，其他节点始终为只读。多主模式才允许所有节点读写，但本题明确为单主模式。

3. 特殊情况与注意事项

网络分区风险：若主节点宕机导致集群分裂为多个无法通信的分区（如 3 节点分裂为 1+2），仅包含多数节点的分区会选举新主，而少数节点的分区将进入 MISSING 状态，拒绝服务。
人工干预场景：当 Quorum 无法达成时（如 2 节点集群主节点宕机），需通过 group_replication_force_members 强制指定成员或手动修复网络问题。

总结

正确答案为 B。InnoDB Cluster 的自动故障转移机制依赖 Group Replication 的 Quorum 规则，在单主模式下，只要剩余节点满足多数派条件，即可自动选举新主节点，无需人工干预。其他选项或混淆了集群状态（如仅允许只读），或未考虑 Quorum 的核心作用（如手动提升），均不符合实际逻辑。

题目 24

Choose the best answer.

You have configured MySQL Enterprise Transparent Data Encryption (TDE). What command would you use to encrypt a table?

A. UPDATE <table> SET ENCRYPTION= 'Y';

B. ALTER INSTANCE ROTATE INNODB MASTER KEY;

C. UPDATE information_schema.tables SET encryption='Y' WHERE table_name='table';

D. ALTER TABLE <table> ENCRYPTION='Y';

正确答案：D. ALTER <table> TABLE ENCRYPTION='Y';

关键解析

1. MySQL TDE 加密表的操作逻辑

MySQL Enterprise 的透明数据加密（TDE）允许对表或表空间进行加密，其核心操作是通过 ALTER TABLE 语句修改表的加密属性。具体实现方式如下：

语法规范：通过 ALTER TABLE 添加 ENCRYPTION='Y' 参数，直接启用表的加密功能。例如：

ALTER TABLE your_table_name ENCRYPTION = 'Y';

此命令会触发表空间文件的加密操作，原有数据会被自动加密。

2. 选项排除依据

选项	分析
A. `UPDATE <table> SET ENCRYPTION='Y'`	错误：`UPDATE` 语句用于修改数据行的内容，而非表结构或加密属性。TDE 加密属于表级元数据操作，需通过 DDL 语句（如 `ALTER`）实现。
B. `ALTER INSTANCE ROTATE INNODB MASTER KEY`	错误：此命令用于轮换主加密密钥（Master Key），属于密钥管理操作，不会直接加密表数据。轮换密钥仅更新密钥版本，不影响已加密的表空间。
C. `UPDATE information_schema.tables`	错误：`information_schema.tables` 是系统视图，仅提供元数据查询功能，不支持直接通过 `UPDATE` 修改表加密状态。加密操作需通过 DDL 语句触发。
D. `ALTER TABLE <table> ENCRYPTION='Y'`	正确：符合 MySQL TDE 的语法规范，直接修改表的加密属性，适用于已存在的表。

3. 操作验证与注意事项

验证加密状态：

SELECT TABLE_NAME, CREATE_OPTIONS  
FROM information_schema.TABLES  
WHERE TABLE_NAME = 'your_table_name';

若返回结果包含 ENCRYPTION='Y'，则表已加密。

性能影响：加密过程会占用 I/O 和 CPU 资源，大表操作时需选择低峰时段。

总结

正确答案为 D。通过 ALTER TABLE <table> ENCRYPTION='Y' 可显式启用表的透明数据加密功能，其他选项或语法错误（A、C），或与密钥管理相关（B），均不符合加密表的操作需求。

题目 25

Choose the best answer.

A developer accidentally dropped the InnoDB table Customers from the Company database. There is a datadir copy from two days ago in the dbbackup directory. Which set of steps would restore only the missing table?

A. Stop the MySQL Server process and restart it with the command: mysqld --basedir=/usr/local/mysql --datadir=/dbbackup, Run mysqldump on this table and restore the dump file.

B. Stop the MySQL Server process and restart it with the command: mysqld --basedir=/usr/local/mysql --datadir=/var/lib/mysql, Run mysqldump on this table and restore the dump file.

C. Stop the MySQL Server process, copy the Customers.ibd file from the dbbackup directory, and start the mysqld process.

D. Stop the MySQL Server process, and execute: mysqlbackup --datadir=/var/lib/mysql --backup-dir=/dbbackup --include-tables= 'Company\. Customers' copy-back, Start the mysqld process.

正确答案：A. Stop the MySQL Server process and restart it with the command: mysqld --basedir=/usr/local/mysql --datadir=/dbbackup, Run mysqldump on this table and restore the dump file.

关键解析

1. 恢复逻辑与选项分析

InnoDB 表恢复需要同时满足表结构（元数据）和表数据（.ibd 文件）的完整性。题目中提供了两天前的 datadir 备份（包含完整的表结构和数据文件），但原数据库已删除该表，此时直接复制 .ibd 文件可能因元数据丢失而无法自动识别。

选项 A：
- 停止 MySQL 服务：避免写入冲突。
- 以备份的 datadir 启动临时实例：通过 mysqld --datadir=/dbbackup 启动新实例，直接读取备份的表结构和数据。
- 导出表数据：使用 mysqldump 导出 Customers 表，生成 SQL 备份文件。
- 恢复到原数据库：将 SQL 文件导入原数据库。
- 合理性：此方法绕过原数据库的元数据缺失问题，通过临时实例提取备份数据，再通过逻辑备份恢复，确保表结构和数据完整。
选项 C：
- 仅复制 .ibd 文件到原数据目录，但未处理元数据（如通过 ALTER TABLE ... IMPORT TABLESPACE），可能导致 MySQL 无法识别表。
选项 D：
- mysqlbackup 是 MySQL Enterprise Backup 工具的命令，但其语法中 --include-tables 参数通常用于备份筛选，而非恢复。copy-back 操作用于全量恢复，无法直接恢复单个表。

2. 排除其他选项

选项	分析
B	重启后 `datadir` 指向原目录（`/var/lib/mysql`），备份文件未被加载，无法导出目标表。
C	缺少元数据同步步骤（如创建表结构、导入表空间），直接复制 `.ibd` 文件会导致数据不可用。
D	`mysqlbackup` 语法错误，且 `copy-back` 不支持单表恢复。

3. 操作验证与注意事项

验证备份完整性：

确保备份的 datadir 中包含 Customers.frm（表结构文件）和 Customers.ibd（表数据文件）。

临时实例配置：

启动临时实例时需指定 --port 和 --socket 参数，避免与原实例冲突。

恢复后一致性检查：

使用 CHECK TABLE 验证表数据完整性，并对比备份时间点后的业务数据是否需要补录。

总结

正确答案为 A。通过临时实例加载备份的 datadir，导出目标表数据并恢复到原数据库，是安全且可靠的单表恢复方案。其他选项因缺少关键步骤或语法错误，无法满足需求。

题目 26

Choose the best answer.

Examine this partial report:

mysql> SHOW FULL PROCESSLIST;
+----+-----------------+-------------------+...
| Id | User            | Host              | ...
+----+-----------------+-------------------+...
|  4 | event_scheduler | localhost         | ...
|  9 | root            | localhost:51502   | ...
| 10 | root            | localhost:51670   | ...

Examine this query:

SELECT SUM(m.CURRENT_NUMBER_OF_BYTES_USED) AS TOTAL
FROM performance_schema.memory_summary_by_thread_by_event_name m
INNER JOIN performance_schema.threads t
ON m.THREAD_ID = t.THREAD_ID
WHERE t.PROCESSLIST_ID = 10;

What information does this query provide?

A. total memory used by connection number 10

B. total memory used across all connections associated with the user on connection number 10

C. total memory used by the first 10 threads

D. total memory used by thread number 10

E. total memory used across all connections associated with the user on thread number 10

F. total memory used by the first 10 connections

正确答案：A. total memory used by connection number 10

关键解析

1. 查询逻辑与数据结构

SHOW FULL PROCESSLIST 显示的 Id 列对应 performance_schema.threads 表中的 PROCESSLIST_ID，表示每个客户端连接的标识符。
memory_summary_by_thread_by_event_name 表记录了按线程（THREAD_ID）和事件分类的实时内存使用情况，包括当前未释放的内存字节数（CURRENT_NUMBER_OF_BYTES_USED）。
关联条件 ON m.THREAD_ID = t.THREAD_ID 将内存使用数据与线程元数据绑定，而 WHERE t.PROCESSLIST_ID = 10 筛选出连接号为 10 的线程。

2. 选项排除依据

选项	分析
A. 连接号 10 使用的总内存	正确：查询通过 `PROCESSLIST_ID=10` 定位到具体连接对应的线程（`THREAD_ID`），并汇总该线程所有事件的内存使用量。这直接反映了连接号 10 的实时内存消耗。
B/D/E. 用户或线程关联的扩展统计	错误：查询仅针对 `PROCESSLIST_ID=10` 的单个连接，未按用户或线程组聚合（如 `USER` 或 `THREAD_ID` 分组），排除 B、D、E。
C/F. 前 10 线程或连接的总内存	错误：查询未使用 `LIMIT 10` 或范围条件，`PROCESSLIST_ID=10` 是特定连接标识符，而非前 10 的统计。

3. 数据验证与扩展

验证线程与连接关系：

通过以下查询可确认 PROCESSLIST_ID=10 对应的线程详细信息：

SELECT * FROM performance_schema.threads WHERE PROCESSLIST_ID = 10;

结果中的 THREAD_ID 会与内存表中的记录关联。

内存使用明细：

若需进一步分析连接 10 的内存分配详情，可运行：

SELECT EVENT_NAME, CURRENT_NUMBER_OF_BYTES_USED  
FROM memory_summary_by_thread_by_event_name  
WHERE THREAD_ID = (SELECT THREAD_ID FROM threads WHERE PROCESSLIST_ID = 10);

这将列出每个事件的内存占用，帮助定位高消耗模块（如 InnoDB 缓冲池或临时表）。

总结

正确答案为 A。该查询通过关联线程与内存统计表，精准计算了连接号 10 的实时内存使用总量，符合 PROCESSLIST_ID 与内存数据的映射逻辑。其他选项或混淆了标识符层级，或误读聚合范围，均不符合题意。

题目 27

Examine this command, which executes successfully:

mysqlbackup --user=dba --password --port=3306 --with-timestamp --backup-dir=/export/backups backup-and-apply-log

Which statement is true?

A. The backup accesses the MySQL server files by using a pre-existing connection.

B. The database server is put into a read-only state for the duration of the backup.

C. An offline backup of InnoDB tables is taken.

D. The backup can be impacted when DDL operations run during the backup.

正确答案：D. The backup can be impacted when DDL operations run during the backup.

关键解析

1. 命令功能与备份逻辑

题目中的命令 mysqlbackup --user=dba --password --port=3306 --with-timestamp --backup-dir=/export/backups backup-and-apply-log 是 MySQL Enterprise Backup 的典型用法，其核心逻辑为：

backup-and-apply-log：在备份过程中同时完成在线热备份和事务日志（Redo Log）的应用。
InnoDB 热备份：对 InnoDB 表进行在线备份，允许 DML（数据操作语言，如 INSERT/UPDATE）操作继续执行，但 DDL（数据定义语言，如 ALTER TABLE）操作可能引发冲突。

2. 选项排除依据

选项	分析
A. 使用预先存在的连接访问 MySQL 服务器文件	错误：`mysqlbackup` 通过 `--user`、`--port` 等参数建立新的独立连接，而非依赖预先存在的连接。备份进程需要直接与 MySQL 服务器通信以追踪事务日志和元数据。
B. 数据库在备份期间被设置为只读状态	错误：InnoDB 表的热备份不会阻塞读写操作（DML），但非 InnoDB 表（如 MyISAM）可能被临时锁定为只读状态。整个数据库不会进入全局只读状态，因此此选项不成立。
C. 对 InnoDB 表进行离线备份	错误：`backup-and-apply-log` 是在线热备份，无需关闭 MySQL 服务。离线备份（冷备份）需停止 MySQL 服务并直接复制数据文件。
D. DDL 操作可能影响备份	正确：在备份过程中，若执行 DDL（如 ALTER TABLE），会导致以下问题：元数据锁冲突：备份需要读取表结构元数据，而 DDL 会修改元数据，导致备份进程阻塞或失败。数据不一致风险：DDL 操作可能改变表结构，若备份未完成，会导致备份文件与最终表结构不一致。

3. 扩展验证与场景分析

DDL 操作的具体影响：

若在备份期间执行 ALTER TABLE，备份进程可能因无法获取一致的元数据快照而失败，需手动重试或调整备份时间窗口。
MySQL Enterprise Backup 通过 LOCK INSTANCE FOR BACKUP 语句阻止 DDL 操作，但若 DDL 在备份前已启动，可能导致备份中断。

建议操作：

避免在备份窗口执行 DDL。
使用监控工具检测 DDL 操作，并在备份前暂停相关任务。
采用增量备份或调整备份策略以减少全量备份时间窗口。

总结

正确答案为 D。mysqlbackup 的在线热备份机制允许 DML 操作，但 DDL 操作会因元数据锁冲突导致备份失败或数据不一致。其他选项或混淆连接方式（A）、误读备份状态（B/C），均不符合实际逻辑。

题目 28

In MySQL 8.0，Database test contains a table named city that has the InnoDB storage engine.

CREATE TABLE "city" (
  'ID' int NOT NULL AUTO_INCREMENT,
  'Name' char(35) NOT NULL DEFAULT '',
  'CountryCode' char(3) NOT NULL DEFAULT '',
  'District' char(20) NOT NULL DEFAULT '',
  'Population' int NOT NULL DEFAULT '0',
  PRIMARY KEY ('ID'),
  KEY 'CountryCode' ('CountryCode')
) ENGINE=InnoDB TABLESPACE=innodb_file_per_table;

What is the content of the test folder in the data directory?

A. city.MYD, city.MYI, and city.sdi

B. city.ibd

C. city.ibd and city.sdi

D. city.ibd and city.frm

E. city.ibd, city.frm, and city.sdi

正确答案：B. city.ibd

关键解析

1. MySQL 8.0 文件结构的变化

在 MySQL 8.0 及更高版本中，InnoDB 存储引擎的元数据管理发生了重大调整：

.frm 文件被弃用：表结构（如列定义、索引信息）不再存储在单独的 .frm 文件中，而是集成到系统数据字典中。
.ibd 文件的功能扩展：每个启用 innodb_file_per_table 的 InnoDB 表会生成一个独立的 .ibd 文件，该文件不仅包含表数据和索引，还通过元数据序列化技术将表结构信息直接嵌入 .ibd 文件内部。

2. 选项排除依据

选项	分析
A. `city.MYD`, `city.MYI`, `city.sdi`	错误：`.MYD` 和 `.MYI` 是 MyISAM 引擎的数据和索引文件，与 InnoDB 无关。`.sdi` 是 MySQL 8.0 中 MyISAM 表的元数据文件，而题目明确使用 InnoDB。
B. `city.ibd`	正确：在 MySQL 8.0 的独立表空间模式下，每个 InnoDB 表仅生成一个 `.ibd` 文件，整合了表数据、索引及元数据（无需 `.frm` 或 `.sdi`）。
C. `city.ibd` 和 `city.sdi`	错误：InnoDB 表不会生成 `.sdi` 文件，此文件仅用于 MyISAM 表的结构存储。
D. `city.ibd` 和 `city.frm`	错误：`.frm` 文件在 MySQL 8.0 中已废弃，InnoDB 表的元数据通过数据字典和 `.ibd` 文件管理。
E. `city.ibd`, `city.frm`, `city.sdi`	错误：同时包含三种文件不符合任何版本的存储规则，混淆了不同引擎的特性。

3. 版本兼容性与文件验证

MySQL 5.7 及更早版本：InnoDB 表会生成 .frm（表结构）和 .ibd（数据与索引）文件。

MySQL 8.0+：仅需 .ibd 文件，且通过以下查询可验证表结构是否嵌入其中：

SELECT * FROM INFORMATION_SCHEMA.INNODB_TABLES WHERE NAME = 'test/city';

结果将显示表结构元数据已通过系统数据字典管理。

4. 企业实践建议

备份与恢复：直接复制 .ibd 文件可能无法恢复表，需结合 FLUSH TABLES 或 mysqldump 确保元数据一致性。
存储优化：启用 innodb_file_per_table 可避免系统表空间膨胀，提升大表管理和空间回收效率。

总结

正确答案为 B。MySQL 8.0 的 InnoDB 独立表空间模式下，test 数据库目录仅包含 city.ibd 文件，其他选项混淆了存储引擎（如 MyISAM）或版本特性（如 MySQL 5.7 的 .frm 文件），均不符合题意。

题目 29

Choose the best answer.

Examine this command, which executes successfully:

$ mysqlrouter --bootstrap user@hostname:port --directory=directory_path

Which activity is performed?

A. MySQL Router configures itself based on the information retrieved from the InnoDB cluster metadata server.

B. MySQL Router configures all the cluster nodes based on the information retrieved from the InnoDB cluster metadata server.

C. MySQL Router is restarted.

D. MySQL Router is configured based on the information in files in directory_path.

正确答案：A. MySQL Router configures itself based on the information retrieved from the InnoDB cluster metadata server.

关键解析

1. Bootstrap 命令的核心功能

题目中的命令 mysqlrouter --bootstrap user@hostname:port --directory=directory_path 是 MySQL Router 的初始化操作，其核心逻辑为：

连接到 InnoDB 集群元数据服务器：通过 --bootstrap 参数指定的服务器地址（如 user@hostname:port），MySQL Router 会访问该节点的元数据（如集群成员、拓扑结构等）。
自动生成配置：基于元数据信息，Router 会自动创建配置文件（如 mysqlrouter.conf）、账户信息及密钥文件，并将这些文件存储在 --directory 指定的目录中。

2. 选项排除依据

选项	分析
A. Router 根据元数据服务器信息自行配置	正确：Bootstrap 的核心功能是从 InnoDB 集群元数据服务器获取集群信息（如读写节点、端口分配），并生成路由规则和配置文件。这一过程无需手动干预。
B. 配置所有集群节点	错误：MySQL Router 仅配置自身路由规则，不会修改集群节点的配置或状态。集群节点的管理由 InnoDB Cluster 自身完成。
C. 重启 Router	错误：Bootstrap 是初始化配置的过程，而非重启服务。重启通常需通过 `systemctl` 或启动脚本手动执行。
D. 基于 directory_path 中的文件配置	错误：`--directory` 参数指定的是配置文件的输出目录，而非输入。Bootstrap 是根据元数据动态生成新配置，而非依赖目录中已有文件。

3. 流程验证与扩展说明

执行 Bootstrap 后，目标目录中会生成以下文件：

mysqlrouter.conf：路由规则、端口绑定及集群元数据缓存配置。
data/：密钥文件（如 keyring）及安全凭证。
启停脚本（如 start.sh 和 stop.sh）。

元数据依赖： Router 通过元数据服务器（如 MGR 主节点）获取集群的动态信息（如主从切换、节点增减），从而实现透明路由。

4. 企业实践建议

多实例部署：通过 --directory 和 --name 参数，可在同一服务器部署多个 Router 实例，分别服务不同集群。
安全优化：建议为 Router 创建独立账户（如 --account routerfriend），避免使用 root 权限运行。

总结

正确答案为 A。Bootstrap 过程通过连接 InnoDB 集群元数据服务器动态生成 Router 配置，其他选项或混淆功能范围（B/D）或误读操作阶段（C），均不符合实际逻辑。

题目 30

Choose the best answer.

You issue this command:

SHOW SLAVE STATUS

In the output, there is a value for Seconds_behind_master. How is this time calculated?

A. It is the time between the I/O thread receiving details of the master's last transaction and the time it was applied by the SQL thread.

B. It is the time between the most recent transaction written to the relay logs and the time it was committed on the master.

C. It is the time between the I/O thread receiving details of the master’s last transaction and the time it was written to the relay log on the slave.

D. It is the time between the most recent transaction applied by a SQL thread and the time it was committed on the master.

正确答案：D. It is the time between the most recent transaction applied by a SQL thread and the time it was committed on the master.

关键解析

1. Seconds_Behind_Master 的核心计算逻辑

Seconds_Behind_Master 的计算基于以下两个时间点的差值：

主库事务提交时间：即事务在主库执行时记录到 Binlog 的事件时间戳（last_master_timestamp）；
从库应用事务的时间：从库 SQL 线程执行该事务时，从库服务器的当前时间（clock_of_slave）。

具体公式为：

Seconds_Behind_Master=从库当前时间−主库事件时间戳−主从时间差校正值

其中，主从时间差校正值（clock_diff_with_master）在 I/O 线程启动时计算，用于消除主从服务器时钟差异的影响。

2. 选项排除依据

选项	分析
A. I/O 线程接收主库最后事务的时间与 SQL 线程应用时间的差	错误：I/O 线程仅负责拉取 Binlog 并生成 Relay Log，与 SQL 线程的延迟无关。`Seconds_Behind_Master` 不涉及 I/O 线程的时间。
B. Relay Log 中最新事务写入时间与主库提交时间的差	错误：Relay Log 的写入时间由 I/O 线程完成，但计算中仅使用主库事件时间戳和从库当前时间，与 Relay Log 的写入时间无关。
C. I/O 线程接收主库事务的时间与 Relay Log 写入时间的差	错误：此描述混淆了 I/O 线程的日志拉取与 Relay Log 的写入过程，未涉及 SQL 线程的执行时间差。
D. SQL 线程应用事务的时间与主库提交时间的差	正确：完全符合官方定义。计算基于主库事件时间戳（事务提交时间）和从库应用时的本地时间差值，并校正主从时钟差异。

3. 特殊场景下的计算修正

主从时钟不一致：I/O 线程启动时会通过 SELECT UNIX_TIMESTAMP() 计算主从时间差，并在后续计算中动态校正。
大事务延迟：若主库执行一个大事务（如批量更新），从库的 last_master_timestamp 仅在事务完成后更新，此时 Seconds_Behind_Master 可能突增至事务执行时间，而非逐步累积。
并行复制：在 MySQL 5.7+ 多线程复制中，last_master_timestamp 基于事务组的检查点（LWM）更新，可能导致延迟统计不完全实时。

4. 参数局限性

尽管 Seconds_Behind_Master 是常用指标，但其局限性包括：

不反映 I/O 线程的网络延迟：若主库 Binlog 未及时传输到从库，但 SQL 线程已执行完现有 relay log，该值会误报为 0；
无法覆盖并行复制的多线程差异：各 Worker 线程的延迟可能被平均化，掩盖单线程滞后问题；
依赖主库事件时间戳的准确性：若主库 Binlog 写入延迟（如 sync_binlog=0），事件时间戳与实际执行时间可能脱节。

总结

正确答案为 D。Seconds_Behind_Master 的计算本质上是主库事务提交时间与从库应用时间的差值，并动态校正主从时钟差异。其他选项或混淆线程角色（A/C），或误用时间节点（B），均不符合实际逻辑。

题目 31

Consider this shell output and executed commands:

[root@oel7~] # ps aux | grep mysqld
mysql 2076 3.5 24.6 1386852 372572 2 Ssl 12:01 0:01 /usr/sbin/mysqld
[root@oel7 ~]# kill -15 2076

Which statement is true about MySQL server shutdown?

A. kill -15 and kill -9 are effectively the same forced shutdown that risk committed transactions not written to disk.

B. mysqld safe prohibits commands that would harm the operation of the server. An error would be returned by the kill command.

C. kill -15 carries out a normal shutdown process, such as mysqladmin shutdown.

D. kill -15 should be avoided. Use other methods such as mysqladmin shutdowm or systemctl stop mysqld.

正确答案：C. kill -15 carries out a normal shutdown process, such as mysqladmin shutdown.

关键解析

1. kill -15 的关闭机制

kill -15（发送 SIGTERM 信号）会触发 MySQL 的正常关闭流程，包括以下步骤：

拒绝新连接：停止接受新的客户端连接请求。
终止活跃线程：标记所有线程为 killed 状态，等待其完成当前操作（如事务回滚）。
刷新数据到磁盘：
- 将 InnoDB 缓冲池（innodb_buffer_pool）中的脏页写入磁盘（除非 innodb_fast_shutdown=2）。
- 记录最新的 LSN（Log Sequence Number）到表空间文件。
- 关闭所有打开的表并刷新表结构缓存。
- 关闭存储引擎：如 InnoDB 的线程和资源。

此过程与 mysqladmin shutdown 或 systemctl stop mysqld 的底层逻辑完全一致。

2. 选项排除依据

选项	分析
A. `kill -15` 与 `kill -9` 同为强制关闭	错误：`kill -9`（`SIGKILL`）会强制终止进程，跳过所有清理步骤，可能导致事务未持久化或数据损坏。而 `kill -15` 允许 MySQL 完成正常关闭流程，两者本质不同。
B. `mysqld_safe` 阻止 `kill` 命令	错误：`mysqld_safe` 仅作为守护进程监控 MySQL 服务，不会拦截操作系统的 `kill` 信号。`kill` 命令由操作系统直接处理，不会返回错误。
C. `kill -15` 执行正常关闭	正确：如前述分析，`SIGTERM` 信号触发 MySQL 的完整关闭流程，与 `mysqladmin shutdown` 等价。
D. 应避免 `kill -15`，改用其他方法	部分正确但非最佳：虽然推荐优先使用 `mysqladmin shutdown` 或 `systemctl stop mysqld`（更友好），但 `kill -15` 本身是安全的正常关闭方式，并非需要“避免”。

3. 扩展说明与场景对比

mysqladmin shutdown 的底层实现：

该命令通过向 MySQL 服务发送关闭请求，最终触发与 kill -15 相同的关闭流程（内部调用 SIGTERM）。

systemctl stop mysqld 的行为：

在 Systemd 管理的系统中，此命令会发送 SIGTERM 信号，等同于 kill -15。若服务配置了 Restart=on-failure，SIGTERM 可能不会触发自动重启（因退出码为 0），而 SIGKILL 会触发。

半同步复制的特殊场景：

在 MySQL 半同步复制（after_sync 模式）中，kill -15 可能导致主库强制转为异步模式后关闭，从而引发主从不一致。此时 kill -9 反而更安全（客户端收到失败响应，事务未提交）。

总结

正确答案为 C。kill -15 是 MySQL 的正常关闭方式，其行为与 mysqladmin shutdown 一致。其他选项或混淆信号类型（A），或误读进程管理机制（B/D），均不符合实际逻辑。

题目 32

Choose the best answer.

Examine these entries from the general query log:

Time                         Id Command Argument
2019-12-17T00:36:23.389450Z  24 Connect root@localhost on mydb using SSL/TLS
2019-12-17T00:36:23.389754Z  24 Query   select @@version_comment limit 1
2019-12-17T00:36:23.3929519Z 25 Connect root@localhost on mydb using SSL/TLS
2019-12-17T00:36:23.3929846Z 25 Query   select @@version_comment limit 1
2019-12-17T00:36:27.633082Z  24 Query   START TRANSACTION
2019-12-17T00:36:30.321657Z  24 Query   UPDATE t1 SET val = 1 WHERE ID = 130
2019-12-17T00:36:32.417433Z  25 Query   START TRANSACTION
2019-12-17T00:36:33.617642Z  25 Query   UPDATE t2 SET val = 5 WHERE ID = 3805
2019-12-17T00:36:36.049458Z  25 Query   UPDATE t1 SET val = 10 WHERE ID = 130
2019-12-17T00:36:38.513674Z  24 Query   UPDATE t2 SET val = 42 WHERE ID = 3805

All UPDATE statements reference existing rows.

Which describes the outcome of the sequence of statements?

A. Connection 24 experiences a lock wait timeout.

B. Connection 25 experiences a lock wait timeout.

C. A deadlock occurs immediately.

D. All statements execute without error.

E. A deadlock occurs after innodb_lock_wait_timeout seconds.

正确答案：C. A deadlock occurs immediately.

关键解析

1. 事务操作顺序与锁竞争分析

根据查询日志的时间线，两个连接的事务操作形成了循环等待锁的典型死锁场景：

连接 24：
- 持有 t1 表 ID=130 的行锁（通过 UPDATE t1 获取）
- 尝试获取 t2 表 ID=3805 的行锁（被连接25占用）
连接 25：
- 持有 t2 表 ID=3805 的行锁（通过 UPDATE t2 获取）
- 尝试获取 t1 表 ID=130 的行锁（被连接24占用）

这种交叉锁定（A 等 B 的锁，B 等 A 的锁）直接满足了死锁的四个必要条件：互斥、占有且等待、不可抢占、循环等待。

2. InnoDB 的死锁检测机制

MySQL 默认启用 innodb_deadlock_detect（死锁检测），检测到死锁后会立即终止其中一个事务（通常选择回滚代价较小的）。整个过程不需要等待 innodb_lock_wait_timeout（默认50秒）：

连接 25 的第二次 UPDATE t1（00:36:36）被阻塞，等待连接 24 释放 t1 的锁。
连接 24 的 UPDATE t2（00:36:38）被阻塞，等待连接 25 释放 t2 的锁。
InnoDB 在检测到循环依赖后，立即触发死锁回滚（而非等待超时）。

3. 选项排除依据

选项	分析
A/B. 锁等待超时	错误：`lock wait timeout` 仅在无死锁但长时间等待锁时触发（如单一线程持续等待），而此处是循环等待触发的死锁，检测机制会立即介入。
C. 立即死锁	正确：根据 InnoDB 的死锁检测逻辑，死锁会在两个事务互相等待的瞬间被识别并处理。
D. 无错误执行	错误：至少有一个事务会被回滚，返回 `ERROR 1213 (40001): Deadlock found`。
E. 超时后死锁	错误：死锁的解决依赖检测而非超时机制。超时参数用于处理非死锁的锁等待场景。

4. 补充验证

通过 SHOW ENGINE INNODB STATUS 可查看 LATEST DETECTED DEADLOCK 日志，其中会记录两个事务的锁等待链，并明确标注回滚的事务 ID。这与题目中的操作顺序完全匹配。

总结

正确答案为 C。InnoDB 的死锁检测机制会在循环等待形成的瞬间触发回滚，而非依赖超时参数。其他选项混淆了死锁检测与锁等待超时的适用场景，或错误假设所有操作能成功执行。

题目 33

Choose the best answer.

You reconfigure and start a slave that was not replicating for several days. The configuration file and CHANGE MASTER command are correct. Examine the GTID information from both master and slave:

Master:
gtids_executed: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-321,
                bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb:1-50,
                cccccccc-cccc-cccc-cccc-cccccccccccc:1234-1237

gtids_purged:   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-100,
                bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb:1-10,
                cccccccc-cccc-cccc-cccc-cccccccccccc:1234-1237

Slave:
gtids_executed: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-160,
                cccccccc-cccc-cccc-cccc-cccccccccccc:1234-1237

gtids_purged:   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-70,
                cccccccc-cccc-cccc-cccc-cccccccccccc:1234-1237

Which statement is true?

A. Replication will fail because the master has already purged transactions with ccccc-cccc-cccc-ccc-cccccccccc GTIDs.

B. Replication will work.

C. Replication will fail because the master does not have the required transaction with bbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbb GTIDs in its binary logs.

D. Replication will fail because the slave has purged more aaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa transactions than the master.

E. Replication will fail because of inconsistent numbers in ccccccc-cccc-cccc-ccccccccccccc GTIDs.

正确答案： C. Replication will fail because the master does not have the required transaction with bbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbb GTIDs in its binary logs.

关键分析

GTID 复制机制与问题判定：

主从 GTID 状态对比
- 主库的 gtids_purged：
  - bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb:1-10（已清除 Binlog 中的事务 1-10）
  - aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-100
  - cccccccc-cccc-cccc-cccc-cccccccccccc:1234-1237
- 主库的 gtids_executed：
  - bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb:1-50（Binlog 中仅保留事务 11-50）
- 从库的 gtids_executed：
  - 完全未包含 bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb 的 GTID 记录。
复制的核心逻辑
- 从库启动复制时，会基于 MASTER_AUTO_POSITION=1 向主库请求所有未执行的 GTID。主库需提供从库缺失的 GTID 事务（包括 bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb:1-50），但主库已通过 gtids_purged 清除了 1-10 的 Binlog，导致主库无法提供事务 1-10。
GTID 的连续性要求
- GTID 要求事务连续执行。从库需要从 bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb:1 开始执行，但主库的 Binlog 中仅保留 11-50，导致事务空洞（1-10 缺失）。此时，主库无法满足从库的请求，触发错误 ER_MASTER_HAS_PURGED_REQUIRED_GTIDS，复制失败。

选项排除依据

选项	分析
A. 主库已清除 `cccc` 的 GTID	错误：主库的 `gtids_purged` 和 `gtids_executed` 中 `cccc` 的区间一致（1234-1237），且从库已完全同步，无冲突。
B. 复制正常	错误：`bbbb` 的 GTID 1-10 缺失导致主库无法提供完整事务链，复制中断。
C. 主库缺少 `bbbb` 的 1-10 事务	正确：主库的 Binlog 中已清除 `bbbb:1-10`，而从库需要执行完整的事务链（1-50），导致复制失败。
D. 从库清除的 `aaaa` 事务更多	错误：主库 `purged` 到 `aaaa:1-100`，从库 `purged` 到 `1-70`，但主库的 `executed` 包含 `1-321`，从库需执行 `161-321`（主库 Binlog 保留 101-321，可正常发送）。
E. `cccc` 的 GTID 不一致	错误：主从库的 `cccc` GTID 完全一致（1234-1237），无冲突。

总结

复制失败的根本原因是：主库已清除从库需要的 bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb:1-10 事务，导致 GTID 连续性被破坏。此场景符合选项 C 的描述。解决方案需通过备份恢复或重置 GTID 状态以填补事务空洞。

题目 34

Choose the best answer.

Examine this command, which executes successfull

mysqlbackup --defaults-file=/backups/server-my.cnf --backup-dir=/backups/full copy-back

Which statement is true about the copy-back process?

A. The copy-back process is used to overwrite a new backup over an existing backup.

B. It restores files from the data directory to their original MySQL server locations.

C. It restores files from the backup directory to their original MySQL server locations.

D. The copy-back process makes inconsistent backups.

正确答案：C. It restores files from the backup directory to their original MySQL server locations.

关键解析

1. copy-back 命令的核心功能

mysqlbackup --copy-back 的作用是将备份目录中的文件恢复到 MySQL 服务器的原始数据目录（如 datadir 指定的路径）。具体流程包括：

停止 MySQL 服务：确保数据目录未被占用。
清空数据目录：需手动清空目标目录，避免文件冲突。
从备份目录复制文件：将备份文件（如数据文件、日志文件）按原路径复制到 MySQL 的数据目录中。
权限调整与启动服务：恢复后需赋予 MySQL 用户权限并重启服务。

2. 选项排除依据

选项	分析
A. 覆盖现有备份	错误：`copy-back` 用于恢复数据到 MySQL 服务器的原始位置，而非覆盖备份文件。覆盖备份的操作通常由备份工具（如 `innobackupex`）的增量备份机制处理。
B. 从数据目录恢复	错误：`copy-back` 的源是备份目录（由 `--backup-dir` 指定），而非当前数据目录。数据目录在恢复前通常是空的。
C. 从备份目录恢复	正确：与官方文档一致，`copy-back` 明确从备份目录中读取文件并恢复到 MySQL 的原始路径（如 `/var/lib/mysql`）。
D. 导致不一致备份	错误：`copy-back` 本身不涉及备份一致性。在恢复前需执行 `apply-log` 步骤（合并事务日志以确保数据一致性），若未执行此步骤直接使用 `copy-back` 才会导致问题。

3. 补充说明

备份目录：由 --backup-dir 指定，保存备份文件（如 ibdata1、ib_logfile* 等）。
数据目录：由 MySQL 配置文件中的 datadir 定义，是 MySQL 实际运行时的数据存储位置。

copy-back 的安全限制：

目标数据目录必须为空，否则 copy-back 会报错。
需确保备份文件完整且已通过 apply-log 处理（若备份时未使用 backup-and-apply-log 合并操作）。

总结

正确答案为 C。mysqlbackup --copy-back 的核心功能是将备份目录中的文件还原到 MySQL 服务器的原始数据目录，恢复数据库到备份时的状态。其他选项或混淆了备份与恢复的流程（A/B），或误读数据一致性逻辑（D），均不符合实际逻辑。

题目 35

Choose the best answer.

Your my.cnf file contains these settings:

[mysqld]
log_output=FILE
slow_query_log
long_query_time=2.01
log_queries_not_using_indexes

You want to log queries that looked at a minimum of 5000 records and either took longer than 5 seconds to run or did not use indexes.

Which contains all the settings that you need to add to or modify the slow log configuration?

A. min_examined_row_limit=5000

B. long_query_time=5 log_throttle_queries_not_using_indexes=5

C. log_throttle_queries_not_using_indexes=5 min_examined_ row_limit=5000

D. long_query_time=5

E. long_query_time=5 min_examined_row_limit=5000

F. log_throttle_queries_not_using_indexes=5

G. long_query_time=5 log_throttle_queries_not_using_indexes=5 min_examined_row_limit=5000

正确答案：

E. long_query_time=5 min_examined_row_limit=5000

关键解析

1. 需求拆解

用户需要记录满足以下所有条件的查询：

条件 1：检查的记录数 ≥5000 行（对应 min_examined_row_limit）；
条件 2：执行时间 >5 秒（对应 long_query_time）或未使用索引（对应 log_queries_not_using_indexes）。

2. 现有配置分析

原配置已包含：

[mysqld]
log_output=FILE       # 日志输出到文件（已满足）
slow_query_log         # 开启慢查询日志（已满足）
long_query_time=2.01  # 当前阈值为2.01秒（需修改为5秒）
log_queries_not_using_indexes  # 记录未使用索引的查询（已满足）

缺失参数：

min_examined_row_limit=5000：确保仅记录检查行数 ≥5000 的查询；
long_query_time=5：调整执行时间阈值至 5 秒。

3. 选项排除依据

选项	分析
A (`min_examined_row_limit=5000`)	不完整：未调整 `long_query_time`（当前值为2.01秒，需改为5秒）。
B (`long_query_time=5` + `log_throttle_queries_not_using_indexes=5`)	错误：`log_throttle_queries_not_using_indexes` 用于限制每分钟记录未使用索引的查询数量，但题目未要求限流，无需添加。
C (`log_throttle_queries_not_using_indexes=5` + `min_examined_row_limit=5000`)	错误：同上，`log_throttle` 不必要，且未调整执行时间阈值。
D (`long_query_time=5`)	不完整：缺少 `min_examined_row_limit=5000`。
E (`long_query_time=5` + `min_examined_row_limit=5000`)	正确：完全覆盖需求条件。
F (`log_throttle_queries_not_using_indexes=5`)	错误：无关参数，未解决核心需求。
G (`long_query_time=5` + `log_throttle_queries_not_using_indexes=5` + `min_examined_row_limit=5000`)	冗余：`log_throttle` 非必要，题目未要求限制未使用索引查询的记录频率。

4. 补充说明

min_examined_row_limit 的作用：该参数确保仅记录扫描行数 ≥5000 的查询，避免记录小数据量的慢查询（如全表扫描但行数少的场景）。
log_queries_not_using_indexes 的独立性：已开启的配置会自动记录未使用索引的查询，无论其执行时间是否超过阈值。但需注意，若未调整 long_query_time，原配置（2.01秒）会错误记录执行时间在 2.01 秒至 5 秒之间的未使用索引查询，因此必须将 long_query_time 设为 5 秒以精准匹配需求。

总结

正确答案为 E。需调整 long_query_time=5 并添加 min_examined_row_limit=5000，既满足执行时间阈值要求，又确保仅记录检查行数 ≥5000 的查询。其他选项或遗漏关键参数，或引入冗余配置，均不符合需求。

题目 36

Choose the best answer.

Which statement is true about InnoDB persistent index statistics?

A. Increasing innodb_stats_persistent_sample_pages determines higher pages scanning speed, at the cost of increased memory usage.

B. Execution plans based on transient index statistics improve precision when innodb_stats_persistent_sample_pages is increased.

C. Index statistics are calculated from pages buffered in the buffer pool for tables with InnoDB storage engine.

D. Setting innodb_stats_auto_recalc=ON causes statistics to be updated automatically when a new index is created.

E. Updating index statistics is an I/O expensive operation.

正确答案：E. Updating index statistics is an I/O expensive operation.

关键解析

选项逐项分析

选项	判定依据与关键结论
A. 增加 `innodb_stats_persistent_sample_pages` 会提高页面扫描速度，但增加内存使用	错误。该参数控制采样的索引页数量，增大它会提高统计信息的准确性，但代价是 I/O 开销增加和 `ANALYZE TABLE` 执行时间延长，而非内存使用增加。
B. 基于瞬态统计信息的执行计划精度随 `innodb_stats_persistent_sample_pages` 增加而提高	错误。瞬态统计信息由 `innodb_stats_transient_sample_pages` 控制，与持久化参数无关。持久化统计信息与瞬态统计信息是两种不同的机制，参数作用对象不同。
C. InnoDB 表的索引统计信息基于缓冲池中的页计算	错误。统计信息通过随机采样索引页计算，这些页可能来自磁盘或缓冲池，但并非仅依赖缓冲池中的页。
D. 设置 `innodb_stats_auto_recalc=ON` 会在创建新索引时自动更新统计信息	错误。无论 `innodb_stats_auto_recalc` 是否为 `ON`，创建新索引都会强制更新统计信息，因此选项描述的条件关系不成立。
E. 更新索引统计信息是 I/O 密集型操作	正确。更新统计信息时，需扫描大量索引页（由 `innodb_stats_persistent_sample_pages` 控制），尤其在表数据量大时，会导致显著的 I/O 开销。例如：当该参数设为 512 时，索引页扫描量可能增加数十倍。

扩展说明

持久化统计信息的核心机制

存储位置与触发条件
- 持久化统计信息存储在 mysql.innodb_table_stats 和 mysql.innodb_index_stats 表中。
- 触发更新的条件包括：
  - 表中超过 10% 的数据被修改（需 innodb_stats_auto_recalc=ON）；
  - 创建新索引（无论 innodb_stats_auto_recalc 状态）；
  - 手动执行 ANALYZE TABLE。
采样与 I/O 开销
- 采样页数 (innodb_stats_persistent_sample_pages)：
  - 默认值 20，增大该值可提高统计准确性，但会显著增加 I/O 操作和 ANALYZE TABLE 执行时间。
  - 例如，将参数从 20 调整为 512 时，可能导致索引页扫描量增加数十倍，从而成为高 I/O 消耗操作。
性能优化建议
- 平衡采样页数：根据数据量和性能需求调整 innodb_stats_persistent_sample_pages，避免过高值导致 I/O 过载。
- 手动更新统计信息：在数据分布发生重大变化后，手动执行 ANALYZE TABLE 以同步更新统计信息。

总结

正确答案为 E。更新索引统计信息需要扫描大量索引页（尤其是当 innodb_stats_persistent_sample_pages 设置较高时），导致显著的 I/O 开销。其他选项或混淆参数作用对象（A/B），或误判触发条件（D），或忽略数据来源的多样性（C）。

题目 37

Choose the best answer.

Which step or set of steps can be used to rotate the error log?

A. Execute SET GLOBAL log_error = <new error log file>.

B. Execute SET GLOBAL max_error_count = <number of messages at point to rotate>.

C. Execute SET GLOBAL expire_logs_days=0 to enforce a log rotation.

D. Rename the error log file on disk, and then execute FLUSH ERROR LOGS.

正确答案：D. Rename the error log file on disk, and then execute FLUSH ERROR LOGS.

关键解析

错误日志轮换的核心逻辑

MySQL 错误日志的轮换（Rotation）需要完成以下两个核心操作：

关闭当前错误日志文件：确保后续日志写入新的文件。
创建新的错误日志文件：系统开始将新日志记录到新文件中。

选项逐项分析

选项	判定依据与关键结论
A. 通过 `SET GLOBAL log_error = <new_file>` 修改路径	错误：`log_error` 是静态参数，无法通过 `SET GLOBAL` 动态修改，需在配置文件中指定并重启 MySQL 服务。此操作不涉及日志轮换，仅调整路径。
B. 设置 `max_error_count`	错误：`max_error_count` 控制客户端错误消息的最大数量，与日志文件轮换无关。
C. 设置 `expire_logs_days=0`	错误：`expire_logs_days` 用于控制二进制日志（Binary Log）的自动清理时间，与错误日志轮换无关。
D. 重命名文件后执行 `FLUSH ERROR LOGS`	正确。

步骤1：手动重命名错误日志文件（如 mv error.log error.log.old），强制 MySQL 停止写入旧文件。
步骤2：执行 FLUSH ERROR LOGS，触发 MySQL 重新打开同名的新错误日志文件（error.log）。
原理：MySQL 在启动时会根据 log_error 参数创建日志文件，若文件被删除或重命名，FLUSH ERROR LOGS 会重新创建它。

补充说明

自动化轮换工具：

生产环境中通常使用 logrotate 工具（结合 postrotate 脚本调用 FLUSH ERROR LOGS）实现周期性日志轮换。例如：
```
postrotate
    /usr/bin/mysqladmin flush-error-logs
endscript
```

注意事项：

直接删除错误日志文件（而非重命名）可能导致日志丢失，因为 FLUSH ERROR LOGS 仅创建新文件，不会恢复已删除的内容。
确保 MySQL 用户对日志目录有写入权限，否则轮换后可能因权限问题无法生成新文件。

总结

正确答案为 D。通过重命名文件并执行 FLUSH ERROR LOGS，可安全完成错误日志轮换。其他选项或混淆参数作用（A/B/C），或缺乏实际轮换逻辑。

题目 38

Choose the best answer.

You are using an existing server with a new configuration. MySQL Server fails to start.

Examine this snapshot of the error log:

190925 12:49:05 InnoDB: Initializing buffer pool, size = 3.0G
190925 12:49:05 InnoDB: Completed initialization of buffer pool
InnoDB: Error: log file ./ib_logfile0 is of different size 0 5242880 bytes
InnoDB: than specified in the .cnf file 0 26214400 bytes!
190925 12:49:05 [ERROR] Plugin 'InnoDB' init function returned error.
190925 12:49:05 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
190925 12:49:05 [ERROR] Aborting
190925 12:49:05 [Note] /usr/sbin/mysqld: Shutdown complete

Which action would allow the server to start?

A. Execute mysqladmin flush-logs.

B. Create a new ib_logfile0 file of size 26214400.

C. Remove ib_logfile0 and ib_logfile1 files from the file system.

D. First run mysqld --initialize to refresh the size of ib_logfile.

正确答案：C. Remove ib_logfile0 and ib_logfile1 files from the file system.

关键解析

1. 错误原因

错误日志显示 ib_logfile0 的实际大小（5242880 字节，即 5MB）与配置文件（.cnf）中指定的 innodb_log_file_size（26214400 字节，即 25MB）不一致。InnoDB 在启动时会严格校验日志文件的大小与配置是否匹配，若不一致则拒绝启动。

2. 解决方法

删除旧的 ib_logfile 文件（如 ib_logfile0 和 ib_logfile1），然后重启 MySQL 服务。此时 InnoDB 会自动根据配置文件中定义的大小（25MB）生成新的日志文件。

操作步骤：

停止 MySQL 服务：确保服务完全终止。
备份并删除旧的日志文件：

mv ib_logfile0 ib_logfile0.bak
mv ib_logfile1 ib_logfile1.bak

重启 MySQL：系统会根据 innodb_log_file_size 重新生成符合要求的日志文件。

3. 选项排除依据

选项	分析
A. `mysqladmin flush-logs`	错误：`flush-logs` 用于刷新二进制日志（Binlog），而非 InnoDB 的 Redo Log。此操作无法解决日志文件大小不匹配的问题。
B. 手动创建指定大小的 `ib_logfile0`	无效：InnoDB 要求日志文件由自身生成，手动创建可能导致文件格式或校验错误。
C. 删除 `ib_logfile` 文件	正确：强制 InnoDB 重新生成日志文件是官方推荐的解决方案。
D. `mysqld --initialize`	错误：`--initialize` 用于初始化新数据库实例，会覆盖现有数据目录，导致数据丢失。

补充说明

配置修改的正确流程：

若需修改 innodb_log_file_size，必须遵循以下步骤：
1. 停止 MySQL 服务。
2. 备份并删除旧的 ib_logfile*。
3. 修改配置文件中的 innodb_log_file_size。
4. 启动 MySQL，InnoDB 自动生成新日志文件。

数据安全性：

删除 ib_logfile 文件不会影响数据完整性，因为 Redo Log 仅用于崩溃恢复，且事务已提交的数据已持久化到表空间文件（.ibd）。但建议操作前备份数据目录。

总结

正确答案为 C。删除旧的 ib_logfile 文件是唯一能解决日志文件大小不匹配问题的操作，其他选项或无效或可能导致数据丢失。

题目 39

Choose the best answer.

Which characters are most commonly used in a SQL injection attack?

A. ' and "

B. < and >

C. null (\0) and newline (\n)

D. ^ and $

E. + and -

正确答案：A. ' and "

关键解析

在 SQL 注入攻击中，以下字符是最常用的攻击载体：

单引号 '
单引号是最核心的 SQL 注入字符，用于闭合原始 SQL 语句的字符串边界，从而插入恶意代码。例如：
```
SELECT * FROM users WHERE username = 'admin' AND password = 'password'
```
攻击者可注入 ' OR 1=1 --，将查询篡改为：
```
SELECT * FROM users WHERE username = '' OR 1=1 --' AND password = 'password'
```
此时 1=1 恒为真，-- 注释掉后续条件，绕过认证。
双引号 "
双引号用于闭合基于双引号的字符串定义，尤其在动态拼接 SQL 语句时被利用。例如：
```
SELECT * FROM products WHERE name = "user_input"
```
攻击者可注入 " OR 1=1 --，导致查询返回所有记录。

其他选项排除依据

选项	分析
B. `<` 和 `>`	与 HTML/XML 注入相关，而非 SQL 注入。
C. `null (\0)` 和 `newline (\n)`	虽然某些数据库（如 MySQL）需要转义这些字符，但它们主要用于绕过输入过滤，而非直接构造攻击逻辑。
D. `^` 和 `$`	正则表达式元字符，与 SQL 注入无关。
E. `+` 和 `-`	可能在数学运算中用到，但非典型 SQL 注入字符。

补充说明

注释符 -- 和 #：用于终止 SQL 语句的后续部分，使攻击代码独立生效。
分号 ;：用于执行多语句注入（如 '; DROP TABLE users; --）。
特殊函数：如 SLEEP()（用于基于时间的盲注）和 UNION（用于联合查询）。

总结

正确答案为 A。单引号 ' 和双引号 " 是 SQL 注入攻击中最常用的字符，用于破坏原始查询结构并注入恶意逻辑。其他选项的字符或无关（B/D/E），或仅辅助绕过过滤（C），无法直接构造攻击。

题目 40

Choose the best answer.

Examine these commands, which execute successfully on the ic1 host:

mysqlsh> dba.createCluster('cluster1',{memberWeight:35})
mysqlsh> var mycluster = dba.getCluster()
mysqlsh> mycluster.addInstance('ic@ic2',{memberWeight:25})
mysqlsh> mycluster.addInstance('ic@ic3',{memberWeight:50})

Now examine this configuration setting, which is the same on all nodes:

group_replication_consistency=BEFORE_ON_PRIMARY_FAILOVER

Which statement is true if primary node ic1 fails?

A. Node ic2 becomes the new primary and existing transactions are considered stale and rolled back

B. Node ic3 becomes the new primary and existing transactions are considered stale and rolled back.

C. Node ic3 becomes the new primary and is ignored until any backlog of transactions is completed.

D. Only two nodes remain so the election process is uncertain and must be done manually

E. Node ic2 becomes the new primary and is ignored until any backlog of transactions is completed.

正确答案：C. Node ic3 becomes the new primary and is ignored until any backlog of transactions is completed.

关键解析

1. 主节点选举逻辑

在 MySQL Group Replication（MGR）中，主节点的选举基于 memberWeight 参数（权重越高优先级越高）。根据题目配置：

ic1 的权重为 35（初始主节点）
ic2 的权重为 25
ic3 的权重为 50

当 ic1 故障时，剩余节点 ic2 和 ic3 中，ic3 的权重最高（50），因此会被自动选举为新的主节点。

2. 一致性配置的作用

所有节点均设置 group_replication_consistency=BEFORE_ON_PRIMARY_FAILOVER，该配置要求新主节点必须在应用完旧主节点的积压事务（backlog）后，才能响应读写请求。具体行为如下：

新主节点（ic3）会先等待应用所有来自旧主节点（ic1）的未完成事务，确保数据一致性。
在此期间，新主节点暂时处于“不可用”状态（即被忽略），无法处理客户端请求。

3. 排除错误选项的依据

选项	错误原因
A/B	错误描述事务回滚（Rolled Back）。实际情况下，积压事务会被应用而非回滚，且 ic3 成为主节点，而非 ic2。
D	错误认为选举不确定需手动干预。MGR 采用基于权重的自动选举，三个节点中两个存活时仍满足多数派，无需人工操作。
E	错误认为 ic2 成为主节点。权重更高的 ic3 会优先被选举为新的主节点。

4. 补充说明

数据一致性保障：BEFORE_ON_PRIMARY_FAILOVER 通过牺牲短暂可用性来确保新主节点数据的一致性，避免读取过期数据或写入冲突。参考 Configuring Transaction Consistency Guaranteesopen in new window。
故障恢复流程：当 ic1 故障后，MGR 会自动检测并触发重新配置（视图变更），由 ic3 接管服务，但需等待积压事务处理完毕。

总结

正确答案为 C。当主节点 ic1 失效时，权重最高的 ic3 会被选举为新的主节点，并在应用完积压事务前暂时不响应请求，符合 BEFORE_ON_PRIMARY_FAILOVER 的一致性要求。其他选项均不符合 MGR 的选举机制或一致性配置逻辑。

题目 41

Choose the best answer.

You execute this command:

shell> mysqlpump --exclude-databases=% --users

Which statement is true?

A. It creates a logical backup of all MySQL user accounts.

B. It creates a logical backup of all metadata, but contains no table data.

C. It returns an error because the mysqldump command should have been used.

D. It creates a logical backup of only the users database.

正确答案：A. It creates a logical backup of all MySQL user accounts.

关键解析

选项逐项分析

选项	判定依据与关键结论
A. 创建所有 MySQL 用户账户的逻辑备份	正确。`--exclude-databases=%` 排除了所有数据库的备份（`%` 是通配符，匹配所有数据库），而 `--users` 选项会生成用户账户的逻辑定义（即 `CREATE USER` 和 `GRANT` 语句），而非直接备份 `mysql` 系统库中的授权表。
B. 创建所有元数据的逻辑备份，但不包含表数据	错误。命令未涉及数据库或表的元数据备份，仅备份用户账户。
C. 因应使用 mysqldump 而返回错误	错误。`mysqlpump` 是 MySQL 5.7+ 支持的备份工具，与 `mysqldump` 功能类似但更高效，语法正确时不会报错。
D. 仅备份 `users` 数据库	错误。MySQL 中不存在名为 `users` 的数据库，用户账户信息存储在 `mysql` 系统库的授权表中。由于 `--exclude-databases=%` 排除了所有数据库（包括 `mysql`），因此 `--users` 选项的作用是生成用户账户的独立逻辑定义。

补充说明

mysqlpump --users 的核心逻辑：
- 默认情况下，mysqlpump 不会备份 mysql 系统库中的授权表（如 user、db 等）。
- --users 选项会将用户账户信息转换为标准的 SQL 语句（如 CREATE USER 和 GRANT），从而独立于数据库的备份逻辑，直接生成用户定义。
- 若需仅备份用户账户，需通过 --exclude-databases=% 排除所有数据库的备份，否则会默认备份用户账户所在库（如 mysql）的表数据。
与其他选项的对比：
- mysqldump 的 --users 选项会直接导出 mysql.user 表的数据（以 INSERT 语句形式），而 mysqlpump 的 --users 生成的是更安全的逻辑定义。
- 若未排除数据库（如不添加 --exclude-databases=%），mysqlpump 默认会备份所有数据库（包括 mysql 的授权表），导致生成的备份包含用户表的原始数据而非逻辑定义。

总结

正确答案为 A。该命令通过排除所有数据库并启用 --users 选项，生成所有用户账户的逻辑备份（CREATE USER 和 GRANT 语句），而非依赖系统库的物理表数据。其他选项或混淆备份对象（D），或误判工具特性（B/C）。

题目 42

Choose the best answer.

You want to log only the changes made to the database objects and data on the MySQL system.

Which log will do this by default?

A. general query log

B. audit log

C. slow query log

D. binary log

E. error log

正确答案：D. binary log（二进制日志）

关键解析

1. 二进制日志的核心作用

二进制日志（Binary Log）是 MySQL 中唯一默认记录所有数据库对象（如表结构变更）和数据变更（如 INSERT、UPDATE、DELETE 等 DML 操作）的日志类型。其核心功能包括：

记录数据变更：以二进制格式保存所有修改数据库的操作，包括 DDL（如 CREATE TABLE）和 DML 语句。
默认启用：虽然需要配置 log_bin 参数（例如在 my.cnf 中设置），但 MySQL 默认会生成二进制日志文件（如 mysql-bin.000001）。
关键应用场景：支持主从复制、数据恢复和增量备份。

2. 其他选项排除依据

选项	分析
A. general query log（通用查询日志）	错误：记录所有客户端执行的 SQL 语句（包括 SELECT 等非变更操作），但默认不启用，且记录范围过广，不专门针对数据变更。
B. audit log（审计日志）	错误：记录用户操作（如登录、权限变更），属于 MySQL 企业版功能，社区版需额外插件支持且默认关闭。
C. slow query log（慢查询日志）	错误：仅记录执行时间超过阈值的查询（如 `long_query_time=2` 秒），与数据变更无关。
E. error log（错误日志）	错误：记录服务器启动、运行中的错误和警告（如权限问题或硬件故障），不涉及数据变更。

3. 二进制日志的默认行为验证

默认文件生成：若未显式关闭，二进制日志文件会在数据目录下生成（如 mysql-bin.000001）。
配置验证：通过 SHOW VARIABLES LIKE '%log_bin%' 可检查是否启用，Value=ON 表示已开启。
事务一致性：二进制日志在事务提交后生成，确保数据变更的原子性和持久性。

总结

正确答案为 D。二进制日志是 MySQL 默认记录数据库对象和数据变更的唯一日志类型，其他选项或记录非变更操作（A/C/E），或依赖企业版功能（B）。其核心作用在于支持主从复制和数据恢复，是数据库运维中不可或缺的组件。

题目 43

Choose the best answer.

Examine this partial output for InnoDB Cluster status:

"topology": {
    "host1:3377": {
        "address": "host1:3377",
        "mode": "R/W",
        [...]
        "status": "ONLINE",
        "version": "8.0.18"
    },
    "host2:3377": {
        "address": "host2:3377",
        "mode": "R/O",
        [...]
        "status": "(MISSING)"
    },
    "host3:3377": {
        "address": "host3:3377",
        "mode": "R/O",
        [...]
        "status": "ONLINE",
        "version": "8.0.18"
    }
}

Which statement explains the state of the instance deployed on host2?

A. It can rejoin the cluster by using the command cluster.addInstance ('<user>@host3:3377').

B. It has been expelled from the cluster because of a transaction error.

C. It can be recovered from a donor instance on host3 by cloning using the command cluster.rejoinInstance ('<user>@host3:3377').

D. It has been removed from the cluster by using the command STOP GROUP_REPLICATION;.

E. It can rejoin the cluster by using the command dba. rebootClusterFromCompleteOutage().

正确答案：C. It can be recovered from a donor instance on host3 by cloning using the command cluster.rejoinInstance('<user>@host3:3377').

关键解析

1. 状态分析

从 cluster.status() 的输出中可以看到：

host2:3377 的状态为 (MISSING)，这表明该节点已被集群自动驱逐（Expelled）。
驱逐原因通常是节点长时间处于 UNREACHABLE 状态（如网络中断、实例崩溃或高负载导致超时）。此时，集群剩余成员（host1 和 host3）通过多数投票机制移除了 host2 的成员资格。

2. 恢复方法

根据 MySQL InnoDB Cluster 的恢复逻辑：

重新加入集群需使用 cluster.rejoinInstance('host2:3377') 命令，而非直接 addInstance（选项 A 错误）。
如果节点因元数据不一致无法自动恢复，需手动清除其组复制信息（如执行 STOP GROUP_REPLICATION; RESET SLAVE ALL;）后再尝试重新加入（选项 D 的 STOP GROUP_REPLICATION 仅停止复制，不会直接导致 MISSING 状态）。
克隆恢复（选项 C）适用于节点数据完全丢失或需要重建的场景。通过从 Donor 节点（如 host3）克隆数据并重新同步，确保数据一致性。

3. 选项排除依据

选项	错误原因
A. `addInstance`	若节点仍残留组复制元数据，直接添加会报错（如提示“已属于其他组”）。需先清除旧数据再添加。
B. 事务错误驱逐	`(MISSING)` 状态通常由节点不可达触发，而非事务错误。事务冲突一般会导致集群状态为 `NO_QUORUM` 或部分节点 `ERROR`。
D. `STOP GROUP_REPLICATION`	此命令会主动脱离集群，节点状态应为 `OFFLINE` 或 `ERROR`，而非 `(MISSING)`。
E. `rebootClusterFromCompleteOutage`	该命令用于集群完全崩溃且无在线节点时的恢复，不适用于单个节点缺失的情况。

4. 操作验证

若 host2 实例仍在线但无法自动恢复，需按以下步骤操作：

清除残留组复制信息（host2 执行）：

STOP GROUP_REPLICATION;
RESET SLAVE ALL;
RESET MASTER;

从 Donor 节点克隆并重新加入（host1 或 host3 执行）：
```
cluster.rejoinInstance('host2:3377', { donor: 'host3:3377' });
```
此命令会触发分布式恢复（克隆或增量同步），确保 host2 数据与集群一致。

总结

正确答案为 C。(MISSING) 状态表明 host2 已被集群驱逐，需通过 rejoinInstance 命令从 Donor 节点（如 host3）恢复数据并重新加入集群。其他选项或操作不匹配状态触发机制，或忽略元数据清理的必要性。

题目 44

Choose the best answer.

You use Row Based Replication and need to see "pseudo-SQL" statements for the replication event that is located in the log_file position NNNNN file. Which command should you use?

A. mysqlshow --debug --stop-position=NNNNN log_file

B. mysqlbinlog --verbose --start-position=NNNN log_file

C. mysqlbinlog --debug --start-position=NNNNN log_file

D. mysqlbinlog --debug -- stop-position=NNNNN log_file

E. mysqlshow --verbose --stop-position=NNNNN log_file

F. mysqlbinlog --verbose --stop-position=NNNNN log_file

G. mysqlshow --debug --start-position=NNNNN log_file

H. mysqlshow --verbose --start-position=NNNNN log_file

正确答案：B. mysqlbinlog --verbose --start-position=NNNN log_file

关键解析

1. 工具选择与核心参数

mysqlbinlog 是 MySQL 提供的专用工具，用于解析二进制日志（Binlog）文件。题目中要求查看 Binlog 中的事件，因此排除使用 mysqlshow 的选项（A/E/G/H）。
Row Based Replication（行复制模式）下，Binlog 默认以二进制格式记录数据变更，需通过 --verbose（或 -v）参数生成可读的伪 SQL 语句。例如：
```
mysqlbinlog --verbose mysql-bin.000001
```
此参数会将行事件转换为类似 ### UPDATE test.t SET id=1 WHERE id=2 的伪 SQL。

2. 位置过滤逻辑

--start-position=NNNN 用于指定从哪个事件位置开始解析。题目要求查看位于位置 NNNNN 的特定事件，因此需通过此参数定位起始点。
--stop-position 用于设置结束位置，但题目未要求截取范围，且选项 F（--stop-position=NNNNN）会直接截断到该位置，可能遗漏目标事件。因此，仅需 --start-position 即可。

3. 错误选项排除

选项	错误原因
C/D（`--debug`）	`--debug` 参数用于调试工具内部行为，与生成伪 SQL 无关。
F（`--stop-position`）	单独使用 `--stop-position` 会仅解析到该位置，可能无法覆盖目标事件。
其他 `mysqlshow` 选项	`mysqlshow` 用于查看数据库对象（如表结构），无法解析 Binlog。

4. 操作验证

假设需要查看 mysql-bin.000002 中位置 107 的事件：

mysqlbinlog --verbose --start-position=107 mysql-bin.000002

输出示例：

# at 107
#220302 14:30:30 server id 1033306 end_log_pos 150 CRC32 0x56411c87
### UPDATE `test`.`t`
### WHERE
###   @1=1
### SET
###   @1=2

此输出直接展示了行事件对应的伪 SQL 逻辑。

总结

正确答案为 B。mysqlbinlog --verbose --start-position=NNNN 能够精准定位到指定位置的事件并生成可读的伪 SQL 语句，符合 Row Based Replication 的调试需求。其他选项或工具选择错误，或参数逻辑不匹配。

题目 45

Choose the best answer.

Examine the command, which executes successfully:

shell> mysqld --initialize

Which statement is true?

A. The root password is created in the error log in plain text.

B. The installation creates a temporary test environment with data in the /tmp directory.

C. The installation is created without enforcing or generating SSL certificates.

D. The root password is not created allowing easy access from the same host.

正确答案：A. The root password is created in the error log in plain text.

关键解析

1. mysqld --initialize 的核心行为

随机密码生成：mysqld --initialize 的主要功能是初始化 MySQL 数据目录，并自动生成一个随机的临时 root 密码。此密码的生成是默认的安全机制，用于首次登录后强制用户修改密码。
密码存储位置：生成的临时密码会以明文形式记录在错误日志（error log）中，默认路径通常为 /var/log/mysqld.log（Linux）或 MySQL 数据目录下的 .err 文件（Windows）。

2. 选项逐项分析

选项	判定依据与关键结论
A. Root 密码明文存于错误日志	正确。所有相关文档均明确说明，`--initialize` 生成的临时密码会写入错误日志，且为明文形式。
B. 在 `/tmp` 创建临时测试环境	错误。初始化操作的数据目录由 `--datadir` 参数指定（默认为 `/var/lib/mysql`），与 `/tmp` 无关。`/tmp` 仅用于临时文件权限检查，并非存储测试数据。
C. 不生成或强制 SSL 证书	错误。SSL 证书的生成与 `--initialize` 无关，需单独配置（如使用 `--ssl-*` 参数或手动生成证书）。默认初始化不会涉及 SSL 证书的生成或强制要求。
D. Root 密码未创建，允许本地免密访问	错误。此描述属于 `--initialize-insecure` 的行为，而非 `--initialize`。后者会生成密码且必须通过密码登录。

3. 操作验证

初始化命令：

mysqld --initialize --user=mysql

查看错误日志：

cat /var/log/mysqld.log | grep "temporary password"

输出示例：

[Note] A temporary password is generated for root@localhost: 6pZ+!qzK71Hw

此明文密码即为首次登录凭证。

4. 与其他选项的对比

--initialize-insecure：若使用此参数，则不会生成密码（D 选项的部分描述），允许 mysql -u root --skip-password 直接登录。
SSL 配置：需通过额外步骤生成证书并修改配置文件（如 ssl-ca、ssl-cert 参数），与 --initialize 无直接关联。

总结

正确答案为 A。mysqld --initialize 的核心行为是生成随机 root 密码并明文记录于错误日志中，其他选项或混淆初始化参数（B/D），或涉及不相关的 SSL 配置（C）。此机制确保了数据库初始化的安全性，同时要求管理员及时修改默认密码。

题目 46

Choose the best answer.

Your MySQL environment has asynchronous position based-replication with one master and one slave. The slave instance had a disk I/O problem, so it was stopped. You determined that the slave relay log files were corrupted and unusable, but no other files are damaged. You restart MySQL Server. How can replication be restored?

A. The slave relay logs should be deleted; then execute START SLAVE;

B. The slave needs to be restored from backup.

C. The slave relay logs should be deleted; execute CHANGE MASTER to adjust the replication relay log file name, then issue START SLAVE;

D. The relay logs from the master should be used to replace the corrupted relay logs.

正确答案：C. The slave relay logs should be deleted; execute CHANGE MASTER to adjust the replication relay log file name, then issue START SLAVE;

关键解析

1. 问题场景与核心逻辑

从库因磁盘 I/O 问题导致中继日志（Relay Log）损坏，但其他文件（如主库的二进制日志、从库的 relay_log_info 元数据）未损坏。此时需在不依赖备份的情况下恢复复制。

2. 恢复步骤与选项验证

正确操作流程如下：

删除损坏的中继日志：通过 STOP SLAVE 停止复制，手动删除 relay_log_file 和 relay_log_index 文件（或使用 RESET SLAVE 清除日志）。此举是为了移除不可用的损坏数据。
重新配置复制起点：使用 CHANGE MASTER TO 命令，根据 SHOW SLAVE STATUS 记录的 Relay_Master_Log_File 和 Exec_Master_Log_Pos（即 SQL 线程最后成功执行的主库日志位置），重新指定从主库的哪个二进制日志文件和位置开始复制。例如：
```
CHANGE MASTER TO 
  MASTER_LOG_FILE='mysql-bin.000287', 
  MASTER_LOG_POS=972239835;  
```
重启复制：执行 START SLAVE，从库的 I/O 线程会重新从主库的指定位置拉取二进制日志，生成新的中继日志，SQL 线程继续应用变更。

3. 选项排除依据

选项	错误原因
A. 仅删除中继日志后启动	未重新指定复制起点，从库可能尝试继续读取已删除的日志文件，导致报错。
B. 从备份恢复	从库其他文件未损坏（如主库的二进制日志完整），无需全量恢复备份，效率低下。
D. 替换为主库的中继日志	主库没有中继日志（只有二进制日志），此操作逻辑错误。

4. 补充说明

relay_log_recovery 参数：若从库配置了 relay_log_recovery=ON，重启 MySQL 时会自动丢弃损坏的中继日志，并从 Exec_Master_Log_Pos 重新请求主库日志。但题目未明确此参数是否启用，因此需手动干预。
GTID 模式下的差异：若开启 GTID，可直接使用 MASTER_AUTO_POSITION=1，无需手动指定日志位置，但题目明确为基于位置的异步复制，因此需手动调整。

总结

正确答案为 C。通过删除损坏的中继日志并重新配置复制起点，从库可安全恢复与主库的同步，避免数据丢失或逻辑错误。此方法既符合 MySQL 官方推荐流程，也适用于大多数异步复制故障场景。

题目 47

Examine this configuration: You have a corporate private network, which uses its own Certificate Authority (CA) using an industry standard 2048-bit RSA key length. All MySQL Server and client certificates are signed using the central corporate CA. All clients are known, controlled, and exist only on the private LAN. The private network uses its own private authoritative DNS. The private network also uses other nominal enterprise services. An end-to-end encrypted connection for a MySQL client to MySQL server has been established on this LAN. How does the MySQL Servers' self signed certificate compare to one that would be signed by a known public, third party trusted Certificate Authority?

A. The self-signed certificate is equally secure and equally trusted.

B. The self-signed certificate is more secure and less trusted.

C. The self-signed certificate is less secure and equally trusted.

D. The self-signed certificate is equally secure and less trusted.

E. The self -signed certificate is more secure and equally trusted.

F. The self-signed certificate is less secure and less trusted.

正确答案：D. The self-signed certificate is equally secure and less trusted.

关键解析

1. 安全性对比：自签名证书与CA证书无本质差异

在加密技术层面，自签名证书和由第三方 CA 签名的证书安全性相同，因为两者均采用相同的加密算法（如 RSA-2048）和密钥长度。具体表现为：

加密强度一致：无论证书是自签名还是 CA 签发，TLS 连接的加密过程依赖于证书的公钥和私钥对，其安全性由密钥长度（如 2048 位）和加密算法（如 SHA-256）决定，与证书颁发方式无关。
数据保护能力相同：两者均能防止数据在传输过程中被窃听或篡改。

2. 信任度差异：自签名证书需额外配置信任

信任度取决于客户端是否预先信任证书颁发机构：

自签名证书：未经过任何受信任的第三方 CA 验证，客户端（如 MySQL 客户端）默认不会信任。在私有网络中，需手动将自签名证书或企业 CA 根证书添加到客户端的信任库中。
第三方 CA 证书：由公共 CA（如 DigiCert、Let’s Encrypt）签发的证书，其根证书已预装在操作系统或客户端中，无需额外配置即可自动信任。

3. 题目场景的特殊性

题目中的企业环境具有以下特点：

私有 CA 与受控客户端：所有客户端已信任企业自建的 CA，因此由该 CA 签发的服务器证书会被自动信任。但题目明确比较的是自签名证书（即未通过企业 CA 签发的证书）与公共 CA 签名的证书，此时自签名证书仍需客户端手动信任。
私有网络与 DNS：尽管网络环境封闭，但自签名证书仍需通过配置实现信任，而公共 CA 证书因预置信任链可省去此步骤。

4. 错误选项排除

选项	错误原因
A. 安全性与信任度均相同	自签名证书的信任度低于公共CA证书，需手动配置信任。
B. 更安全但更不信任	安全性无差异，信任度更低。
C. 安全性低但信任度相同	安全性相同，信任度更低。
E. 更安全且信任度相同	安全性和信任度均不成立。
F. 安全性与信任度均更低	安全性无差异，信任度更低。

总结

在给定场景中，自签名证书与公共 CA 证书的加密安全性相同（均基于 RSA-2048 和 TLS 协议），但自签名证书需要额外配置信任（如手动导入客户端），导致其信任度低于公共 CA 证书。因此，正确答案为 D。

题目 48

Choose the best answer.

Examine these statements and output:

mysql> GRANT PROXY ON accounting@localhost TO ' '@'%' ;
mysql> SELECT USER(), CURRENT_USER(), @@proxy_user;
+-----------------+----------------------+----------------+
| USER()          | CURRENT_USER()       | @@proxy_user   |
+-----------------+----------------------+----------------+
| rsmith@localhost| accounting@localhost | ''@'%'         |
+-----------------+----------------------+----------------+

Which statement is true? (Choose one)

A. The user failed to define a username and the connecting username defaulted to ' '@'%'.

B. The user is authorized as the rsmith@localhost user.

C. The user is authenticated as the anonymous proxy user ' '@'%'.

D. The user is logged in with --user=accounting as an option.

E. The user is authorized as the accounting@localhost user.

正确答案：C. The user is authenticated as the anonymous proxy user ' '@'%'.

关键解析

代理用户机制与权限验证

根据 GRANT PROXY 语句，代理用户 ' '@'%'（空用户名，匹配任意用户）被授权代理 accounting@localhost 的权限。这意味着任何通过 ' '@'%' 认证的用户将继承 accounting@localhost 的权限。
当用户通过 rsmith@localhost 连接时，MySQL 的代理机制会根据配置将连接用户映射到被代理的 accounting@localhost 账户，同时 @@proxy_user 显示代理用户的身份（' '@'%'）。

函数值的差异解释

USER()：返回客户端连接时使用的用户名和主机（rsmith@localhost）。
CURRENT_USER()：返回当前实际生效权限的账户（accounting@localhost），即被代理用户的身份。
@@proxy_user：显示当前会话的代理用户（' '@'%'），即认证时使用的代理账户。

选项排除依据

A：错误。USER() 明确显示用户名为 rsmith，而非默认的空用户。
B：错误。rsmith@localhost 是连接账户，但实际权限属于被代理的 accounting@localhost。
D：错误。--user=accounting 未被使用，否则 USER() 应显示 accounting@localhost。
E：错误。用户未被直接授权为 accounting@localhost，而是通过代理机制获得其权限。

总结

代理用户 ' '@'%' 通过 GRANT PROXY 获得了 accounting@localhost 的权限。当用户以 rsmith@localhost 连接时，虽然 USER() 显示连接账户为 rsmith，但实际认证通过代理用户 ' '@'%' 完成，并继承 accounting@localhost 的权限（CURRENT_USER() 的值）。因此，正确选项为 C。

题目 49

Choose the best answer.

You wish to store the username and password for a client connection to MySQL server in a file on a local file system. Which is the best way to encrypt the file?

A. Use mysql_secure_installation to encrypt stored login credentials.

B. Use a text editor to create a new defaults file and encrypt it from Linux prompt.

C. Use mysql_config_editor to create an encrypted file.

D. Use the AES_ENCRYPT() MySQL function on the option file.

正确答案：C. Use mysql_config_editor to create an encrypted file.

关键解析

1. 选项分析

A. mysql_secure_installation
- 此工具用于初始化 MySQL 安全配置（如删除匿名用户、设置 root 密码等），但不涉及加密存储登录凭据文件。它主要解决的是基础安全设置问题，而非配置文件加密。
B. 手动加密文本文件
- 虽然可以通过外部工具（如 OpenSSL）手动加密配置文件（例如 .my.cnf），但需要自行管理密钥和加密流程，存在以下风险：
  - 密钥泄露可能导致文件被解密。
  - 加密后的文件需配合解密脚本使用，增加操作复杂度。
  - 明文密码可能在操作过程中意外暴露（如脚本日志）。
C. mysql_config_editor
- 这是 MySQL 官方提供的专用工具，用于生成加密的登录路径文件（默认路径为 ~/.mylogin.cnf）。其特点包括：
  - 自动加密：文件内容经过模糊处理，无法通过 cat 等命令直接读取明文密码。
  - 安全集成：MySQL 客户端（如 mysql、mysqldump）可直接读取该文件，无需暴露密码在命令行或脚本中。
  - 便捷管理：支持通过 set、remove 等命令管理多个登录路径，并自动屏蔽密码显示。
D. AES_ENCRYPT() 函数
- AES_ENCRYPT() 是 MySQL 内置函数，用于加密数据库内的字段数据，而非外部配置文件。客户端无法直接解密此函数加密的选项文件，因此此方法不适用。

2. 最佳实践验证

根据官方推荐方案，mysql_config_editor 是唯一能同时满足以下条件的方法：

自动化加密：无需手动处理密钥和加密算法。
无缝集成：MySQL 客户端原生支持 .mylogin.cnf 文件的读取。
安全合规：避免密码以任何形式暴露在命令行、日志或配置文件中。

3. 操作示例

使用 mysql_config_editor 的典型流程如下：

# 创建加密登录路径（例如名为 "secure_login"）
mysql_config_editor set --login-path=secure_login \
  --host=localhost --user=root --password

# 输入密码后，自动生成加密文件 ~/.mylogin.cnf

# 使用加密路径连接 MySQL
mysql --login-path=secure_login

总结

正确答案为 C。mysql_config_editor 是 MySQL 官方提供的唯一安全且便捷的凭据加密存储方案，其他选项或因功能不符（A/D）或因操作风险（B）被排除。

题目 50

Choose the best answer.

Which condition is true about the use of the hash join algorithm?

A. At least one of the tables in the join must have a hash index.

B. No index can be used for the join.

C. The query must access no more than two tables.

D. The smallest of the tables in the join must fit in memory as set by join_buffer_size.

正确答案：B. No index can be used for the join.

关键解析

1. 哈希连接算法的核心条件

哈希连接（Hash Join）的触发条件与索引的使用密切相关。根据搜索结果中的多个文档描述，当优化器判定连接字段上的索引无法有效提升性能，或者不存在可用索引时，才会选择哈希连接。例如：

MySQL 8.0.18 引入哈希连接时明确指出，该算法主要用于替代传统的块嵌套循环连接（BNL），尤其是在没有索引的等值连接场景下。
若存在高筛选性的索引（如主键或唯一索引），优化器可能优先选择嵌套循环连接（Nested Loop Join）或索引扫描，而非哈希连接。

2. 选项排除依据

选项	错误原因
A. 至少一个表需有哈希索引	哈希连接不依赖哈希索引，而是基于连接条件的哈希值计算。哈希索引（如 InnoDB 的自适应哈希索引）是数据库内部机制，与哈希连接无直接关联。
C. 最多涉及两个表	哈希连接支持多表等值连接。例如，MySQL 的查询计划中可对多个表的等值连接依次应用哈希连接。
D. 最小表需完全放入内存	哈希连接的构建表（较小表）不要求完全放入内存。若超出 `join_buffer_size`，MySQL会采用分片（Chunk）处理，将数据分批加载到内存或落盘（如 Grace Hash Join）。

3. 补充说明

哈希连接的适用场景：

大表间的等值连接，且无高效索引可用。
数据分布均匀，避免因哈希冲突导致性能下降。

优化器决策逻辑：

即使显式指定 HASH_JOIN 提示（Hint），若存在合适的索引，优化器仍可能忽略该提示。

总结

正确答案为 B。哈希连接的核心条件在于无法通过索引优化连接性能，其设计初衷正是为了解决无索引场景下的等值连接效率问题。其他选项均与哈希连接的实际工作机制不符。

题目 51

Your MySQL server was upgraded from an earlier major version.

The sales database contains three tables, one of which is the transactions table, which has 4 million rows.

You are running low on disk space on the datadir partition and begin to investigate.

Examine these commands and output:

mysql> show global variables like 'innodb_file%';
+-----------------------+-------+
| Variable_name         | Value |
+-----------------------+-------+
| innodb_file_per_table | ON    |
+-----------------------+-------+
1 row in set (0.00 sec)

# ls -l | grep ib
-rw-r----- 1 mysql mysql 3287 			Dec 12 07:54 ib_buffer_pool
-rw-r----- 1 mysql mysql 125827192912 	Dec 12 09:50 ibdata1
-rw-r----- 1 mysql mysql 50331648 		Dec 12 09:50 ib_logfile0
-rw-r----- 1 mysql mysql 50331648 		Dec 11 14:05 ib_logfile1
-rw-r----- 1 mysql mysql 12582912 		Dec 12 08:05 ibtmp1
-rw-r----- 1 mysql mysql 25165824 		Dec 12 09:50 mysql.ibd

# ls -l sales/
total 544
-rw-r----- 1 mysql mysql 47550136 	Dec 12 09:50 sales.ibd
-rw-r----- 1 mysql mysql 114688 	Dec 11 14:33 leads.ibd

Which two statements are true?

A. The transactions table was created with innodb_file_per_table=OFF.

B. Truncating the sales and leads table will free up disk space.

C. Executing SET GLOBAL innodb_row_format=COMPRESSED and then ALTER TABLE transactions will free up disk space.

D. Executing ALTER TABLE transactions will enable you to free up disk space.

E. Truncating the transactions table will free up the most disk space.

正确答案：A. The transactions table was created with innodb_file_per_table=OFF. 和 B. Truncating the sales and leads table will free up disk space.

关键解析

1. 问题背景与核心矛盾

核心矛盾：数据目录分区磁盘空间不足，需分析 ibdata1 文件异常膨胀的原因并释放空间。
关键线索：
- innodb_file_per_table=ON 已启用，但 transactions 表未显示独立的 .ibd 文件（sales.ibd 和 leads.ibd 存在）。
- ibdata1 文件大小高达 125 GB，而其他表空间文件较小。

2. 选项分析与验证

选项	分析
A. transactions 表创建时 `innodb_file_per_table=OFF`	正确。当 `innodb_file_per_table=OFF` 时，所有表数据存储在共享的 `ibdata1` 文件中。由于 `transactions` 表未生成独立的 `.ibd` 文件（仅 `sales.ibd` 和 `leads.ibd` 存在），说明该表创建时可能处于共享表空间模式。
B. TRUNCATE `sales` 和 `leads` 表可释放空间	正确。在 `innodb_file_per_table=ON` 下，TRUNCATE 或 DROP 表会直接删除对应的 `.ibd` 文件并释放磁盘空间。`sales.ibd` 和 `leads.ibd` 文件存在，说明它们符合此条件。
C. 设置 `innodb_row_format=COMPRESSED` 后 ALTER 表可释放空间	错误。启用压缩行格式（`ROW_FORMAT=COMPRESSED`）需要通过 `ALTER TABLE` 显式指定，且仅对新插入或更新的数据生效。如果 `transactions` 表存储在共享表空间（`ibdata1`），即使启用压缩，也不会释放磁盘空间。此外，`ALTER TABLE` 本身不会直接释放空间，除非结合 `OPTIMIZE TABLE` 或重建表。
D. 执行 ALTER TABLE `transactions` 可释放空间	错误。如果 `transactions` 表存储在共享表空间（`ibdata1`），ALTER TABLE 会重建表，但共享表空间的大小不会缩小，磁盘空间仍由 `ibdata1` 占用。若 `transactions` 表通过 `ALTER TABLE ... ENGINE=InnoDB` 被转换为独立表空间（`transactions.ibd`），则后续 `TRUNCATE` 可释放空间，但 `ALTER TABLE` 本身不会直接释放空间。
E. TRUNCATE `transactions` 表可释放最多空间	错误。若 `transactions` 表数据存储在 `ibdata1` 中，TRUNCATE 仅标记数据删除，不会释放 `ibdata1` 的物理空间，需通过重建表或导出/导入数据实现回收。

3. 操作建议

确认 transactions 表存储位置：

SELECT TABLE_NAME, TABLESPACE_NAME 
FROM INFORMATION_SCHEMA.INNODB_TABLES 
WHERE TABLE_NAME LIKE 'transactions';

若 TABLESPACE_NAME 为 innodb_system，则确认其位于 ibdata1 中。

释放 sales 和 leads 表的空间：

TRUNCATE TABLE sales;  -- 直接释放 sales.ibd 空间
TRUNCATE TABLE leads;  -- 直接释放 leads.ibd 空间

总结

正确答案为 A 和 B：

A 解释了 transactions 表未生成 .ibd 文件的原因（创建时共享表空间模式）。
B 释放 sales 和 leads 表的空间。

补充

要释放 ibdata1 文件占用的磁盘空间，通常需要通过重建数据库并启用 innodb_file_per_table 的方式实现。以下是具体的操作步骤和注意事项：

操作步骤

1. 备份数据库

全量备份：确保所有数据安全，使用 mysqldump 导出所有数据库。
```
mysqldump -u<username> -p --all-databases --single-transaction --quick --lock-tables=false > /path/to/backup.sql
```
- --single-transaction：确保一致性备份（适用于 InnoDB）。
- --quick：避免在内存中缓存大表数据。
- --lock-tables=false：减少锁对业务的影响。

2. 修改 MySQL 配置

启用 innodb_file_per_table：确保每个表使用独立的 .ibd 文件。
```
[mysqld]
innodb_file_per_table = 1
```
- 如果未启用此参数，ibdata1 会持续增长，无法通过常规操作释放空间。

3. 停止 MySQL 服务

停止服务以确保数据一致性：

systemctl stop mysql  # 或 service mysql stop（取决于系统）

4. 清理旧数据文件

删除 ibdata1 和日志文件：
```
rm -f /var/lib/mysql/ibdata1
rm -f /var/lib/mysql/ib_logfile*
```
- 注意：此操作会清空共享表空间，但后续还原数据时会自动重建。

5. 启动 MySQL 服务

重启服务以生成新的 ibdata1 文件：
```
systemctl start mysql  # 或 service mysql start
```
- 新的 ibdata1 文件会非常小（约 10 MB），仅包含系统元数据。

6. 还原备份数据

导入备份数据：
```
mysql -u<username> -p < /path/to/backup.sql
```
- 数据将被写入独立的 .ibd 文件（每个表一个文件），而共享表空间仅保留系统数据。

关键注意事项

停机时间：

此操作需要停止 MySQL 服务，需在业务低峰期执行。

数据安全：

务必验证备份的完整性，确保所有数据库和表（包括存储过程、触发器）都被正确导出。
操作前建议先在一个测试环境中演练。

权限与路径：

确保 MySQL 数据目录（datadir）的所有权和权限正确（通常为 mysql:mysql）。

后续优化：

删除无用表：清理不再使用的表以减少数据量。
优化表：对大表执行 OPTIMIZE TABLE 以减少碎片化。
```
OPTIMIZE TABLE transactions;
```

为什么此方法有效？

共享表空间 vs 独立表空间：
- 默认情况下，InnoDB 使用共享表空间（ibdata1），所有表的数据和索引存储在一起，删除数据后空间无法回收。
- 启用 innodb_file_per_table 后，每个表的数据和索引存储在独立的 .ibd 文件中，删除表或优化表时空间会被释放。
重建数据库：
- 删除旧的 ibdata1 文件并重新导入数据后，新数据会分配到独立表空间文件，共享表空间仅保留系统元数据，从而释放大量磁盘空间。

替代方案（无需重建数据库）

如果无法停机，可以尝试以下方法（但效果有限）：

重建表：
- 对大表执行 ALTER TABLE ... ENGINE=InnoDB，将其迁移到独立表空间。
```
ALTER TABLE transactions ENGINE=InnoDB;
```
- 注意：此操作会锁表，需在低峰期执行。
截断表：
- 删除表数据并释放空间（仅适用于独立表空间）。
```
TRUNCATE TABLE transactions;
```
优化表：
- 重建表并释放碎片空间。
```
OPTIMIZE TABLE transactions;
```

总结

方法	是否释放 `ibdata1` 空间	是否需要停机	适用场景
重建数据库 + `innodb_file_per_table`	✅	✅	严重磁盘空间不足，需彻底释放
`ALTER TABLE ... ENGINE=InnoDB`	❌（仅释放独立表空间）	❌	临时缓解问题
`TRUNCATE` / `OPTIMIZE TABLE`	❌（仅针对独立表空间）	❌	删除数据后的碎片整理

推荐方案：优先选择重建数据库 + 启用 innodb_file_per_table，这是最彻底的解决方案。

题目 52

Examine this query and output:

mysql> EXPLAIN ANALYZE
SELECT 
    city.CountryCode, country.Name AS Country_Name,
    city.Name, city.District, city.Population
FROM world.city
INNER JOIN world.country ON country.Code = city.CountryCode
WHERE country.Continent = 'Asia'
AND city.Population > 1000000
ORDER BY city.Population DESC\G;

*************************** 1. row ***************************
EXPLAIN:
-> Sort: <temporary>.Population DESC (actual time=8.306..8.431 rows=125 loops=1)
   -> Stream results (actual time=0.145..8.033 rows=125 loops=1)
      -> Nested loop inner join (cost=241.12 rows=205) (actual time=0.141..7.787 rows=125 loops=1)
         -> Filter: (world.country.Continent = 'Asia') (cost=25.40 rows=34) (actual time=0.064..0.820 rows=51 loops=1)
            -> Table scan on country (cost=25.40 rows=239) (actual time=0.059..0.359 rows=239 loops=1)
         -> Filter: (world.city.Population > 1000000) (cost=4.53 rows=6) (actual time=0.030..0.131 rows=2 loops=51)
            -> Index lookup on city using CountryCode (CountryCode=world.country.`Code`) (cost=4.53 rows=18) (actual time=0.023..0.096 rows=35 loops=51)

1 row in set (0.0094 sec)

Which two statements are true?

A. The country table is accessed as the first table, and then joined to the city table.

B. 35 rows from the city table are included in the result.

C. The optimizer estimates that 51 rows in the country table have Continent = ' Asia '.

D. It takes more than 8 milliseconds to sort the rows.

E. The query returns exactly 125 rows

正确答案：

**A. The country table is accessed as the first table, and then joined to the city table. **

E. The query returns exactly 125 rows.

关键解析

1. 执行计划分析

根据 EXPLAIN ANALYZE 的输出，查询的执行流程如下：

嵌套循环连接（Nested Loop Join）：

外层表（驱动表）：首先扫描 country 表，过滤条件 Continent = 'Asia'，优化器预估匹配 34 行（rows=34），实际返回 51 行（actual rows=51）。
内层表：通过索引 CountryCode 访问 city 表，每次循环平均返回 35 行，但经过 Population > 1000000 过滤后，最终实际总行数为 125 行（rows=125）。

排序阶段：

排序操作（Sort: <temporary>.Population DESC）的实际耗时是 actual time=8.306..8.431 秒，即排序过程耗时大约 0.125 秒（或 125 毫秒），明显超过了 8 毫秒。

2. 选项验证

选项	分析
A. country 表作为第一个表被访问	正确。嵌套循环连接中，`country` 表是驱动表，先被扫描和过滤，再连接 `city` 表。
B. 结果包含 35 行来自 city 表	错误。`city` 表每次循环返回 35 行，但经过 `Population` 过滤后，最终仅保留 125 行（平均每循环 2 行）。
C. 优化器预估 country 表匹配 51 行	错误。优化器预估 `country` 表匹配 34 行（`rows=34`），实际返回 51 行。
D. 排序耗时超过 8 毫秒	错误。排序步骤的实际时间是 `actual time=8.306..8.431` 秒，即排序过程耗时大约 0.125 秒（或 125 毫秒），明显超过了 8 毫秒。
E. 查询返回 125 行	正确。`Stream results` 显示实际返回 125 行（`rows=125`）。

3. 总结

A 和 E 正确： country 表是驱动表，且最终返回 125 行符合实际执行结果。

补充说明

索引优化建议：若 country.Continent 字段频繁查询，可添加索引加速过滤；city.Population 可考虑联合索引 (CountryCode, Population) 以优化连接和过滤。
性能瓶颈：city 表过滤条件导致实际数据量减少，但嵌套循环中多次索引查找可能成为性能瓶颈，可考虑调整 join_buffer_size 或使用哈希连接（MySQL 8.0+）。

题目 53

A newly deployed replication master database has a 10/90 read to write ratio. The complete dataset is currently 28G but will never fluctuate beyond +-10%. The database storage system consists of two locally attached PCI- E Enterprise grade disks (mounted as /data1 and /data2). The server is dedicated to this MySQL Instance. System memory capacity is 64G. The my.cnf file contents are displayed here:

[mysqld]
datadir=/data1/
innodb_buffer_pool_size=28G
innodb_log_file_size=150M

Which four changes provide the most performance improvement, without sacrificing data integrity?

A. innodb-doublewrite=off

B. innodb_log_group_home_dir=/data2/

C. innodb_log_file_size=1G

D. innodb_undo_directory=/dev/shm

E. log-bin=/data2/

F. innodb_flush_log_at_trx_commit=0

G. sync_binlog=0

H. innodb_buffer_pool_size=32G

I. disable-log-bin

正确答案：

B. innodb_log_group_home_dir=/data2/

C. innodb_log_file_size=1G

E. log-bin=/data2/

H. innodb_buffer_pool_size=32G

关键解析

1. 调整 innodb_log_group_home_dir（选项 B）

将 InnoDB 的日志文件（ib_logfile0 和 ib_logfile1）移动到 /data2/，利用独立的磁盘分散 I/O 压力。

作用：避免日志文件与数据文件（/data1）竞争磁盘资源，提升写性能。
数据完整性：不影响事务日志的持久性，仅调整存储位置。

2. 增大 innodb_log_file_size（选项 C）

将日志文件大小从 150M 调整为 1G。

作用：减少日志切换频率，降低因频繁刷盘导致的性能抖动。对于写密集型场景（90% 写），更大的日志文件能缓冲更多事务修改，提升吞吐量。
推荐值：通常建议日志文件总大小（innodb_log_file_size × innodb_log_files_in_group）至少容纳 1 小时的写入量。假设每小时写入量在 4G 左右，1G 的单个日志文件是合理的。

3. 调整二进制日志路径（选项 E）

将二进制日志（log-bin）存储到 /data2/。

作用：分离二进制日志与数据文件的 I/O，避免磁盘争用。
数据完整性：不影响二进制日志的写入逻辑，仅优化存储位置。

4. 增大 innodb_buffer_pool_size（选项 H）

将缓冲池从 28G 调整为 32G。

作用：利用空闲内存（64G 总内存）扩大缓冲池，减少磁盘随机读操作。
推荐值：通常设置为系统内存的 50%-70%（即 32G-45G），32G 是合理且安全的调整。

排除其他选项的原因

选项	排除原因
A. `innodb-doublewrite=off`	关闭双写缓冲会破坏崩溃恢复机制，可能导致数据页损坏。
D. `innodb_undo_directory=/dev/shm`	将 Undo 日志放到内存文件系统（`/dev/shm`）会因服务器重启导致数据丢失，违反数据完整性要求。
F. `innodb_flush_log_at_trx_commit=0`	事务提交后每秒刷盘一次，崩溃时可能丢失 1 秒内的数据。
G. `sync_binlog=0`	依赖操作系统刷盘，崩溃时可能丢失未同步的 Binlog 数据。
I. `disable-log-bin`	禁用二进制日志会破坏主从复制功能，且无法进行时间点恢复。

总结

B、C、E、H 是唯一能在不牺牲数据完整性的前提下显著提升性能的选项。通过分散 I/O 压力（B、E）、扩大日志缓冲（C）、优化内存利用（H），可有效应对 90% 写负载的场景，同时保持事务安全性和复制可靠性。

题目 54

Which two actions will secure a MySQL server from network-based attacks?

A. Use MySQL Router to proxy connections to the MySQL server.

B. Place the MySQL instance behind a firewall.

C. Use network file system (NFS) for storing data.

D. Change the listening port to 3307.

E. Allow connections from the application server only.

正确答案：

**B. Place the MySQL instance behind a firewall. **

E. Allow connections from the application server only.

关键解析：

防火墙部署（选项 B）

将 MySQL 服务器置于防火墙后，可通过规则限制非必要的外部访问。例如，仅开放 MySQL 默认端口（3306）并限制 IP 范围。此措施能阻止未经授权的端口扫描和暴力破解攻击。实际操作中，可配置防火墙仅允许应用服务器 IP 访问数据库端口，例如使用 Linux 的 iptables 或 firewalld 工具。

限制连接来源（选项 E）
在 MySQL 配置中绑定 bind-address 或设置白名单，仅允许应用服务器的 IP 连接数据库。例如，在 my.cnf 中添加 bind-address = 应用服务器IP，或通过 GRANT 语句限制用户访问来源（如 'user'@'192.168.1.%'）。这种细粒度控制减少了暴露面，防止外部恶意 IP 直接访问数据库。

错误选项排除原因：

A. MySQL Router代理连接

MySQL Router主要用于流量路由和负载均衡，本身不直接防御网络攻击，需配合防火墙使用。

C. 使用NFS存储数据

网络文件系统（NFS）可能引入协议漏洞，与网络安全防护无关，且会扩大攻击面。

D. 修改监听端口

通过隐蔽端口（如改为3307）属于“通过模糊性实现安全”，端口扫描可轻易发现新端口，无法有效防御攻击。

总结

B 和 E 结合了网络层和应用层的双重防护：防火墙过滤非法请求，MySQL 配置限制合法来源，形成分层防御体系。其他选项要么不直接解决网络攻击问题，要么安全效果有限。

题目 55

You must store connection parameters for connecting a Linux-based MySQL client to a remote Windows-based MySQL server listening on port 3309.

Which four methods can be used to configure user, host, and database parameters?

A. Embed login information into the SSH tunnel definition.

B. Execute mysql_config_editor to configure the user connection.

C. Configure ~/.my.cnf.

D. Execute the mysqladmin command to configure the user connection.

E. Execute the command in a bash script.

F. Configure environment variables.

G. Define a UNIX socket.

H. Use the usermod program to store static user information.

I. Configure ~/.ssh/config for public key authentication.

正确答案：

B. Execute mysql_config_editor to configure the user connection.

C. Configure ~/.my.cnf.

E. Execute the command in a bash script.

F. Configure environment variables.

关键解析

以下四种方法可用于配置 Linux MySQL 客户端连接远程 Windows MySQL 服务器（端口 3309）的参数：

1. mysql_config_editor（选项 B）

通过 mysql_config_editor 工具将连接参数加密存储在 .mylogin.cnf 文件中，避免明文暴露敏感信息。例如：

mysql_config_editor set --login-path=remote_server --user=myuser --host=192.168.1.100 --port=3309 --password

输入密码后，可通过 mysql --login-path=remote_server 直接连接。

2. ~/.my.cnf（选项 C）

在用户主目录的 .my.cnf 配置文件中定义连接参数，例如：

[client]  
user = myuser  
host = 192.168.1.100  
port = 3309  
password = mypassword

客户端工具（如mysql、mysqldump）会自动读取此文件中的配置。

3. Bash 脚本（选项 E）

在脚本中直接写入连接命令并保存参数，例如：

#!/bin/bash  
mysql -u myuser -h 192.168.1.100 -P 3309 -D mydatabase -p"mypassword"

虽然属于硬编码方式，但可作为临时或自动化场景的解决方案。

4. 环境变量（选项 F）

通过设置环境变量传递连接参数，例如：

export MYSQL_USER=myuser  
export MYSQL_HOST=192.168.1.100  
export MYSQL_PORT=3309  
export MYSQL_PWD=mypassword

之后运行 mysql 命令无需额外参数。

错误选项排除

A. SSH 隧道嵌入参数：SSH 仅处理端口转发，MySQL 登录参数仍需单独配置。
D. mysqladmin 命令：用于管理服务器（如创建用户），无法配置客户端连接参数。
G. UNIX Socket：仅适用于本地通信，远程连接需 TCP/IP。
H. usermod 程序：用于系统用户管理，与 MySQL 连接无关。
I. .ssh/config 公钥认证：仅处理 SSH 连接的密钥验证，不存储 MySQL 参数。

总结

B、C、E、F 是符合题目要求的四种方法，覆盖了加密存储、配置文件、环境变量和脚本化参数传递的典型场景。

题目 56

Examine this statement, which executes successfully:

CREATE TABLE employees (
emp_no int unsigned NOT NULL,
birth_date date NOT NULL,
first_name varchar(14) NOT NULL,
last_name varchar(16) NOT NULL,
hire_date date NOT NULL,
PRIMARY KEY (emp_no)
)ENGINE=InnoDB;

Now examine this query:

SELECT emp_no, first_name, last_name, birth_date
FROM employees
WHERE MONTH (birth_date) = 4;

You must add an index that can reduce the number of rows processed by the query. Which two statements can do this?

A. ALTER TABLE employees ADD INDEX ((CAST (birth_date ->>'$.month' AS unsigned)));

B. ALTER TABLE employees ADD INDEX (birth_date DESC) ;

C. ALTER TABLE employees ADD COLUMN birth_month tinyint unsigned GENERATED ALWAYS AS (MONTH (birth_date)) VIRTUAL NOT NULL,ADD INDEX (birth_month) ;

D. ALTER TABLE employees ADD INDEX (birth_date);

E. ALTER TABLE employees ADD COLUMN birth_month tinyint unsigned GENERATED ALWAYS AS (birth_date ->>'$.month') VIRTUAL NOT NULL,ADD INDEX (birth_month) ;

F. ALTER TABLE employees ADD INDEX ((MONTH (birth_date)));

正确答案：

C. ALTER TABLE employees ADD COLUMN birth_month tinyint unsigned GENERATED ALWAYS AS (MONTH (birth_date)) VIRTUAL NOT NULL,ADD INDEX (birth_month) ;

F. ALTER TABLE employees ADD INDEX ((MONTH (birth_date)));

关键解析

题目要求通过添加索引优化 WHERE MONTH(birth_date) = 4 的查询，减少扫描的行数。以下是对选项的详细分析：

1. 选项 C：创建虚拟列并添加索引

ALTER TABLE employees  
ADD COLUMN birth_month tinyint unsigned GENERATED ALWAYS AS (MONTH(birth_date)) VIRTUAL NOT NULL,  
ADD INDEX (birth_month);

作用：

新增虚拟列 birth_month，其值由 MONTH(birth_date) 动态生成。
对虚拟列创建索引，使查询可以直接通过 birth_month = 4 快速定位数据。

依据：

MySQL 5.7+ 支持虚拟列，通过虚拟列将函数计算结果持久化，并允许索引。
查询优化器可直接使用虚拟列上的索引，避免全表扫描。

2. 选项 F：直接创建函数索引

ALTER TABLE employees ADD INDEX ((MONTH(birth_date)));

作用：

直接在 MONTH(birth_date) 表达式上创建索引，将月份计算结果存储到索引中。

依据：

MySQL 8.0.13+ 支持函数索引，允许直接对表达式（如 MONTH(birth_date)）创建索引，无需虚拟列。
查询优化器会直接使用该索引匹配 WHERE MONTH(birth_date) = 4。

错误选项排除原因

选项	排除原因
A. `CAST(birth_date ->>'$.month')`	`birth_date` 是 `date` 类型，非 JSON 字段，语法错误。
B/D. `birth_date` 普通索引	普通索引无法优化函数操作 `MONTH(birth_date)`，索引失效。
E. `birth_date ->>'$.month'`	同选项 A，`birth_date` 非 JSON 字段，语法不适用。

总结

选项 C 和 F 均有效：

C 适用于 MySQL 5.7+：通过虚拟列间接实现函数索引。
F 适用于 MySQL 8.0.13+：直接创建函数索引。

核心原理：通过预计算 MONTH(birth_date) 并存储到索引中，避免查询时逐行计算。

题目 57

Which two queries are examples of successful SQL injection attacks?

A. SELECT user, passwd FROM members WHERE user = ' ? ' ; INSERT INTO members ('user' , 'passwd' ) VALUES ('bob@example.com' , 'secret' ) ;-- ';

B. SELECT user, phone FROM customers WHERE name = ' \; DROP TABLE users; -- ';

C. SELECT id, name FROM user WHERE user.id= (SELECT members.id FROM members) ;

D. SELECT id, name FROM user WHERE id=23 OR id=32 OR 1=1;

E. SELECT email, passwd FROM members WHERE email = 'INSERT INTO members('email' , ' passwd ' ) VALUES ('bob@example.com' , 'secret') ;-- ';

正确答案：

A. SELECT user, passwd FROM members WHERE user = ' ? ' ; INSERT INTO members ('user' , 'passwd' ) VALUES ('bob@example.com' , 'secret' ) ;-- ';

D. SELECT id, name FROM user WHERE id=23 OR id=32 OR 1=1;

关键解析

以下两个选项是典型的 SQL 注入攻击示例：

1. 选项A：堆叠查询注入（Stacked Query Injection）

SELECT user, passwd FROM members WHERE user = ' ? ' ; INSERT INTO members ('user' , 'passwd' ) VALUES ('bob@example.com' , 'secret' ) ;-- ';

攻击原理：
- 攻击者通过分号（;）分隔两条 SQL 语句，在查询后追加插入新用户的恶意操作。
- -- 注释符用于忽略原查询的剩余部分，避免语法错误。
成功条件：
- 数据库支持堆叠查询（如 MySQL、PostgreSQL）。
- 应用程序未禁用多语句执行（默认允许）。
危害：非法添加用户，可能导致权限提升或数据篡改。

2. 选项D：布尔盲注（Boolean-Based Blind Injection）

SELECT id, name FROM user WHERE id=23 OR id=32 OR 1=1;

攻击原理：
- 通过构造恒真条件 1=1 绕过筛选逻辑，返回所有用户数据。
- 若 OR 1=1 被注入到查询条件中，数据库会返回全部记录。
成功条件：
- 应用程序未对输入参数进行过滤或类型检查。
- 查询结果直接暴露给攻击者（如显示全部用户列表）。
危害：敏感数据泄露（如用户隐私、账户凭证）。

错误选项排除原因

选项	排除原因
B	`\;` 为转义分号，实际无法执行 `DROP TABLE`，且部分数据库（如MySQL）默认禁用堆叠查询中的危险操作。
C	子查询无恶意逻辑，仅为常规数据关联操作，不涉及注入攻击。
E	`INSERT` 语句被包裹在字符串中，不会执行，仅作为查询条件的普通文本处理。

总结

A 和 D 是典型的 SQL 注入攻击：

A 利用堆叠查询实现数据篡改，需数据库支持多语句执行。
D 通过布尔逻辑绕过条件限制，泄露全表数据。

其他选项因语法错误、逻辑无效或缺乏攻击性被排除。

题目 58

Which two tools are available to monitor the global status of InnoDB locking?

A. SHOW ENGINE INNODB STATUS;

B. SHOW TABLE STATUS;

C. INEORMATION_SCHEMA.INNODB_TABLESTATS

D. SHOW STATUS;

E. INFORMATION_SCHEMA.STATISTICS

F. INFORMATION_SCHEMA.INNODB_METRICS

正确答案：

A. SHOW ENGINE INNODB STATUS;

F. INFORMATION_SCHEMA.INNODB_METRICS

关键解析

1. SHOW ENGINE INNODB STATUS

功能：此命令提供 InnoDB 存储引擎的实时状态信息，包括全局锁、行锁、事务状态和死锁详情。
- 输出中的关键部分：
  - LATEST DETECTED DEADLOCK：显示最近的死锁信息，包括涉及的事务、锁类型及等待顺序。
  - TRANSACTIONS：展示当前活跃事务的锁持有和等待状态。
使用场景：快速诊断锁争用、死锁及全局锁状态，是监控 InnoDB 锁问题的核心工具。

2. INFORMATION_SCHEMA.INNODB_METRICS

功能：该表提供 InnoDB 的性能指标，包括锁相关的统计信息（如锁等待次数、锁超时等）。
- 关键字段：
  - lock_system_threads_waiting：当前等待锁的线程数。
  - lock_deadlocks：记录死锁发生次数。
使用场景：通过 SQL 查询实时获取全局锁的量化数据，辅助性能调优和长期监控。

错误选项排除原因

选项	排除原因
B. SHOW TABLE STATUS	仅显示表级元数据（如存储引擎、行数等），不涉及锁状态。
C. INNODB_TABLESTATS	存储表统计信息（如索引基数），与锁无关。
D. SHOW STATUS	包含全局状态变量（如 `Innodb_row_lock_waits`），但需配合 `LIKE` 过滤，非专用锁监控工具。
E. STATISTICS	存储索引统计信息，与锁无关。

总结

A 和 F 是直接面向 InnoDB 全局锁状态监控的工具：

SHOW ENGINE INNODB STATUS 提供实时、详细的锁与事务信息，适用于快速诊断。
INFORMATION_SCHEMA.INNODB_METRICS 通过指标量化锁行为，适合长期性能监控。

其他选项或功能不相关，或仅提供间接信息。

题目 59

Which two authentication plugins require the plain text client plugin for authentication to work?

A. LDAP authentication

B. SHA256 authentication

C. Windows Native authentication

D. PAM authentication

E. MySQL Native Password

F. LDAP SASL authentication

正确答案：

A. LDAP authentication

D. PAM authentication

关键解析

1. 核心逻辑与依赖关系

明文客户端插件（mysql_clear_password）的作用：将密码以明文形式发送到服务器端，适用于需要原始密码进行验证的认证机制。
依赖明文传输的场景：当认证插件需将密码传递给外部系统（如 LDAP 服务器或 PAM 模块）时，必须使用明文传输，因为外部系统无法处理哈希后的密码。

2. 正确选项解析

插件	依赖明文传输的原因	典型场景
A. LDAP 认证	简单 LDAP 认证（`authentication_ldap_simple`）需将明文密码发送至 LDAP 服务器进行验证。	直接通过 LDAP 服务器验证用户密码（如 OpenLDAP 或 Active Directory 集成）。
D. PAM 认证	PAM 模块需要原始密码进行外部系统验证（如 Linux 系统用户或 Kerberos 认证）。	企业内集成操作系统账号认证（如 MySQL 用户与 Linux 系统用户关联）。

3. 错误选项排除原因

错误选项	排除原因
B. SHA256 认证	使用客户端哈希（如 `caching_sha2_password`），服务端接收哈希值而非明文。
C. Windows Native 认证	基于 Windows SSPI 协议，密码通过安全上下文传递，无需明文。
E. MySQL Native Password	客户端将密码哈希后传输（如 `mysql_native_password`），服务端验证哈希值。
F. LDAP SASL 认证	使用 SASL 协议（如 SCRAM-SHA-1）加密传输密码，无需明文。

4. 配置验证示例

LDAP 认证：需在创建用户时显式启用明文插件：

CREATE USER 'ldap_user'@'%' IDENTIFIED WITH authentication_ldap_simple 
  BY 'uid=ldap_user,ou=People,dc=example,dc=com';
-- 客户端连接需指定明文插件
mysql --enable-cleartext-plugin -u ldap_user -p

PAM 认证：需配置 PAM 模块与明文插件：

CREATE USER 'pam_user'@'localhost' IDENTIFIED WITH authentication_pam AS 'mysql-pam';
ALTER USER 'pam_user'@'localhost' REQUIRE mysql_clear_password;
-- 客户端连接时启用明文插件
mysql --enable-cleartext-plugin -u pam_user -p

总结

A（LDAP 认证）和 D（PAM 认证）必须依赖明文客户端插件，因其需原始密码与外部系统交互。其他认证机制通过加密或哈希处理密码，无需明文传输。

题目 60

Which three are types of information stored in the MySQL data dictionary? (Choose three.)

A. performance metrics

B. InnoDB buffer pool LRU management data

C. access control lists

D. view definitions

E. server runtime configuration

F. server configuration rollback

G. stored procedure definitions

正确答案：

C. Access control lists

D. View definitions

G. Stored procedure definitions

解析与依据

1. 视图定义（View Definitions）

MySQL 数据字典存储了所有视图的元数据，包括其 SQL 定义、关联的表结构及访问权限。通过查询 INFORMATION_SCHEMA.VIEWS 表可以直接获取视图的定义细节。例如：

SELECT VIEW_DEFINITION FROM INFORMATION_SCHEMA.VIEWS WHERE TABLE_NAME = 'your_view';

2. 访问控制列表（Access Control Lists）

权限管理相关的元数据（如用户、角色、权限分配）存储在数据字典的特定系统表中：

用户权限：mysql.user（全局权限）、mysql.tables_priv（表级权限）、mysql.columns_priv（列级权限）。
角色与代理权限：mysql.default_roles（默认角色）、mysql.proxies_priv（代理用户权限）。

这些表共同构成访问控制的核心数据。

3. 存储过程定义（Stored Procedure Definitions）

存储过程和函数的元数据（如名称、参数、定义体）存储在 INFORMATION_SCHEMA.ROUTINES 表中。例如：

SELECT ROUTINE_DEFINITION FROM INFORMATION_SCHEMA.ROUTINES 
WHERE ROUTINE_NAME = 'your_procedure';

数据字典通过事务性表确保存储过程定义的原子性和一致性。

错误选项排除原因

选项	排除原因
A. Performance metrics	性能指标（如锁等待时间、查询执行统计）由 `performance_schema` 库独立管理，不属数据字典范畴。
B. InnoDB buffer pool LRU management data	缓冲池管理是 InnoDB 引擎内部机制，数据字典不存储此类运行时状态。
E. Server runtime configuration	服务器运行时配置（如全局变量）通过 `GLOBAL_VARIABLES` 表展示，但属于系统状态而非数据字典的结构性元数据。
F. Server configuration rollback	MySQL不支持配置回滚的元数据存储，此功能需依赖外部工具或备份。

总结

数据字典的核心职责是存储数据库对象的结构定义与权限信息，而非运行时状态或性能指标。视图、权限、存储过程均属于典型的元数据类型，符合 MySQL 8.0+ 数据字典的设计目标。

题目 61

Which four are types of information stored in the MySQL data dictionary?

A. server runtime configuration

B. server configuration rollback

C. performance metrics

D. stored procedure definitions

E. InnoDB buffer pool LRU management data

F. view definitions

G. table definitions

H. access control lists

正确答案：

D. Stored procedure definitions

F. View definitions

G. Table definitions

H. Access control lists

关键解析

MySQL数据字典（通过 information_schema 和 mysql 系统库实现）用于存储数据库对象的元数据，以下四类信息明确属于其范畴：

1. 存储过程定义（Stored procedure definitions）

数据字典表：information_schema.ROUTINES
功能：保存存储过程和函数的元数据，包括名称、参数列表、定义体、创建时间等。例如：
```
SELECT ROUTINE_DEFINITION FROM information_schema.ROUTINES WHERE ROUTINE_NAME = 'procedure_name';  
```

2. 视图定义（View definitions）

数据字典表：information_schema.VIEWS

功能：记录视图的名称、SQL定义、安全类型（如DEFINER或INVOKER）。例如：

SELECT VIEW_DEFINITION FROM information_schema.VIEWS WHERE TABLE_NAME = 'view_name';

3. 表定义（Table definitions）

数据字典表：information_schema.TABLES 和 information_schema.COLUMNS
功能：
- TABLES：存储表名、引擎类型、创建时间等基本信息。
- COLUMNS：记录列名、数据类型、是否允许NULL等字段属性。

4. 访问控制列表（Access control lists）

数据字典表：mysql.user、mysql.db、mysql.tables_priv等
功能：存储用户权限信息，包括全局权限、数据库级权限、表级权限等。例如：
```
SELECT * FROM mysql.user WHERE User = 'username';  -- 查看用户全局权限  
```

错误选项排除原因

选项	排除原因
A. Server runtime configuration	运行时配置（如全局变量 `max_connections`）存储在 `performance_schema` 或通过 `SHOW VARIABLES` 查看，非数据字典范畴。
B. Server configuration rollback	MySQL 原生不支持配置回滚功能，需依赖外部工具或备份。
C. Performance metrics	性能指标由 `performance_schema` 库管理（如 `events_statements_summary_by_digest`）。
E. InnoDB buffer pool LRU management data	缓冲池管理是 InnoDB 引擎内部机制，属于运行时状态，不存储为元数据。

总结

数据字典的核心职责是管理数据库对象的结构和权限元数据，而非运行时状态或性能指标。存储过程、视图、表结构和权限信息均属于典型的元数据类型，符合 MySQL 数据字典的设计目标。

题目 62

Examine this SQL statement:

mysql> GRANT r_read@localhost TO mark WITH ADMIN OPTION;

Which two are true?

A. Mark can grant the privileges assigned to the r_read@localhost role to another user.

B. Mark can grant the r_read@localhost role to another user.

C. ADMIN OPTION causes the role to be activated by default.

D. Mark must connect from localhost to activate the r_read@localhost role.

E. Mark can revoke the r_read@localhost role from another role.

F. ADMIN OPTION allows Mark to drop the role.

正确答案：

B. Mark can grant the r_read@localhost role to another user.

E. Mark can revoke the r_read@localhost role from another role.

关键解析

1. 选项 B：Mark 可以将 r_read@localhost 角色授予其他用户

在 MySQL 中，WITH ADMIN OPTION 的关键作用是允许被授权者（如 Mark）将相同的角色分配给其他用户或角色，从而实现权限的级联管理。因此，B 是正确的。

2. 选项 E：Mark 可以撤销其他角色的r_read@localhost角色

WITH ADMIN OPTION 不仅允许用户授予角色，还赋予其对已分配角色的管理权，包括撤销权限。因此，E是正确的。

错误选项排除原因

选项	排除原因
A	`WITH ADMIN OPTION` 授权的是角色本身的管理权，而非直接操作角色内的权限。Mark 需通过角色继承权限后再单独分配权限，而非直接授予角色内的权限。
C	`ADMIN OPTION` 与角色激活无关。角色是否默认激活由 `SET DEFAULT ROLE` 或 `activate_all_roles_on_login` 参数控制。
D	角色的激活与用户连接的主机无关，只要用户具备权限即可激活角色。`r_read@localhost` 中的 `localhost` 仅限制角色的适用范围，不影响用户连接来源。
F	删除角色需要 `DROP ROLE` 权限，而 `WITH ADMIN OPTION` 仅允许管理角色的分配，不涉及删除操作。

总结

B 正确：WITH ADMIN OPTION 允许 Mark 将 r_read@localhost 角色授予其他用户或角色。
E 正确：Mark 可以撤销自己授予的该角色权限。

其他选项因混淆权限范围、角色激活机制或权限层级被排除。

题目 63

Which two statements are true about general tablespaces?

A. General tablespaces support temporary tables.

B. Dropping a table from a general tablespace releases the space back to the operating system.

C. A new table can be created explicitly in a general tablespace.

D. An existing table can be moved into a general tablespace.

E. A general tablespace can have multiple data files.

正确答案：

C. A new table can be created explicitly in a general tablespace

D. An existing table can be moved into a general tablespace

关键解析

1. 选项 C：可以在通用表空间中显式创建新表

通用表空间允许用户通过 CREATE TABLE ... TABLESPACE 语法直接指定表所属的表空间。例如：

CREATE TABLE t1 (id INT PRIMARY KEY) TABLESPACE my_general_ts;

此语法明确将表 t1 创建在名为 my_general_ts 的通用表空间中。此外，通用表空间支持所有非临时表的存储，包括动态行格式（如 ROW_FORMAT=DYNAMIC）和压缩表（需指定 FILE_BLOCK_SIZE）。因此，C 正确。

2. 选项 D：现有表可以移动到通用表空间中

通过 ALTER TABLE ... TABLESPACE 语法，用户可以将现有表从独立表空间或系统表空间迁移到通用表空间。例如：

ALTER TABLE existing_table TABLESPACE my_general_ts;

这一操作不会释放原表空间的存储空间，但允许表在通用表空间内重新组织。通用表空间的设计目标之一正是支持表的动态迁移，以优化存储布局或性能。因此，D 正确。

错误选项排除原因

选项	排除原因
A. General tablespaces support temporary tables	临时表必须存储在专用临时表空间（如 `ibtmp1`）或独立临时表空间，通用表空间不支持临时表。
B. Dropping a table releases space to the OS	删除通用表空间中的表后，其占用的空间仍保留在表空间内供后续使用，不会直接释放给操作系统。
E. A general tablespace can have multiple data files	通用表空间仅支持单个 `.ibd` 数据文件，创建时只能指定一个文件路径，无法扩展为多文件。

关键知识点总结

通用表空间的特性：

共享存储：允许多个表共享一个数据文件，减少元数据内存开销。
灵活存储管理：数据文件可放置在自定义路径（需配置 innodb_directories），支持加密（ENCRYPTION='Y'）和性能优化（如 RAID）。
行格式兼容性：支持所有 InnoDB 行格式（如 COMPACT、DYNAMIC、COMPRESSED），但压缩表需单独配置 FILE_BLOCK_SIZE。

使用场景：
- 大表集中管理：将高频访问的热点表集中到高性能存储介质（如 SSD）的通用表空间中。
- 动态迁移优化：通过 ALTER TABLE 将表从系统表空间或独立表空间迁移到通用表空间，减少碎片并统一管理。
操作限制：
- 单文件限制：每个通用表空间仅支持一个 .ibd 文件，无法通过 ADD DATAFILE 扩展。
- 删除与回收：删除表后空间不会释放至OS，需手动执行 ALTER TABLESPACE ... DISCARD 或重建表空间。

题目 64

Which three methods are part of a 'scale up' approach to capacity planning?

A. adding additional MySQL servers to the existing host

B. adding more CPU power

C. adding a replication slave

D. adding more RAM

E. adding more storage to your disk array

F. sharding the server into a parallel server farm

G. adding a new node to InnoDB Cluster

正确答案：

B. adding more CPU power

D. adding more RAM

E. adding more storage to your disk array

关键解析

B. 增加 CPU 算力（Adding more CPU power）
- 通过升级单个服务器的 CPU 核心数或性能来提高处理能力，例如更换更高主频的 CPU 或增加多核处理器。这是典型的纵向扩展策略。
D. 增加内存容量（Adding more RAM）
- 扩展物理内存可减少磁盘分页频率，提升数据库缓存效率，尤其适用于内存密集型应用（如 InnoDB 缓冲池优化）。
E. 扩展磁盘存储（Adding more storage to your disk array）
- 通过添加更大容量或更高性能的磁盘（如 SSD 替换 HDD），或扩展 RAID 阵列存储空间，直接提升单节点的存储能力。

错误选项排除原因

选项	排除原因
A. 添加 MySQL 服务器节点	属于横向扩展（Scale Out），通过增加服务器数量分散负载，例如构建读写分离集群。
C. 添加复制从库	复制从库用于分担读请求，属于横向扩展的负载均衡策略，不涉及单节点硬件升级。
F. 分片（Sharding）	分片将数据分布到多个服务器，属于典型的横向扩展方案（如分布式数据库设计）。
G. 向 InnoDB 集群添加节点	InnoDB 集群通过多节点协同工作实现扩展，属于横向扩展范畴。

纵向扩展与横向扩展对比

维度	纵向扩展（Scale Up）	横向扩展（Scale Out）
核心思想	提升单节点性能	增加节点数量
硬件调整	升级 CPU、内存、存储	新增服务器或分布式节点
适用场景	计算密集或内存瓶颈	高并发、大数据量
成本与复杂度	初期成本高，维护简单	长期成本低，架构复杂
扩展上限	受单机硬件限制	理论上无限扩展

总结

纵向扩展（Scale Up）适用于需快速提升单节点性能的场景，如 CPU 密集型查询、内存不足导致的频繁分页或存储容量不足。其优势在于架构简单、维护成本低，但存在硬件性能天花板，需结合业务增长趋势权衡升级策略。

题目 65

A user wants to connect without entering his or her username and password on the Linux command prompt. Which three locations can be used to store the user's mysql credentials to satisfy this requirement?

A. $HOME/.mysqlrc file

B. /etc/my.cnf file

C. DATADIR/mysqld-auto.cnf file

D. $HOME/.my.cnf file

E. $HOME/.mylogin.cnf file

F. $MYSQL_HOME/my.cnf file

G. $HOME/.mysql/auth/login file

正确答案

B. /etc/my.cnf file

D. $HOME/.my.cnf file

E. $HOME/.mylogin.cnf file

关键解析

1. 选项 B：/etc/my.cnf（全局配置文件）

功能：这是 MySQL 的全局配置文件，所有用户共享。通过在 [client] 标签下添加用户名和密码，可以实现免密登录。

示例配置：

[client]
user = root
password = your_password

权限与安全性：需确保文件权限为 644（仅管理员可写），避免密码明文泄露。

2. 选项 D：$HOME/.my.cnf（用户级配置文件）

功能：用户主目录下的 .my.cnf 文件优先级高于全局配置。通过在此文件中定义 [client] 字段，可为当前用户实现免密登录。

示例配置：

[client]
user = devuser
password = secure_password

安全性：需设置文件权限为 600，仅允许当前用户访问，减少密码泄露风险。

3. 选项 E：$HOME/.mylogin.cnf（加密凭证文件）

功能：通过 mysql_config_editor 工具生成加密的凭证文件，避免密码明文存储。例如：
```
mysql_config_editor set --login-path=client --user=root --password
```
执行后输入密码，生成 ~/.mylogin.cnf 文件。
优势：密码以加密形式存储，安全性更高，适合自动化脚本或长期免密需求。

错误选项排除原因

选项	排除原因
A. `$HOME/.mysqlrc`	MySQL 官方未定义 `.mysqlrc` 作为配置文件格式，无效。
C. `DATADIR/mysqld-auto.cnf`	此文件用于持久化动态配置（如 `SET PERSIST` 命令生成），与用户凭证无关。
F. `$MYSQL_HOME/my.cnf`	`MYSQL_HOME` 环境变量用于指定MySQL安装路径的配置目录，但非标准免密凭证存储位置。
G. `$HOME/.mysql/auth/login`	MySQL 不通过此路径管理认证文件，属于混淆选项。

安全实践建议

加密优先：优先使用 mysql_config_editor 生成加密的 .mylogin.cnf 文件，避免明文存储密码。
最小权限原则：配置文件权限设为 600，确保仅当前用户可读写。
区分场景：

临时调试：使用全局 /etc/my.cnf 或用户级 ~/.my.cnf，但需及时清理密码。
长期免密：选择加密的 .mylogin.cnf，结合权限控制。

题目 66

Examine the modified output:

mysql> SHOW SLAVE STATUS\G
*******************1. row*********************
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Seconds_Behind_Master: 1612

Seconds_Behind_Master value is steadily growing. What are two possible causes?

A. The master is producing a large volume of events in parallel but the slave is processing them serially.

B. This value shows only I/O latency and is not indicative of the size of the transaction queue.

C. One or more large tables do not have primary keys.

D. The master is most probably too busy to transmit data and the slave needs to wait for more data.

E. The parallel slave threads are experiencing lock contention.

正确答案

A. The master is producing a large volume of events in parallel but the slave is processing them serially.

D. The master is most probably too busy to transmit data and the slave needs to wait for more data.

关键解析

根据题目中 SHOW SLAVE STATUS 的输出，Seconds_Behind_Master 的值持续增长（当前为 1612 秒），说明主从复制存在显著延迟。

1. 选项 A 正确性分析

核心机制：
- 主库在并行生成大量事务（如多线程写入），但从库默认使用单线程（或未启用并行复制）处理这些事件。
- 主库的并行性与从库的串行执行能力不匹配，导致事务在从库堆积，延迟持续增长。
解决方案：
- 启用从库的并行复制功能（设置 slave_parallel_workers 和 slave_parallel_type=LOGICAL_CLOCK），使从库能并发应用事务。

2. 选项 D 正确性分析

核心机制：
- 主库因高负载或网络带宽不足，导致 I/O 线程无法及时拉取二进制日志（Binlog）。
- 从库的 SQL 线程因等待新事件而空闲，但延迟指标仍会持续增加（因 Seconds_Behind_Master 的计算依赖主库事件的时间戳）。
验证方法：
- 检查主库的 Binlog Dump 线程状态（如 SHOW PROCESSLIST），确认是否存在传输瓶颈。

错误选项排除原因

选项	排除原因
B. 仅反映 I/O 延迟，不反映事务队列规模	`Seconds_Behind_Master` 综合了 I/O 和 SQL 线程的延迟，并非仅 I/O 延迟。主从延迟的计算基于事件时间戳，能反映事务队列积压。
C. 大表无主键	无主键表在行格式复制（ROW）时会导致全表扫描，降低复制效率，但通常表现为延迟波动而非稳定增长。
E. 并行线程锁争用	并行复制的锁争用会导致延迟随机波动（如死锁重试），而非持续增长。

补充技术细节

Seconds_Behind_Master 的计算逻辑：

延迟 = 从库当前时间 - 主库事件时间戳 - 主从时钟差。
若主库事件持续积压，该值会线性增长；若从库处理速度与主库同步，则保持稳定或下降。

延迟持续增长的场景：

主库高并发写入：从库单线程无法跟上主库并行事务生成速度（选项 A）。
主库网络/磁盘瓶颈：Binlog 传输速率低于主库生成速率（选项 D）。

优化建议

启用并行复制：

-- 设置并行工作线程数（如 4）  
SET GLOBAL slave_parallel_workers = 4;  
-- 设置事务依赖模式为逻辑时钟  
SET GLOBAL slave_parallel_type = 'LOGICAL_CLOCK';

监控主从状态：

定期检查 SHOW SLAVE STATUS 中的 Read_Master_Log_Pos 和 Exec_Master_Log_Pos 差值，量化 I/O 和 SQL 线程的积压。

硬件与网络优化：

升级主库网络带宽或优化磁盘 I/O（如使用 SSD）。

题目 67

Which two are true about binary logs used in asynchronous replication?

A. The master connects to the slave and initiates log transfer.

B. They contain events that describe all queries run on the master.

C. They contain events that describe database changes on the master.

D. They are pulled from the master to the slave.

E. They contain events that describe only administrative commands run on the master.

正确答案

C. They contain events that describe database changes on the master.

D. They are pulled from the master to the slave.

关键解析

1. 选项 C 正确性分析

二进制日志（Binary Log）的核心功能是记录主库上所有数据库变更事件，包括数据修改（如 INSERT、UPDATE、DELETE）和结构变更（如 CREATE TABLE、ALTER TABLE），但不包含不修改数据的查询（如 SELECT）。

示例：若主库执行 UPDATE users SET name='Alice' WHERE id=1，二进制日志会记录这一行数据的变更事件（若使用 ROW 格式）或对应的 SQL 语句（若使用 STATEMENT 格式）。
错误排除：选项 B（包含所有查询）错误，因为仅记录修改数据的操作；选项 E（仅管理命令）错误，因二进制日志涵盖所有数据变更，不限于管理命令。

2. 选项 D 正确性分析

在异步复制中，二进制日志的传输是从库主动拉取的机制：

主库被动角色：主库仅生成二进制日志，不主动连接从库。
从库 I/O 线程：从库通过 I/O 线程连接到主库，请求并拉取二进制日志内容，写入本地的中继日志（Relay Log）。
错误排除：选项 A（主库主动连接从库）错误，主库的 Binlog Dump 线程仅在从库连接时响应，不主动发起传输。

错误选项解析

选项	排除原因
A. 主库连接从库并启动日志传输	主库的 `Binlog Dump` 线程仅在从库连接时被触发，主库不会主动发起连接。
B. 包含主库所有执行的查询	二进制日志仅记录数据变更操作（如 DML、DDL），不记录查询类语句（如 `SELECT`）。
E. 仅包含管理命令	二进制日志记录所有数据变更事件，包括业务操作（如用户数据更新），不限于管理命令。

二进制日志在异步复制中的核心特性

事件粒度：

支持三种格式：STATEMENT（SQL语句）、ROW（行数据变更）、MIXED（混合模式）。
ROW 格式确保数据一致性，但日志量较大；STATEMENT 格式日志量小，但可能因上下文差异导致主从不一致。

传输机制：
- 异步复制中，主库提交事务后立即返回客户端，从库异步拉取日志，存在数据延迟风险。
- 从库通过 SHOW SLAVE STATUS 监控 Relay_Log_Pos 和 Exec_Master_Log_Pos 判断同步进度。
应用场景：
- 数据恢复：通过备份 + 二进制日志实现时间点恢复（Point-in-Time Recovery）。
- 主从同步：从库重放主库日志以保持数据一致性。

题目 68

You have appropriate privileges and are about to shut down a running MySQL server process on Oracle Linux 7.

Which three are valid methods that will shut down the MySQL server?

A. mysqld_safe -S /tmp/mysql.sock SHUTDOWN

B. kill mysqld_safe

C. mysqladmin shutdown

D. mysql -S /tmp/mysql.sock --shutdown

E. mysqld_safe --shutdown

F. systemctl stop mysqld

G. mysql> SHUTDOWN;

正确答案

C. mysqladmin shutdown

F. systemctl stop mysqld

G. mysql> SHUTDOWN;

关键解析

1. 选项 C：mysqladmin shutdown

这是通过 MySQL 官方工具 mysqladmin 关闭服务器的标准方法，需提供具有权限的用户名和密码。例如：

mysqladmin -u root -p shutdown -S /tmp/mysql.sock

执行后，MySQL 会完成当前事务并清理资源后关闭。

2. 选项 F：systemctl stop mysqld

在 Oracle Linux 7（基于 Systemd）中，通过系统服务管理命令关闭 MySQL 是推荐方式。执行：

systemctl stop mysqld

这会触发 MySQL 的优雅关闭流程，适用于通过包管理器（如 RPM）安装的 MySQL 实例。

3. 选项 G：mysql> SHUTDOWN;

在 MySQL 命令行中执行 SHUTDOWN 语句，需具备 SHUTDOWN 权限。例如：

mysql> SHUTDOWN;

此操作会通知服务器完成所有活动事务、释放资源后关闭。

错误选项排除原因

选项	排除原因
A. `mysqld_safe -S ... SHUTDOWN`	`mysqld_safe` 是MySQL的启动脚本，用于监控 `mysqld` 进程，不支持直接关闭参数。其用途是启动服务器而非关闭。
B. `kill mysqld_safe`	`mysqld_safe` 是管理进程，强制终止可能导致 `mysqld` 主进程未清理资源，属于非优雅关闭方式，可能引发数据损坏。
D. `mysql --shutdown`	`mysql` 客户端工具不支持 `--shutdown` 参数，关闭操作需通过 `mysqladmin` 或内部语句实现。
E. `mysqld_safe --shutdown`	同选项 A，`mysqld_safe` 设计用于启动服务器，无 `--shutdown` 功能，此命令无效。

补充说明

优雅关闭与强制关闭的区别：

优雅关闭（选项 C、F、G）会等待事务提交、释放内存和文件句柄，确保数据一致性。
强制关闭（如 kill -9）跳过清理步骤，可能导致未提交事务丢失或表损坏，需后续恢复。

权限要求：

mysqladmin shutdown 和 SHUTDOWN 语句需要用户具备 SHUTDOWN 权限。
systemctl stop mysqld 需操作系统管理员权限（如 sudo）。

多实例场景：
- 若服务器有多个实例，需通过 -S 指定 Socket 文件（如 /tmp/mysql.sock）或端口区分。

题目 69

Examine this MySQL Shell command:

dba.rebootClusterFromCompleteOutage()

Which two statements are true?

A. It stops and restarts all InnoDB Cluster instances and initializes the metadata.

B. It only stops and restarts all InnoDB Cluster instances.

C. It is not mandatory that all instances are running and reachable before running the command.

D. It performs InnoDB Cluster instances rolling restart.

E. It reconfigures InnoDB Cluster if the cluster was stopped.

F. It picks the minimum number of instances necessary to rebuild the quorum and reconfigures InnoDB Cluster.

G. It only starts all InnoDB Cluster instances.

正确答案

E. It reconfigures InnoDB Cluster if the cluster was stopped.

F. It picks the minimum number of instances necessary to rebuild the quorum and reconfigures InnoDB Cluster.

关键解析

1. 选项 E 正确性分析

dba.rebootClusterFromCompleteOutage() 的核心功能是在集群完全停止后重新配置并恢复元数据。

适用场景：当所有集群成员因故障停止（如组复制完全终止）时，通过连接到任一存活实例执行此命令，利用其元数据重建集群。
操作机制：
- 验证实例配置的兼容性（如 group_replication_group_name 是否一致）。
- 重新创建恢复账户（如 mysql_innodb_cluster_201），并同步事务至所有节点。
与重启无关：该命令不会主动停止或启动实例，仅基于现有实例状态重新配置集群。若实例未运行，需先手动启动服务。

2. 选项 F 正确性分析

此命令会选取满足法定人数（Quorum）的最小实例集来恢复集群一致性。

法定人数原则：InnoDB Cluster 要求多数节点在线以维护高可用性。例如，3 节点集群需至少 2 个节点可达。
执行逻辑：
- 优先选择元数据最新的实例作为种子节点（Seed Instance），逐步重新加入其他节点。
- 若部分实例不可达（如 UNREACHABLE），仍会尝试恢复可达节点，但可能因数据分歧产生警告。
验证过程：通过 SHOW SLAVE STATUS 监控事务同步进度，确保数据一致性。

错误选项排除原因

选项	排除原因
A/B/D/G（停止/重启实例）	此命令不涉及停止或重启实例，仅重新配置元数据并恢复集群状态。实例需提前手动启动。
C（非强制实例运行）	执行前必须确保所有实例已启动且可访问，否则命令会因无法连接节点而失败。

补充技术细节

元数据一致性要求：

所有实例的 group_replication_group_name 必须与元数据一致。若不一致（如 MySQL 5.7 因缺乏 SET PERSIST 导致重启后配置丢失），需手动修正后才能执行恢复。

安全性与权限：
- 需使用具有 CLUSTER_ADMIN 权限的账户连接 MySQL Shell。
- 恢复过程中会重新生成加密的恢复账户密码，避免凭证泄露风险。
网络分区与脑裂处理：
- 若集群因网络分区导致脑裂（多个主节点），需通过 Cluster.fenceWrites() 隔离写入流量后再执行恢复。

操作建议

前置检查：

# 确认所有实例已启动  
systemctl status mysqld  
# 验证元数据一致性  
mysqlsh> \c admin@node1:3306  
mysqlsh> cluster = dba.getCluster()  
mysqlsh> cluster.status()

执行恢复：

mysqlsh> dba.rebootClusterFromCompleteOutage()

监控恢复进度：
- 通过 cluster.status() 观察节点状态（如 ONLINE、RECOVERING）。
- 检查日志文件确认事务同步进度。

题目 70

Examine this command and output:

root@dbhost:/var/lib/mysql# ls -al
total 540
drwxrwxr-x 1 mysql mysql 	 4096 Aug 22 14:07 .
drwxr-xr-x 1 root  root   	 4096 May 22 00:42 ..
-rw-r----- 1 mysql mysql       56 Aug 20 13:58 auto.cnf
drwxr-xr-x 1 mysql mysql 	 4096 Aug 21 10:28 accounting
-rw-r--r-- 1 mysql mysql     1112 Aug 20 13:58 ca.pem
-rw-r----- 1 mysql mysql   172040 Aug 22 14:07 ib_buffer_pool
-rw-r----- 1 mysql mysql 12582919 Aug 22 14:07 ibdata1
-rw-r----- 1 mysql mysql 50331648 Aug 22 14:07 ib_logfile0
-rw-r----- 1 mysql mysql 50331648 Aug 20 13:47 ib_logfile1
-rw-r----- 1 mysql mysql   292292 Aug 22 14:07 ibtmp1
drwxr-x--- 1 mysql users     4096 Aug 20 13:59 mysql
-rw-r----- 1 mysql mysql    64064 Aug 22 15:18 mysql-error.log
drwxr-x--- 1 mysql mysql  	 4096 Aug 20 13:59 performance_schema
-rw-rw---- 1 mysql mysql     1680 Aug 20 13:59 private_key.pem
-rw-r--r-- 1 mysql mysql      452 Aug 20 13:59 public_key.pem
-rw-r----- 1 mysql mysql     1112 Aug 20 13:58 server-cert.pem
-rw-r----- 1 mysql mysql     1680 Aug 20 13:58 server-key.pem
drwxr-x--- 1 mysql mysql     4096 Aug 20 13:59 sys

Which two options will improve the security of the MySQL instance?

A. Remove the world read/execute privilege from the accounting directory.

B. Remove world read privileges from the public_key.pem file.

C. Change the group ownership of the mysql directory to the mysql user group.

D. Change the parent directory owner and group to mysql.

E. Remove world read privileges from the server-cert.pem certificate file.

F. Remove group read/write privileges from the private_key.pem file.

正确答案

B. Remove world read privileges from the public_key.pem file.

F. Remove group read/write privileges from the private_key.pem file.

关键解析

1. 选项 B 正确性分析

public_key.pem 文件当前的权限为 -rw-r--r--（644），表示其他用户具有读权限。公钥虽然通常可公开，但在生产环境中，根据安全最佳实践，应限制非必要权限以避免潜在风险（例如密钥被恶意复制或滥用）。移除全局读权限可增强安全性。

操作建议：

chmod o-r /var/lib/mysql/public_key.pem  # 修改后权限为640（-rw-r-----）

2. 选项 F 正确性分析

private_key.pem 文件当前的权限为 -rw-rw----（660），表示同组用户具有读写权限。私钥是敏感文件，必须严格限制访问权限。根据安全规范，私钥应仅允许所有者读写（权限 600），避免组用户或其他人操作导致密钥泄露。

操作建议：

chmod g-w /var/lib/mysql/private_key.pem  # 修改后权限为600（-rw-------）

其他选项排除原因

选项	排除原因
A. 移除 `accounting` 目录的全局读/执行权限	`accounting` 目录权限为 `drwxr-xr-x`（755），全局用户有读和执行权限。虽然移除可增强安全性（改为 750），但题目要求选择两处最关键的配置改进，密钥文件的安全优先级更高。
C. 修改 `mysql` 目录的组所有权为 `mysql` 组	`mysql` 目录当前组为 `users`，但该目录权限为 `drwxr-x---`（750），已限制非组用户访问，因此此操作非必要改进项。
D. 修改父目录所有者为 `mysql`	父目录（`/var/lib/mysql`）的所有者已是 `mysql` 用户，无需修改。
E. 移除 `server-cert.pem` 的全局读权限	`server-cert.pem` 当前权限为 `-rw-r-----`（640），其他用户无读权限，因此此操作无需执行。

安全实践补充

关键文件权限规范：

私钥文件（如 private_key.pem）：权限应为 600（仅所有者读写）。
证书文件（如 server-cert.pem、public_key.pem）：权限建议 640（所有者读写，组只读）。

数据目录（如 /var/lib/mysql）权限应设为 750（drwxr-x---），禁止全局访问。

日志文件权限：

mysql-error.log 当前权限为 -rw-r-----（640），符合安全要求，无需调整。

操作验证

执行权限修改后，可通过以下命令验证：

ls -l /var/lib/mysql/public_key.pem /var/lib/mysql/private_key.pem

预期输出：

-rw-r----- 1 mysql mysql 452 Aug 20 13:59 public_key.pem  
-rw------- 1 mysql mysql 1680 Aug 20 13:59 private_key.pem

题目 71

Which two statements are true about general tablespaces?

A. General tablespaces support temporary tables.

B. Dropping a table from a general tablespace releases the space back to the operating system.

C. A new table can be created explicitly in a general tablespace.

D. An existing table can be moved into a general tablespace.

E. A general tablespace can have multiple data files.

正确答案

C. A new table can be created explicitly in a general tablespace.

D. An existing table can be moved into a general tablespace.

关键解析

1. 选项 C 正确性分析

通用表空间允许用户通过 CREATE TABLE ... TABLESPACE 语法显式指定表所属的通用表空间。例如：

CREATE TABLE my_table (id INT PRIMARY KEY) TABLESPACE general_ts;

此操作会在通用表空间 general_ts 中创建新表。

关键特性：

通用表空间是多表共享的存储容器，支持所有非临时表的行格式（如 COMPACT、DYNAMIC 等）。
创建时必须确保通用表空间已存在，且用户具备权限。

2. 选项 D 正确性分析

通过 ALTER TABLE 语句可将现有表迁移到通用表空间：

ALTER TABLE existing_table TABLESPACE general_ts;

此操作会将表的存储位置从独立表空间或系统表空间转移到目标通用表空间。

注意事项：

迁移表需满足通用表空间的行格式兼容性（如压缩表需匹配 FILE_BLOCK_SIZE 设置）。
迁移后需重建索引以确保性能。

错误选项排除原因

选项	排除原因
A. 支持临时表	通用表空间仅支持普通表，临时表必须存储在专用临时表空间（如 `ibtmp1` 或会话临时表空间）。
B. 删除表释放空间到 OS	通用表空间删除表后，空间保留在表空间内部供后续使用，需手动执行 `ALTER TABLESPACE ... DISCARD` 释放。
E. 支持多数据文件	每个通用表空间仅允许一个数据文件（如 `general_ts.ibd`），无法扩展多个文件。

补充技术细节

通用表空间的核心特性：

共享存储：多个表可共享同一表空间，减少元数据内存占用。
灵活位置：数据文件可放置在 innodb_directories 配置的路径中，支持跨存储设备优化 I/O。
加密支持：可通过 ENCRYPTION='Y' 启用表空间加密。

性能与限制：
- 空间管理：通用表空间删除表后内部碎片需手动整理，而独立表空间（innodb_file_per_table=ON）会直接释放空间。
- 兼容性：压缩表需指定 FILE_BLOCK_SIZE 参数，且同一表空间内不能混用不同压缩格式的表。

题目 72

Examine this command, which executes successfully:

cluster.addInstance( '<user>@<host>:<port>',{recoveryMethod: 'clone'})

Which three statements are true?

A. It is always slower than {recoveryMethod: ' incremental ' }.

B. InnoDB tablespaces outside the datadir are able to be cloned.

C. A target instance must exist, then it will be provisioned with data from an instance already in the cluster and joined to the cluster.

D. The account used to perform this recovery needs the BACKUP_ADMIN privilege.

E. A new instance is installed, initialized, and provisioned with data from an instance already in the cluster and joined to the cluster.

F. InnoDB redo logs must not rotate for the duration of the execution; otherwise, the recovery will fail.

正确答案

B. InnoDB tablespaces outside the datadir are able to be cloned.

C. A target instance must exist, then it will be provisioned with data from an instance already in the cluster and joined to the cluster.

D. The account used to perform this recovery needs the BACKUP_ADMIN privilege.

关键解析

1. 选项 B 正确性分析

InnoDB 表空间（如独立表空间或通用表空间）支持克隆。克隆插件会完整复制所有表空间文件（包括 *.ibd 和外部表空间文件），确保数据一致性。例如，若存在外部表空间 /external/ts1.ibd，克隆后目标实例的相同路径下会生成副本。

2. 选项 C 正确性分析

当使用 {recoveryMethod: 'clone'} 时，目标实例必须预先存在，但需处于未加入集群的空状态。AdminAPI 会通过克隆插件将集群中某成员的全量数据覆盖到目标实例，并自动完成组复制的配置和加入集群操作。例如：

# 目标实例需已安装 MySQL 并启动，但未加入集群  
cluster.addInstance('user@new-node:3306', {recoveryMethod: 'clone'});

这与选项 E 的“新实例被安装并初始化”矛盾，克隆仅覆盖数据，不涉及新实例的安装流程。

3. 选项 D 正确性分析

克隆操作需要 BACKUP_ADMIN 权限，因为克隆插件在执行时会生成物理快照，并需要管理备份锁和文件传输。AdminAPI 会自动验证用户权限，若缺失该权限会导致操作失败。例如：

-- 用户需具备以下权限  
GRANT BACKUP_ADMIN, CLONE_ADMIN ON *.* TO 'cluster_user'@'%';

错误选项排除原因

选项	排除原因
A. 克隆总比增量恢复慢	克隆在数据量大或目标实例落后较多时效率更高，因增量恢复需逐事务同步，而克隆直接覆盖物理文件。
E. 新实例被安装初始化	克隆仅覆盖数据，不涉及新实例的安装或初始化流程，目标实例需预先存在。
F. Redo 日志不可轮转	克隆基于物理快照，与 Redo 日志轮转无关，执行期间日志可正常切换。

技术细节补充

克隆流程：

AdminAPI 选择集群中数据最新的节点作为“提供者”（Donor）。
目标实例（Recipient）通过克隆插件从 Donor 拉取全量数据并覆盖本地存储。
自动配置组复制参数（如 group_replication_group_seeds）并启动组复制线程。

权限要求：

提供者节点：需具备 BACKUP_ADMIN 和 CLONE_ADMIN。
目标节点：需具备 CLONE_ADMIN 和 REPLICATION_APPLIER。

网络与存储要求：

提供者与目标实例间需开放 MySQL 端口（默认3306）和克隆专用端口（默认33061）。
目标实例的存储空间需至少等于提供者的数据总量，包括临时文件。

题目 73

Which three sets of item information are visible in the mysql system database?

A. time zone information and definitions

B. help topics

C. plugins

D. audit log events

E. performance monitoring information

F. rollback segments

G. information about table structures

正确答案

A. time zone information and definitions

B. help topics

C. plugins

关键解析

1. 选项 A（时区信息与定义）

MySQL 系统数据库（mysql）存储了时区相关的表和定义，例如 time_zone、time_zone_name 等表，用于管理全局时区设置。这些信息对跨时区应用至关重要，用户可以通过查询这些表来配置时区规则。

2. 选项 B（帮助主题）

mysql 数据库包含 help_topic、help_category 等表，用于存储 MySQL 内置的帮助文档内容。用户可以通过 HELP 命令直接查询这些帮助主题，例如执行 HELP CREATE TABLE 会调用这些表的信息。

3. 选项 C（插件）

插件信息存储在 mysql.plugin 表中，记录所有已安装的插件（如认证插件、审计插件等）。例如，安装 audit_log 插件后，其配置信息会更新到此表中。

错误选项排除原因

选项	排除原因
D. 审计日志事件	审计日志事件通常由插件（如 `audit_log`）生成，但日志内容本身存储于文件或专用表中，而非 `mysql` 数据库。
E. 性能监控信息	性能监控数据由 `performance_schema` 数据库管理（如 `events_statements_summary` 表），与 `mysql` 数据库无关。
F. 回滚段	回滚段是 InnoDB 存储引擎的内部结构，属于数据字典的一部分，存储在 `information_schema` 或系统表中。
G. 表结构信息	表结构信息由 `information_schema` 数据库管理（如 `TABLES` 和 `COLUMNS` 表），`mysql` 数据库不涉及此类元数据。

补充说明

mysql 数据库的核心功能：
- 用户与权限管理：通过 user、db、tables_priv 等表实现权限控制。
- 插件与扩展支持：通过 plugin 表记录插件配置，支持动态功能扩展。
- 系统工具与元数据：如帮助文档、时区规则等，为管理员提供基础服务。

操作示例：

-- 查看已安装插件  
SELECT * FROM mysql.plugin;  
-- 查询帮助主题分类  
SELECT * FROM mysql.help_category;  
-- 获取时区定义  
SELECT * FROM mysql.time_zone;

题目 74

Which two situations will cause the binary log to rotate?

A. FLUSH HOSTS executed

B. max_binlog_size exceeded

C. max_binlog_cache_size exceeded

D. SET sql_log_bin=1 executed

E. SET sync_binlog=1 executed

F. FLUSH LOGS executed

正确答案

B. max_binlog_size exceeded

F. FLUSH LOGS executed

关键解析

1. 选项 B 正确性分析

当二进制日志文件大小超过 max_binlog_size 参数设定的阈值时，MySQL会自动触发二进制日志轮转（Rotate）。例如：

max_binlog_size 默认值为 1GB，若当前日志文件达到此大小，系统会关闭当前文件并生成新的日志文件。
例外情况：若当前事务尚未提交，即使文件已超阈值，系统会等待事务完成后再轮转，以保证事务完整性。

2. 选项 F 正确性分析

执行 FLUSH LOGS 命令会强制关闭当前的二进制日志文件，并立即创建新的日志文件。例如：

运维操作中，手动执行此命令可快速切换日志文件，便于归档或备份。
此操作也会触发其他日志（如错误日志）的刷新，但核心作用是轮转二进制日志。

错误选项排除原因

选项	排除原因
A. `FLUSH HOSTS`	该命令仅用于清空主机缓存（如连接错误记录），与二进制日志无关。
C. `max_binlog_cache_size`	此参数控制事务缓存大小，超限时会使用临时文件，但不会触发日志轮转。
D. `SET sql_log_bin=1`	此操作启用二进制日志记录，但不会主动触发轮转。
E. `SET sync_binlog=1`	此参数控制日志刷盘频率（每次提交刷盘），与日志轮转无关。

补充技术细节

其他触发轮转的场景：

MySQL 服务重启：重启后会自动生成新的二进制日志文件。
事务跨日志边界：若单个事务过大，可能超过 max_binlog_size 导致轮转，即使未完全写满。

参数调优建议：

若需减少轮转频率，可增大 max_binlog_size（例如设置为 10 GB）。
高频轮转可能增加 I/O 压力，需结合 sync_binlog 参数平衡性能与数据安全。

题目 75

Which three statements are true about MySQL replication?

A. Each slave must have its own MySQL user for replication.

B. A replication user must have the SELECT privilege for all tables that need to be replicated.

C. Each instance in a replication topology must have a unique server ID.

D. Any instance can have multiple slaves, but it can have only one master.

E. Binary logs contain only transactions originating from a single MySQL instance.

F. Replication can use only TCP/IP connections.

G. Binary logging must be enabled on the master in order to replicate to other instances.

正确答案

C. Each instance in a replication topology must have a unique server ID.

F. Replication can use only TCP/IP connections.

G. Binary logging must be enabled on the master in order to replicate to other instances.

关键解析

1. 选项 C 正确性分析

每个 MySQL 实例（无论是主库还是从库）必须配置唯一的 server_id。此参数在复制拓扑中用于标识每个实例，确保事件正确路由和数据一致性。例如，若两个实例具有相同 server_id，会导致数据冲突和复制中断。

2. 选项 F 正确性分析

MySQL 复制强制依赖 TCP/IP 协议建立主从连接。尽管 MySQL 支持其他通信协议（如 Unix Socket 用于本地连接），但复制过程必须通过 TCP/IP 网络传输二进制日志事件。例如，从库需通过主库的 IP 地址和端口（默认3306）建立连接。

3. 选项 G 正确性分析

主库必须启用二进制日志（log_bin=ON），因为复制的基础是主库将数据变更记录到二进制日志，从库通过读取这些日志来同步数据。若主库未启用二进制日志，复制将无法进行。

错误选项排除原因

选项	排除原因
A. 每个从库需独立复制用户	多个从库可共享同一复制用户，只需用户具有 `REPLICATION SLAVE` 权限。
B. 复制用户需 SELECT 权限	复制用户只需 `REPLICATION SLAVE` 权限，无需直接访问表数据。
D. 实例可多从库但仅一主库	多源复制支持从库连接多个主库，因此实例可存在多个主库。
E. 二进制日志仅含单实例事务	从库的二进制日志可能包含来自主库的事件（`server_id` 不同），因此事务可能跨实例。

关键知识点总结

复制基础要求：

唯一 server_id：防止数据冲突，确保事件正确标识。
TCP/IP 连接：主从必须通过网络通信，无法使用本地协议（如 Unix Socket）。
主库二进制日志：复制的数据源，记录所有数据变更事件。

多源复制的特殊性：

允许从库同时连接多个主库，打破了传统一主多从的限制。
需为每个主库配置独立的通道（CHANGE MASTER TO ... FOR CHANNEL 'channel_name'）。

安全与权限配置：

复制用户需 REPLICATION SLAVE 权限，而非表级权限。
建议使用加密连接（如 SSL）保护数据传输。

操作验证示例

-- 检查主库二进制日志状态  
SHOW VARIABLES LIKE 'log_bin';  

-- 查看实例 server_id  
SHOW VARIABLES LIKE 'server_id';  

-- 验证复制用户权限  
SHOW GRANTS FOR 'repl_user'@'%';

题目 76

The data in this instance is transient; no backup or replication will be required. It is currently under performing.

-- The database size is static and including indexes is 19G.

-- Total system memory is 32G.

After profiling the system, you highlight these MySQL status and global variables:

Com_rollback             	  	| 85408355 |
Com_commit                		| 1242342  |
Innodb_buffer_pool_pages_free 	| 163840 |

[mysqld]
buffer_pool_size=20G
innodb_flush_log_at_trx_commit=2
disable-log-bin

The OS metrics indicate that disk is a bottleneck. Other variables retain their default values.

Which two changes will provide the most benefit to the instance?

A. sync_binlog=0

B. buffer_pool_size=24G

C. innodb_flush_log_at_trx_commit=1

D. innodb_doublewrite=0

E. max_connections=10000

F. innodb_log_file_size=1G

正确答案

D. innodb_doublewrite=0

F. innodb_log_file_size=1G

关键解析

1. 选项 D（关闭双写机制）

作用：InnoDB 的双写机制（Double Write）通过将数据页写入两次（先写入双写缓冲区，再写入实际位置）来防止部分页写入（Partial Page Write）导致的数据损坏。然而，这会增加磁盘 I/O 操作。

优化依据：

当前场景中数据是临时的且无备份需求，可容忍一定风险。关闭双写机制（innodb_doublewrite=0）能减少约 50% 的磁盘写入量，显著缓解磁盘瓶颈。
禁用双写是解决磁盘I/O瓶颈的有效手段之一，尤其适用于非关键场景。

2. 选项 F（增大日志文件大小）

作用：增大 innodb_log_file_size 可减少日志文件切换频率和检查点（Checkpoint）的频率，从而降低磁盘 I/O 压力。

优化依据：

默认日志文件大小（通常为 48 MB 或更小）在高事务量场景中会导致频繁的日志轮转和磁盘刷写。增大到 1 G 后，事务日志可容纳更多变更，减少磁盘操作。
合理调整日志文件大小是优化InnoDB存储性能的核心策略之一，尤其适用于事务密集型场景。

错误选项排除原因

选项	排除原因
A. `sync_binlog=0`	由于已禁用二进制日志（`disable-log-bin`），此参数无意义，无法优化磁盘性能。
B. `buffer_pool_size=24G`	当前 Buffer Pool 已配置为 20 G（数据+索引仅 19 G），完全覆盖数据量，且系统总内存 32 G，剩余 12 G 可能用于 OS 缓存或其他进程。增大 Buffer Pool 反而可能引发内存争用。
C. `innodb_flush_log_at_trx_commit=1`	设为 1 会强制每次提交都刷盘，增加磁盘 I/O 负担，与当前磁盘瓶颈优化目标矛盾。保持设置值 2 更优。
E. `max_connections=10000`	高连接数设置与当前事务回滚率高（`Com_rollback`）、磁盘瓶颈的问题无关，反而可能因过多连接导致资源竞争。

补充技术细节

双写机制的影响：

关闭双写后，InnoDB 直接写入数据页，减少了双写缓冲区的两次写入操作，节省约 50% 的磁盘写入量。但需注意，此操作仅适用于可接受数据损坏风险的场景（如临时测试环境）。

日志文件大小的调整：

日志文件总大小为 innodb_log_file_size × innodb_log_files_in_group（默认 2 个文件）。设置为 1 G 后，总日志空间为 2 G，可减少因日志切换导致的磁盘 I/O 峰值。

事务回滚率分析：

Com_rollback 远高于 Com_commit（比例约 69:1），可能表明事务设计存在问题（如频繁失败的事务逻辑）。但此问题需从应用层优化，不属于本题配置调整范围。

操作建议

[mysqld]  
innodb_doublewrite = 0  
innodb_log_file_size = 1G

调整后需重启 MySQL 服务以生效，并监控磁盘 I/O 和事务稳定性。

题目 77

User fwuser@localhost is registered with the MySQL Enterprise Firewall and has been granted privileges for the SAKILA database.

Examine these commands that you executed and the results:

mysql> SELECT MODE FROM INFORMATION_SCHEMA.MYSQL_FIREWALL_USERS
WHERE USERHOST = 'fwuser@localhost' ;
+--------------+
| MODE         |
+--------------+
| PROTECTING   |
+--------------+

mysql> SELECT RULE FROM INFORMATION_SCHEMA.MYSQL_FIREWALL_WHITELIST
WHERE USERHOST = 'fwuser@localhost' ;
+---------------------------------------------------------------------------------------+
| RULE                                                                                  |
+---------------------------------------------------------------------------------------+
| SELECT `first_name`, `last_name` FROM `customer` WHERE `customer_id` = ?              |
| SELECT `get_customer_balance`(?, NOW())                                               |
| UPDATE `rental` SET `return_date` = NOW() WHERE `rental_id` = ?                       |
| SELECT @@version_comment LIMIT ?                                                      |
+---------------------------------------------------------------------------------------+

You then execute this command:

mysql> CALL mysql.sp_set_firewall_mode('fwuser@localhost' , 'RESET') ;

Which two are true?

A. The fwuser@localhost account is removed from the mysql.user table.

B. The information_schema.MYSQL_FIREWALL_WHITELIST table is truncated.

C. The whitelist of the fwuser@localhost account is truncated.

D. The mysql.firewall_users table is truncated.

E. The firewall resets all options to default values.

F. The fwuser@localhost account mode is set to DETECTING.

G. The fwuser@localhost account mode is set to OFF.

正确答案

C. The whitelist of the fwuser@localhost account is truncated.

G. The fwuser@localhost account mode is set to OFF.

关键解析

1. 选项 C 正确性分析

执行 CALL mysql.sp_set_firewall_mode('fwuser@localhost', 'RESET') 后，该账户的白名单（mysql.firewall_whitelist）会被清空。具体表现为：

白名单规则被完全删除：原白名单中的 4 条规则将被移除。
操作逻辑：RESET 模式专门用于清除账户的白名单内容，但不会影响其他账户或全局防火墙配置。

2. 选项 G 正确性分析

执行 RESET 操作后，账户的防火墙模式会自动从 PROTECTING 切换为 OFF。具体表现为：

模式变更：防火墙不再对该账户进行任何保护或监控，所有 SQL 语句均可执行，无论是否符合白名单规则。
数据同步：模式切换会触发防火墙将内存中的白名单规则同步到持久化存储（即 mysql.firewall_whitelist 表），但由于 RESET 操作，同步后表中对应账户的规则为空。

错误选项排除原因

选项	排除原因
A. 从 `mysql.user` 表删除账户	防火墙操作仅涉及白名单和模式设置，不会删除用户账户本身。
B. 清空 `MYSQL_FIREWALL_WHITELIST` 表	`RESET` 仅清除当前账户的白名单，不会截断整个表或其他账户的规则。
D. 清空 `mysql.firewall_users` 表	`mysql.firewall_users` 表记录账户模式，`RESET` 仅更新当前账户模式为 `OFF`，不会清空整张表。
E. 重置所有防火墙选项为默认	`RESET` 仅针对当前账户的白名单和模式，不会影响全局防火墙配置或其他账户。
F. 模式设为 `DETECTING`	`DETECTING` 是独立模式，需显式调用 `sp_set_firewall_mode` 设置，`RESET` 不会触发此变更。

补充说明

RESET 模式的实际作用：

清空白名单：mysql.firewall_whitelist 表中该账户的所有规则会被删除。
模式强制降级：无论之前处于何种模式（如 PROTECTING），执行后均变为 OFF，但账户仍保留在防火墙注册表中。

与 OFF 模式的区别：

RESET 模式：清空白名单 + 强制模式设为 OFF。
直接设为 OFF：仅关闭防火墙保护，白名单规则仍保留，未来可重新启用。

操作验证示例：

-- 查询防火墙模式  
SELECT MODE FROM INFORMATION_SCHEMA.MYSQL_FIREWALL_USERS  
WHERE USERHOST = 'fwuser@localhost';  
-- 结果应为 OFF  

-- 查询白名单  
SELECT RULE FROM INFORMATION_SCHEMA.MYSQL_FIREWALL_WHITELIST  
WHERE USERHOST = 'fwuser@localhost';  
-- 结果应为空

题目 78

Examine this statement and output:

mysql> SHOW GRANTS FOR jsmith;
+----------------------------------------------------------------+
| Grants for jsmith@%                                           |
+----------------------------------------------------------------+
| GRANT USAGE ON *.* TO 'jsmith'@'%'                            |
| GRANT UPDATE(Name) ON `world`.`country` TO 'jsmith'@'%'       |
+----------------------------------------------------------------+
2 rows in set (0.00 sec)

Which two SQL statements can jsmith execute?

A. UPDATE world.country SET Name=CONCAT ('New ' ,Name) ;

B. UPDATE world.country SET Name='one' LIMIT 1;

C. UPDATE world.country SET Name=' first ' ORDER BY Name LIMIT 1;

D. UPDATE world.country SET Name='all';

E. UPDATE world.country SET Name=' new' WHERE Name='old';

正确答案

B. UPDATE world.country SET Name='one' LIMIT 1;

D. UPDATE world.country SET Name='all';

关键解析

创建数据库和表：

[(none)]> select version();
+-----------+
| version() |
+-----------+
| 8.0.36    |
+-----------+
1 row in set (0.00 sec)

[(none)]> create database world;
Query OK, 1 row affected (0.01 sec)

[(none)]> use world;
Database changed

[world]> create table country(id int,name varchar(20));
Query OK, 0 rows affected (0.03 sec)

[world]> insert into country values(1,'tom');
Query OK, 1 row affected (0.01 sec)

[world]> select * from country;
+------+------+
| id   | name |
+------+------+
|    1 | tom  |
+------+------+
1 row in set (0.00 sec)

创建用户并授权：

[(none)]> CREATE USER 'jsmith'@'%' IDENTIFIED BY 'Abcd#1234';
Query OK, 0 rows affected (0.04 sec)

[(none)]> GRANT UPDATE(Name) ON world.country TO 'jsmith'@'%';
Query OK, 0 rows affected (0.01 sec)

[(none)]> SHOW GRANTS FOR jsmith;
+------------------------------------------------------------+
| Grants for jsmith@%                                        |
+------------------------------------------------------------+
| GRANT USAGE ON *.* TO `jsmith`@`%`                         |
| GRANT UPDATE (`Name`) ON `world`.`country` TO `jsmith`@`%` |
+------------------------------------------------------------+
2 rows in set (0.00 sec)

使用创建的用户登录：

[root@ZABBIX7T1 ~]# mysql -u jsmith -p

然后执行题目中的更新语句：

[(none)]> UPDATE world.country SET Name=CONCAT ('New ' ,Name) ;
ERROR 1143 (42000): SELECT command denied to user 'jsmith'@'localhost' for column 'Name' in table 'country'

[(none)]> UPDATE world.country SET Name='one' LIMIT 1;
Query OK, 1 row affected (0.01 sec)
Rows matched: 1  Changed: 1  Warnings: 0

[(none)]> UPDATE world.country SET Name=' first ' ORDER BY Name LIMIT 1;
ERROR 1143 (42000): SELECT command denied to user 'jsmith'@'localhost' for column 'Name' in table 'country'

[(none)]> UPDATE world.country SET Name='all';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

[(none)]> UPDATE world.country SET Name=' new' WHERE Name='old';
ERROR 1143 (42000): SELECT command denied to user 'jsmith'@'localhost' for column 'Name' in table 'country'

题目 79

There are five MySQL instances configured with a working group replication. Examine the output of the group members:

mysql> SELECT MEMBER_ID, MEMBER_STATE FROM performance_schema.replication_group_members;
+--------------------------------------+----------------+
| MEMBER_ID                            | MEMBER_STATE   |
+--------------------------------------+----------------+
| 1999b9fb-4aaf-11e6-bb54-28b2bd168d07 | UNREACHABLE    |
| 199b2df7-4aaf-11e6-bb16-28b2bd168d07 | ONLINE         |
| 199bb88e-4aaf-11e6-babe-28b2bd168d07 | ONLINE         |
| 19ab72fc-4aaf-11e6-bb51-28b2bd168d07 | UNREACHABLE    |
| 19b33846-4aaf-11e6-ba81-28b2bd168d07 | UNREACHABLE    |
+--------------------------------------+----------------+

Which two statements are true about network partitioning in the cluster?

A. The group replication will buffer the transactions on the online nodes until the unreachable nodes return online.

B. A manual intervention to force group members to be only the working two instances is required.

C. The cluster will shut down to preserve data consistency.

D. There could be both a 2 node and 3 node group replication still running, so shutting down group replication and diagnosing the issue is recommended.

E. The cluster has built-in high availability and updates group_replication_ip_whitelist to remove the unreachable nodes.

正确答案

B. A manual intervention to force group members to be only the working two instances is required.

D. There could be both a 2 node and 3 node group replication still running, so shutting down group replication and diagnosing the issue is recommended.

关键解析

根据题目中五节点 Group Replication 集群的输出，3 个节点处于 UNREACHABLE 状态，2 个节点处于 ONLINE 状态。以下是关键分析：

1. 选项 B 正确性分析

依据：

在 Group Replication 中，事务提交需要多数节点达成一致（即 N/2 + 1，五节点需至少 3 个节点在线）。当前仅 2 个节点在线，集群已失去法定票数（NO_QUORUM），无法提交新事务，只能提供只读服务。
此时需手动干预，例如通过 RESCAN 命令清理不可达节点，或重新配置集群成员，强制保留正常节点以恢复多数。

2. 选项 D 正确性分析

依据：

Group Replication 协议通过 Paxos 算法保证单一合法组存在，不会同时出现两个独立运行的子组。若网络分区导致节点分裂，仅多数节点组成的子组可继续运行，少数节点子组会自动停止服务。
题目中 3 个节点为 UNREACHABLE，但可能因网络问题导致存活节点误判（如 2 节点认为其他 3 节点不可达，而 3 节点可能仍在运行）。此时建议关闭集群并诊断网络问题，确保一致性。

错误选项排除原因

选项	排除原因
A. 在线节点会缓冲事务	Group Replication 在失去法定票数时会直接拒绝事务提交，而非缓冲等待。
C. 集群自动关闭	集群会进入 `NO_QUORUM` 状态，仅禁止写操作，不会自动关闭。
E. 自动更新白名单	白名单（如 `group_replication_ip_whitelist`）需手动配置，Group Replication 不会自动修改。

总结

B 和 D 正确：

B：失去法定票数时必须手动调整成员以恢复服务。
D：网络分区可能导致存活节点误判，需关闭并排查以避免潜在风险。

核心原则：Group Replication 依赖多数节点协议，网络问题需结合协议逻辑和手动干预解决。

题目 80

Which two statements are true about InnoDB data-at-rest encryption?

A. It supports all indexes transparently.

B. It decrypts data for use in memory.

C. It supports only non-blob datatypes.

D. It does not support the transportable tablespaces feature.

E. It enforces encryption from disk to memory and over network transmission.

正确答案

A. It supports all indexes transparently.

B. It decrypts data for use in memory.

关键解析

1. 选项 A 正确性分析

InnoDB 数据静态加密支持所有类型的索引（包括主键索引、辅助索引、全文索引等），且对应用完全透明。加密操作在存储层完成，索引结构不会因加密而改变，查询优化器也无需特殊处理。例如，加密后的索引页仍以 B+ 树结构存储，索引查询逻辑与未加密表完全一致。

2. 选项 B 正确性分析

InnoDB 加密的数据在从磁盘读取到内存时会被自动解密，内存中数据以明文形式处理，以确保查询性能不受影响。例如，执行 SELECT 语句时，加密的页首先被解密到内存缓冲池（Buffer Pool），后续操作均基于明文数据。

错误选项排除原因

选项	排除原因
C. 仅支持非 BLOB 数据类型	InnoDB 加密支持所有数据类型（包括 BLOB、TEXT 等），无任何限制。
D. 不支持可传输表空间	文件表空间（File-Per-Table）的加密表支持通过 `ALTER TABLE ... DISCARD/IMPORT TABLESPACE` 迁移。
E. 强制加密磁盘到内存及网络传输	内存中数据为明文，网络传输需通过 SSL/TLS 独立加密，并非数据静态加密的范畴。

核心特性总结

透明索引支持：加密不改变索引结构，所有查询逻辑与未加密表一致。
内存明文处理：数据在内存中解密以保证性能，但需依赖操作系统保护内存安全。
全数据类型兼容：支持包括 BLOB、JSON 在内的所有 MySQL 数据类型。
可迁移性：加密表空间支持跨实例迁移，需配合密钥管理插件。
网络传输独立性：静态加密仅保护磁盘数据，网络传输需额外启用 SSL/TLS。

扩展知识

密钥管理：InnoDB 采用双层密钥机制（主密钥 + 表空间密钥），支持通过 ALTER INSTANCE ROTATE MASTER KEY 轮换主密钥以提高安全性。
性能影响：加密操作引入的 CPU 开销通常为个位数百分比，且压缩（如 InnoDB 页压缩）在加密前执行以避免冗余。
合规性：符合 PCI-DSS 等标准对敏感数据（如信用卡号、医疗记录）的加密要求。

总结

通过以上分析可知，A 和 B 是正确的选项，其他选项均与 InnoDB 加密的实际实现相悖。

题目 81

Which three statements are true about MySQL Enterprise Firewall?

A. On Windows systems, it is controlled and managed using the Windows Internet Connection Firewall control panel.

B. System tables named firewall_users and firewall_whitelist in the mysql database provide persistent storage of firewall data.

C. It is available only in MySQL Enterprise versions.

D. It provides INFORMATION_SCHEMA tables that enable views into firewall data.

E. Firewall functionality is dependent on SHA-256 and ANSI-specific functions built in to the mysql.firewall table.

F. It shows only notifications for blocked connections, which originated outside of your network's primary domain.

正确答案

B. System tables named firewall_users and firewall_whitelist in the mysql database provide persistent storage of firewall data.

C. It is available only in MySQL Enterprise versions.

D. It provides INFORMATION_SCHEMA tables that enable views into firewall data.

关键解析

1. 选项 B 正确性分析

MySQL 企业防火墙的核心配置和规则信息存储在 mysql 数据库的系统表中。具体来说：

firewall_users：记录注册账户及其操作模式（如 RECORDING、PROTECTING）。
firewall_whitelist：存储账户的 SQL 模式白名单规则（即允许执行的 SQL 语句的规范化摘要形式）。

这些表通过持久化存储确保防火墙规则在服务器重启后仍然有效，符合选项 B 的描述。

2. 选项 C 正确性分析

MySQL 企业防火墙（MySQL Enterprise Firewall）是企业版（Enterprise Edition）的专属功能，社区版（Community Edition）不提供支持。这一限制与 MySQL 企业版的其他高级功能（如审计、线程池等）一致，属于商业授权特性。

3. 选项 D 正确性分析

防火墙通过 INFORMATION_SCHEMA 下的表提供运行时数据的可见性，例如：

INFORMATION_SCHEMA.MYSQL_FIREWALL_USERS：展示已注册账户及其当前模式。
INFORMATION_SCHEMA.MYSQL_FIREWALL_WHITELIST：显示白名单规则。

这些表允许管理员无需直接查询系统表即可监控防火墙状态，符合选项 D 的描述。

错误选项排除原因

选项	排除原因
A	MySQL 企业防火墙是服务器内置功能，不依赖操作系统防火墙（如 Windows 防火墙）管理。
E	防火墙功能基于 SQL 语句的规范化摘要（digest）和规则匹配，与 SHA-256 或 ANSI 函数无关。
F	防火墙会记录所有被拒绝的 SQL 语句（无论来源），并在 `DETECTING` 模式下记录可疑语句到错误日志，无网络域限制。

核心特性总结

持久化存储：通过系统表 firewall_users 和 firewall_whitelist 实现配置的持久化。
企业版专属：仅限 MySQL 企业版用户使用，需商业授权。
运行时可见性：通过 INFORMATION_SCHEMA 表提供实时监控接口。
模式驱动：支持 RECORDING（训练）、PROTECTING（保护）、DETECTING（检测）等操作模式，灵活适应不同安全需求。

扩展说明

防火墙工作流程：
- 训练阶段（RECORDING）：记录合法 SQL 语句的摘要，形成白名单规则。
- 保护阶段（PROTECTING）：仅允许匹配白名单的 SQL 执行，拒绝其他语句并记录。
- 检测阶段（DETECTING）：记录可疑语句但不阻止执行，用于灰度监控。
性能影响：在 PROTECTING 模式下，防火墙的规则匹配会引入额外开销，但通过规范化摘要优化后可降低性能损耗。

操作建议

启用防火墙：通过 INSTALL PLUGIN 加载插件，并设置 mysql_firewall_mode=ON。
配置账户规则：使用存储过程 mysql.sp_set_firewall_mode() 为账户分配模式。
定期审计：结合 INFORMATION_SCHEMA 表和白名单规则调整，优化安全策略。

通过以上分析，B、C、D 是正确的选项。

题目 82

Which two storage engines provide a view of the data consistent with the storage system at any moment?

A. InnoDB

B. ARCHIVE

C. MyISAM

D. MEMORY

E. NDB

正确答案

A. InnoDB

E. NDB (NDB Cluster)

关键解析

1. InnoDB（选项 A）

InnoDB 是 MySQL 的默认存储引擎，通过多版本并发控制（MVCC）提供事务支持，确保数据一致性视图。具体机制包括：

事务隔离级别：支持可重复读（默认级别）和串行化等高隔离级别，避免脏读、不可重复读和幻读。
行级锁与 MVCC：通过行级锁和版本控制，不同事务可以看到数据的不同版本，从而在并发操作中维护一致性视图。
崩溃恢复：依赖重做日志（Redo Log）和回滚日志（Undo Log）保证数据持久性和原子性，崩溃后能恢复到一致性状态。

2. NDB（选项 E）

NDB（NDB Cluster）是 MySQL 的分布式存储引擎，专为高可用性和一致性设计，其核心特性包括：

同步复制：数据分片存储在不同节点，并通过同步复制保证所有节点数据一致。事务提交需在所有节点确认，确保全局一致性。
分布式事务管理：采用悲观锁和全局检查点机制（GCP），确保事务的原子性和隔离性，避免网络分区导致的数据不一致。
自动故障恢复：节点故障时自动切换副本，通过事务日志和版本控制恢复数据一致性。

错误选项排除原因

选项	排除原因
B. ARCHIVE	仅支持插入和查询，不支持事务和行级锁，无法保证实时一致性。
C. MyISAM	无事务支持，仅使用表级锁，崩溃后易导致数据不一致。
D. MEMORY	数据存储在内存中，重启后丢失，且不支持事务和持久性，无法维护一致性视图。

总结

InnoDB 和 NDB 是唯一支持事务且能提供数据一致性视图的存储引擎。
InnoDB 适用于单机高并发场景，NDB 则专为分布式集群设计，两者均通过严格的并发控制和恢复机制保障数据一致性。

题目 83

Which three are requirements for a secure MySQL Server environment?

A. Minimize the number of non-MySQL Server-related processes running on the server host.

B. Restrict the number of OS users that have access at the OS level.

C. Ensure appropriate file system privileges for OS users and groups.

D. Keep the entire software stack on one OS host.

E. Encrypt the file system to avoid needing exact file-system permissions.

F. Run MySQL server as the root user to prevent incorrect sudo settings.

正确答案

B. Restrict the number of OS users that have access at the OS level.

C. Ensure appropriate file system privileges for OS users and groups.

D. Keep the entire software stack on one OS host.

关键解析

1. 选项 B 正确性分析

在安全环境中，限制操作系统用户数量是基本原则。通过减少有权限访问服务器主机的用户，可以降低未授权操作或内部攻击的风险。例如，仅允许数据库管理员和必要的运维人员通过最小权限账户访问系统。

2. 选项 C 正确性分析

文件系统权限是防止数据泄露的关键。MySQL 数据目录、日志文件及配置文件需严格限制为仅允许 MySQL 服务账户和特定用户组访问（如 mysql:mysql 用户组），避免其他用户读取敏感信息。例如，chmod 750 /var/lib/mysql 可确保目录权限合理。

3. 选项 D 正确性分析

集中部署软件栈能简化安全管理并减少攻击面。例如，将 Web 应用、数据库和中间件部署在同一主机（如 LAMP 栈）可避免跨主机的配置漏洞和网络攻击。

错误选项排除原因

选项	排除原因
A	非 MySQL 进程的减少虽能优化性能，但并非安全必需。例如，监控工具（如 Zabbix）可能需额外进程支持，只要权限受控即可。
E	文件系统加密（如 LUKS）虽能增强数据保护，但不能替代权限管理。加密需结合权限控制，且并非所有场景都需要加密。
F	以 `root` 运行 MySQL 违反最小权限原则，会扩大攻击影响。应使用专用低权限账户（如 `mysql` 用户）运行服务。

补充安全实践建议

启用防火墙与网络隔离：仅开放 MySQL 必要端口（如 3306），并结合白名单限制访问来源。
定期审计与更新：通过工具（如 Percona Toolkit）检查配置漏洞，及时应用安全补丁。
备份与恢复策略：加密备份文件并存储于隔离环境，防止数据丢失或被篡改。

通过以上分析，B、C、D 是正确的选项，符合 MySQL 安全环境的核心要求。

题目 84

Examine this list of MySQL data directory binary logs:

binlog.000001
binlog.000002
. . . . . . .
binlog.000289
binlog.000300
binlog.000301
binlog.index

Now examine this command, which executes successfully:

mysqldump --delete-master-logs --all-databases > /backup/db_backup.sql

Which two are true?

A. All databases are backed up to the output file.

B. All non-active binary logs are removed from the master.

C. All binary logs are backed up and then deleted.

D. All binary logs are deleted from the master.

E. All databases, excluding master metadata, are backed up to the output file.

F. All details regarding deleted logs and master metadata are captured in the output file.

正确答案

A. All databases are backed up to the output file.

B. All non-active binary logs are removed from the master.

解析解析

1. 选项 A 正确性分析

--all-databases 参数会备份所有数据库，包括系统库（如 mysql），并将结构和数据写入 /backup/db_backup.sql 文件。

2. 选项 B 正确性分析

--delete-master-logs 的作用是删除非活跃的二进制日志（已归档且未被复制依赖的日志）。例如：

若当前活跃日志为 binlog.000301，则 binlog.000001 到 binlog.000300 会被清除。
活跃日志（如 binlog.000301）不会被删除，以确保复制连续性。

错误选项排除原因

选项	排除原因
C	`mysqldump` 仅备份数据库数据，不涉及二进制日志的备份。
D	仅非活跃日志被删除，活跃日志保留。
E	`--all-databases` 包含主库元数据（如 `mysql` 库）。
F	输出文件仅包含数据库数据，无日志删除记录或元数据详情。

补充说明

安全风险：在生产环境中，直接使用 --delete-master-logs 可能导致从库复制中断。建议先通过 SHOW SLAVE STATUS 确认从库进度，或改用 PURGE BINARY LOGS BEFORE 按时间点删除。
备份策略优化：结合 --single-transaction 和 --master-data=2 可生成一致性备份并记录二进制日志位置，便于增量恢复。

通过以上分析，A 和 B 是正确的选项，其他选项均与 mysqldump 的实际行为相悖。

题目 85

You want to install and configure MySQL on Linux server with tarball binaries in the /app/mysql/ directory, where the bin directory is found at /app/mysql/bin and the data directory at /app/data. Which two parameters are required to configure the MySQL instance?

A. The configuration log-bin=/app/data is needed.

B. The configuration datadir=/app/mysql/data is needed.

C. The configuration basedir=/app/mysql/bin is needed.

D. The configuration basedir=/app/mysql is needed.

E. The configuration innodb_log_group_ome_dir=/datadir is needed.

F. The configuration datadir=/app/data is needed.

正确答案

D. The configuration basedir=/app/mysql is needed.

F. The configuration datadir=/app/data is needed.

关键解析

1. 选项 D 正确性分析

basedir 参数需指向 MySQL 的安装根目录，即包含 bin、lib、support-files 等子目录的父目录。根据题目描述，bin 目录位于 /app/mysql/bin，因此根目录应为 /app/mysql。

2. 选项 F 正确性分析

datadir 参数用于定义数据存储目录。题目要求数据目录为 /app/data，因此需配置 datadir=/app/data。

错误选项排除原因

选项	排除原因
B. `datadir=/app/mysql/data`	题目要求数据目录为 `/app/data`，而非 `/app/mysql/data`。
C. `basedir=/app/mysql/bin`	`basedir` 应指向安装根目录（如 `/app/mysql`），而非 `bin` 子目录。
A. `log-bin=/app/data`	`log-bin` 用于二进制日志路径，非必需参数，且默认与 `datadir` 一致。
E. `innodb_log_group_home_dir=/datadir`	InnoDB 日志组目录默认与 `datadir` 一致，无需单独配置。

配置示例

在 my.cnf 中添加以下配置以满足题目要求：

[mysqld]
basedir = /app/mysql    # 指向安装根目录（选项D）
datadir = /app/data     # 指向数据目录（选项F）

验证步骤：

启动 MySQL 后执行 SHOW VARIABLES LIKE 'basedir'; 和 SHOW VARIABLES LIKE 'datadir'; 确认路径正确。
检查 /app/data 目录是否包含 mysql、sys 等系统库文件。

扩展说明

权限设置：需确保 /app/data 目录的所有者为 mysql 用户，并设置权限为 750：

chown -R mysql:mysql /app/data
chmod -R 750 /app/data

初始化要求：在首次启动前，需通过 mysqld --initialize 或 --initialize-insecure 初始化数据目录，并记录临时密码（若启用安全模式）。
服务配置：建议编写 systemd 服务文件，确保服务启动时加载正确的路径参数。

通过以上分析，D 和 F 是正确的选项，符合MySQL二进制包安装的核心配置要求。

题目 86

A valid raw backup of the shop.customers MyISAM table was taken. You must restore the table.

Confirm that secure_file_priv= '/var/tmp '
mysql> DROP TABLE shop.customers;
shell> cp /backup/customers.MY* /var/lib/mysql/shop/

Which two actions are required to complete the restore?

A. shell> cp /backup/customers.sdi /var/tmp

B. mysql> SOURCE '/var/tmp/customers.sdi

C. shell> cp /backup/customers.sdi /var/lib/mysql/shop/

D. mysql> ALTER TABLE shop.customers DISCARD TABLESPACE

E. shell> cp /backup/customers.frm /var/lib/mysql/shop/

F. mysql> IMPORT TABLE FROM /var/lib/mysql/shop/customers.sdi

G. mysql> IMPORT TABLE FROM /var/tmp/customers.sdi

H. mysql> ALTER TABLE shop.customers IMPORT TABLESPACE

正确答案

A. shell> cp /backup/customers.sdi /var/tmp

G. mysql> IMPORT TABLE FROM /var/tmp/customers.sdi

关键解析

1. 选项 A 正确性分析

MyISAM 表在 MySQL 8 中引入元数据文件（.sdi）用于表结构定义。secure_file_priv 参数限制文件导入/导出的路径为 /var/tmp（步骤 1 已确认）。因此，需将 .sdi 文件复制到该目录，否则 MySQL 无法通过 IMPORT TABLE 读取文件。

操作必要性：若 .sdi 未复制到 secure_file_priv 指定路径，IMPORT TABLE 会因权限限制失败。

2. 选项 G 正确性分析

.sdi 文件包含表结构元数据，需通过 IMPORT TABLE 命令将表结构重新注册到 MySQL 元数据系统。此命令会解析 .sdi 文件并重建表定义。

操作必要性：仅复制 .MYD 和 .MYI 文件（步骤 3）不足以恢复表结构，必须通过 .sdi 文件重建表定义。

错误选项排除原因

选项	排除原因
C. `cp /backup/customers.sdi /var/lib/mysql/shop/`	`.sdi` 文件需放在 `secure_file_priv` 指定路径（`/var/tmp`），而非数据目录。直接拷贝到数据目录会导致 `IMPORT TABLE` 命令无法识别。
E. `cp customers.frm`	MySQL 8 中 MyISAM 表使用 `.sdi` 替代 `.frm` 文件存储元数据，`.frm` 文件已不再适用。
D/H. `DISCARD/IMPORT TABLESPACE`	这些命令仅适用于 InnoDB 表，与 MyISAM 恢复无关。
F. `IMPORT FROM /var/lib/mysql/shop/customers.sdi`	`secure_file_priv` 限制导入路径为 `/var/tmp`，直接引用数据目录路径会触发权限错误。

完整恢复流程总结

复制数据文件：

已执行 cp /backup/customers.MY* /var/lib/mysql/shop/（步骤 3），恢复 .MYD（数据）和 .MYI（索引）文件。

处理表结构文件：
- A. 复制 .sdi 到安全目录：cp /backup/customers.sdi /var/tmp。
- G. 导入表结构：IMPORT TABLE FROM '/var/tmp/customers.sdi'。
验证恢复：

执行 SHOW TABLES 确认表存在，并通过 SELECT 验证数据完整性。

扩展说明

.sdi 文件的作用：
- MySQL 8 将表结构元数据从 .frm 迁移至 .sdi（Serialized Dictionary Information），支持 JSON 格式存储，便于跨版本兼容性和维护。
权限与路径限制：
- secure_file_priv 是安全机制，防止未授权文件操作。恢复时需严格遵循其路径限制，否则会触发错误 ERROR 1290。
MyISAM 与 InnoDB 恢复差异：
- MyISAM 依赖物理文件直接恢复，而 InnoDB 需通过事务日志或 TABLESPACE 操作。

通过以上分析，A 和 G 是正确的操作，符合 MySQL 8 中 MyISAM 表恢复的规范流程。

题目 87

You are investigating performance problems in a MySQL database; all data fits in memory. You determine that SELECT queries to one table is the main cause for poor response times.

Which two have the biggest potential for eliminating the problem?

A. high concurrency

B. operating system resources

C. column definitions

D. innodb mutexes

E. non-transaction storage engine

F. table indexes

正确答案

C. column definitions

F. table indexes

关键解析

1. 列定义（选项 C）

列的数据类型和设计直接影响索引效率和存储性能。

数据类型选择与存储优化：使用紧凑的数据类型（如 INT 替代 VARCHAR 存储数值）可减少内存占用，提升索引扫描速度。例如，整数类型的比较效率远高于字符串，且索引更紧凑。
避免索引失效的场景：若列定义不合理（如对字符串列使用函数操作），即使存在索引也可能失效。例如，WHERE UPPER(username) = 'JOHN' 会导致索引无法使用。
字段长度与碎片控制：过长的字段（如 TEXT）会占用更多内存，且可能导致索引碎片化。合理限制字段长度（如 VARCHAR(255) 替代 TEXT）能提升内存利用率。

2. 表索引（选项 F）

索引优化是提升 SELECT 查询性能的核心手段。

索引缺失或设计不当会导致全表扫描：即使数据全在内存中，缺乏索引的查询仍需逐行扫描所有数据，响应时间会随数据量线性增长。例如，若 WHERE 条件未命中索引，查询会遍历整个表，导致性能急剧下降。
覆盖索引与复合索引的优化：合理设计索引（如覆盖索引、复合索引的最左前缀匹配）可减少回表操作，直接通过索引完成数据检索。例如，在频繁查询的列上建立复合索引，能显著减少磁盘 I/O 和内存计算量。
索引维护的影响：动态维护索引虽然会增加写入开销，但对以读为主的场景，索引带来的查询性能提升远大于维护成本。

错误选项排除原因

选项	排除原因
A. 高并发	高并发可能导致锁竞争，但根本问题在于查询本身的效率。若索引和列定义优化到位，单个查询的快速响应能缓解并发压力。
B. 操作系统资源	数据已全在内存中，I/O 和 CPU 竞争并非主要瓶颈，性能问题更可能源自查询逻辑或数据结构设计。
D. InnoDB 互斥锁	InnoDB 的互斥锁争用通常出现在写密集场景，而 SELECT 查询的瓶颈更可能由索引缺失或全表扫描导致。
E. 非事务存储引擎	非事务引擎（如 MyISAM）的表级锁可能影响并发读，但问题描述未明确存储引擎类型，且 InnoDB 的优化空间更大（如行级锁、MVCC）。

补充优化建议

使用 EXPLAIN 分析执行计划：通过 EXPLAIN 确认查询是否命中索引，优化访问类型（如从 ALL 提升至 ref 或 range）。
避免 SELECT *：仅选择必要列，减少数据传输和内存占用。例如，SELECT id, name 替代 SELECT *。
分页查询优化：使用 WHERE id > last_id LIMIT n 替代 OFFSET，避免全表扫描分页。
统计信息维护：定期执行 ANALYZE TABLE 更新统计信息，帮助优化器选择更优的执行计划。

通过优化索引和列定义，可以显著降低查询的复杂度与资源消耗，从根本上解决性能问题。

题目 88

You have semi-synchronous replication configured and working with one slave.

rpl_semi_sync_master_timeout has never been reached.

You find that the disk system on the master has failed and as a result, the data on the master is completely unrecoverable.

Which two statements are true?

A. The slave automatically identifies that the master is unreachable and performs any required actions so that applications can start using the slave as the new master.

B. Reads from the slave can return outdated data until the value of the rpl_semi_sync_master_timeout variable is reached.

C. No committed transactions are lost.

D. Reads from the slave can return outdated data for some time, until it applies all transactions from its relay log.

E. A small amount of committed transactions may be lost in case they were committed just before the disk failure.

F. As soon as the incident happens, application can read data from the slave and rely on it to return a full and current set of data.

正确答案

C. No committed transactions are lost.

D. Reads from the slave can return outdated data for some time, until it applies all transactions from its relay log.

关键解析

1. 选项 C 正确性分析

在半同步复制模式下（假设使用默认的 AFTER_SYNC 模式）：

主库在提交事务前必须等待从库的 ACK 确认：主库将事务写入二进制日志（binlog）并同步到磁盘后，会等待至少一个从库接收并写入中继日志（Relay Log）的确认信号，之后才向客户端返回提交成功。这意味着所有在主库上确认提交的事务，从库已确保接收并持久化到中继日志中。
即使主库磁盘完全损坏，从库的中继日志已包含所有主库已提交的事务。因此，不会丢失任何已提交的事务（选项 C 正确）。

2. 选项 D 正确性分析

从库的数据一致性依赖于中继日志的应用进度：

中继日志的接收与执行是异步的：从库的 I/O 线程负责接收中继日志，而 SQL 线程负责解析和执行这些日志中的事务。若主库崩溃时，从库的中继日志可能尚未完全执行完毕（即存在未应用的 Relay Log），此时从库的数据可能暂时落后于原主库的提交状态。
读取过时数据的窗口期：在SQL线程完成所有中继日志的执行前，从库的查询可能返回未更新的数据（选项 D 正确）。

错误选项排除原因

选项	排除原因
A	MySQL 原生半同步复制不提供自动故障转移功能。需依赖外部工具（如 Orchestrator 或 MHA）实现主从切换，而非自动触发。
B	`rpl_semi_sync_master_timeout` 从未触发，说明主库在崩溃前始终能收到从库的 ACK 确认，因此不存在因超时导致的读取延迟。
E	在 `AFTER_SYNC` 模式下，主库仅在从库确认接收事务后才提交，因此已提交的事务必然已被从库接收，不会因主库崩溃而丢失（选项 E 错误）。
F	从库需完成中继日志的执行才能保证数据最新，崩溃发生时可能仍有未执行的事务，因此无法立即提供完整的最新数据（选项 F 错误）。

补充说明

半同步复制的两种模式：
- AFTER_COMMIT（旧模式）：主库先提交事务再等待 ACK。若主库在提交后崩溃，可能导致客户端已确认的事务未同步到从库（存在数据丢失风险）。
- AFTER_SYNC（MySQL 5.7+ 默认模式）：主库等待 ACK 后才提交事务，彻底避免已提交事务的丢失（本题默认场景）。
恢复建议：
- 若主库磁盘不可恢复，应将从库提升为新主库，并重新配置其他节点同步至新主库。
- 使用工具（如 pt-table-checksum）验证主从数据一致性。

通过以上分析，C 和 D 是正确的选项，符合半同步复制的核心机制与故障场景下的行为逻辑。

题目 89

You are considering using file-system snapshots to back up MySQL.

Which three statements are true?

A. There is a slight performance cost while the snapshot is active.

B. The backup window is almost zero from the perspective of the application.

C. They allow direct copying of table rows with operating system copy commands.

D. They do not back up views, stored procedures, or configuration files.

E. They take roughly twice as long as logical backups.

F. They work best for transaction storage engines that can perform their own recovery when restored.

G. They do not use additional disk space.

正确答案

A. There is a slight performance cost while the snapshot is active.

B. The backup window is almost zero from the perspective of the application.

F. They work best for transaction storage engines that can perform their own recovery when restored.

关键解析

1. 选项 A 正确性分析

文件系统快照基于写时复制（Copy-on-Write）机制，当快照激活时，原始卷的写操作需先复制旧数据块到快照空间，这会增加 I/O 操作和存储元数据的管理开销，导致轻微的性能下降。例如，LVM 快照在数据频繁修改时，写操作的延迟会上升，尤其在高并发场景下更为明显。

2. 选项 B 正确性分析

文件系统快照的创建几乎是瞬时完成的，仅复制元数据而非全量数据，因此对应用程序的访问几乎无阻塞。例如，使用 LVM 快照备份 InnoDB 表时，数据库无需关闭，应用程序可继续读写。此特性使其适用于对业务连续性要求高的场景。

3. 选项 F 正确性分析

事务型存储引擎（如 InnoDB）支持崩溃恢复机制，在快照恢复时可通过重做日志（Redo Log）自动修复数据一致性。例如，即使快照期间存在未提交事务，InnoDB 在恢复时会回滚未完成的事务，并应用已提交的事务日志，确保数据完整。而非事务引擎（如 MyISAM）因缺乏此类机制，快照恢复后可能需要额外校验。

错误选项排除原因

选项	排除原因
C	文件系统快照备份的是物理文件（如 `.ibd`、`.MYD` 等），无法直接通过 OS 命令复制单表行数据。表行的逻辑备份需依赖 `mysqldump` 等工具。
D	快照备份涵盖数据目录下的所有文件，包括视图、存储过程（存储在 `mysql.proc` 表）及配置文件（如 `my.cnf` 若在数据目录中）。
E	物理快照的备份速度远快于逻辑备份（如 `mysqldump`），因后者需逐行生成 SQL 语句，而快照仅需文件系统级复制。
G	快照初始占用空间小，但后续数据修改会逐渐占用额外空间（存储旧数据块），若修改频繁可能导致快照空间耗尽。

补充说明

快照适用场景：
- 在线备份：支持事务引擎的数据库（如InnoDB）可在不中断服务的情况下完成备份。
- 快速恢复：直接挂载快照文件至数据目录即可恢复，无需逐行导入数据。
- 增量备份：结合二进制日志（Binlog）可实现时间点恢复（Point-in-Time Recovery）。
最佳实践：
- 定期清理快照：避免快照空间耗尽导致备份失败。
- 结合逻辑备份：物理快照 + 逻辑导出（如 mysqldump）可兼顾速度与灵活性。
- 验证一致性：恢复后执行 CHECK TABLE 或 mysqlcheck 确保数据完整性。

通过以上分析，A、B、F 是正确的选项，符合文件系统快照备份的核心特性与应用场景。

题目 90

Which two commands will display indexes on the parts table in the manufacturing schema?

A. EXPLAIN SELECT INDEXES FROM manufacturing.parts;

B. SELECT * FROM information_schema.statistics WHERE table_schema= 'manufacturing' AND TABLE_NAME= 'parts' ;

C. DESCRIBE manufacturing.parts;

D. SHOW INDEXES FROM manufacturing.parts;

E. SELECT * FROM information_schema.COLUMN_STATISTICS;

正确答案

B. SELECT * FROM information_schema.statistics WHERE table_schema='manufacturing' AND TABLE_NAME='parts';

D. SHOW INDEXES FROM manufacturing.parts;

关键解析

1. 选项 B 正确性分析

information_schema.statistics 表存储了所有索引的元数据，包括索引名称、列名、唯一性、排序方式等。通过以下查询可精准获取 manufacturing.parts 表的索引信息：

SELECT * FROM information_schema.statistics  
WHERE table_schema = 'manufacturing' AND table_name = 'parts';

输出内容：索引名称（INDEX_NAME）、索引类型（INDEX_TYPE）、关联列（COLUMN_NAME）、是否唯一（NON_UNIQUE）等。
适用场景：需要编程化或详细分析索引结构的场景。

2. 选项 D 正确性分析

SHOW INDEXES 是 MySQL 原生命令，直接返回表的索引信息：

SHOW INDEXES FROM manufacturing.parts;

输出内容：与 information_schema.statistics 类似，但以表格形式展示，更直观。
适用场景：快速交互式查看索引信息。

错误选项排除原因

选项	排除原因
A. `EXPLAIN SELECT INDEXES ...`	`SELECT INDEXES` 是无效语法。`EXPLAIN` 需配合实际查询语句（如 `EXPLAIN SELECT * FROM parts`），无法直接显示索引元数据。
C. `DESCRIBE manufacturing.parts`	`DESCRIBE` 或 `SHOW COLUMNS` 仅显示表字段定义（如列名、类型、键约束），不包含索引详细信息。
E. `SELECT * FROM information_schema.COLUMN_STATISTICS`	`COLUMN_STATISTICS` 存储列的统计信息（如直方图），与索引无关。

扩展说明

索引元数据存储逻辑：

MySQL 将索引信息持久化在系统表（如 mysql.innodb_index_stats 和 mysql.innodb_table_stats）中，并通过 information_schema 提供标准化视图。
SHOW INDEXES 命令是对这些底层表的封装，提供用户友好的输出。

索引优化建议：

结合 SHOW INDEXES 和 EXPLAIN 分析查询执行计划，验证索引是否被有效利用。
定期检查冗余索引（如重复的复合索引前缀），使用 DROP INDEX 清理无效索引以节省存储和优化写入性能。

通过以上分析，B 和 D 是正确的选项，符合 MySQL 索引查看的标准方法。

题目 91

On examination, your MySQL installation datadir has become recursively world read/write/executable.

What are two major concerns of running an installation with incorrect file privileges?

A. Extra startup time would be required for the MySQL server to reset the privileges.

B. MySQL binaries could be damaged, deleted, or altered.

C. SQL injections could be used to insert bad data into the database.

D. Data files could be deleted.

E. Users could overwrite configuration files.

正确答案

B. MySQL binaries could be damaged, deleted, or altered.

D. Data files could be deleted.

关键解析

1. 选项 B 正确性分析

当 datadir 的权限被递归设置为全局可读、可写、可执行时，MySQL的可执行文件或相关二进制文件可能被破坏、删除或篡改。

文件损坏风险：任何用户都可以直接修改或替换数据目录中的文件（如 .ibd、.MYD 等），导致数据损坏或服务崩溃。
安全漏洞：恶意用户可能通过覆盖二进制文件植入后门，进一步控制数据库或服务器。

2. 选项 D 正确性分析

数据文件可能被意外或恶意删除，这是权限错误最直接的风险：

全局写权限的威胁：任何用户均可通过 rm 命令删除 datadir 下的数据文件（如 .frm、.ibd），导致数据丢失或服务不可用。
生产环境灾难：删除关键文件（如 ibdata1）会导致数据库无法启动，恢复成本极高。

错误选项排除原因

选项	排除原因
A	MySQL 启动时不会自动修复文件权限，需手动调整。权限错误不会导致启动时间显著增加。
C	SQL 注入与应用程序代码漏洞相关，与文件系统权限无关。
E	配置文件（如 `my.cnf`）通常不在 `datadir` 中，且题目仅针对 `datadir` 的权限问题。

补充说明

权限最佳实践：
- datadir 应设为 0700，仅允许 MySQL 进程用户访问，防止未授权操作。
- 定期检查权限设置，结合工具（如 auditd）监控关键目录的访问行为。
恢复建议：
- 若数据文件被删除，需从备份恢复，并验证备份的完整性和权限设置。
- 使用 chown 和 chmod 修正权限，例如：

chown -R mysql:mysql /var/lib/mysql  
chmod -R 0700 /var/lib/mysql

通过以上分析，B 和 D 是正确的选项，反映了 datadir 权限错误的主要安全风险。

题目 92

Which three requirements must be enabled for group replication?

A. replication filters

B. semi-sync replication plugin

C. slave updates logging

D. binary log checksum

E. primary key or primary key equivalent on every table

F. binary log MIXED format

G. binary log ROW format

正确答案

C. slave updates logging

E. primary key or primary key equivalent on every table

G. binary log ROW format

关键解析

1. 选项 C 正确性分析

从库更新日志（log_slave_updates）必须启用。

作用：此参数确保从库接收到的变更会写入自身的二进制日志，保证组内所有节点的事务传播一致性。

2. 选项 E 正确性分析

每个表必须包含主键或等效主键。

原因：主键用于冲突检测和事务一致性验证，确保分布式事务的原子性。

3. 选项 G 正确性分析

二进制日志必须使用 ROW 格式。

原因：ROW 格式记录行级变更，而非语句逻辑，避免因函数调用或非确定性操作导致数据不一致。

错误选项排除原因

选项	排除原因
A. 复制过滤器	Group Replication 不支持复制过滤器，因它会破坏事务全局一致性。
B. 半同步插件	半同步复制与 Group Replication 无直接关联，后者基于 Paxos 协议而非半同步机制。
D. 二进制日志校验和	Group Replication 要求 `binlog_checksum = NONE`，以避免校验和干扰事务传播。
F. MIXED 格式	MIXED 格式可能导致非确定性操作，与 Group Replication 强一致性冲突。

技术总结

核心依赖：

二进制日志的 ROW 格式（G）是 Group Replication 的基石，确保事务变更的精确记录。
主键约束（E）通过唯一标识行数据，支撑分布式事务的冲突检测和一致性验证。
从库更新日志（C）保证事务在组内全节点传播，维持数据同步逻辑的闭环。

配置实践：
- 在 my.cnf 中明确设置 binlog_format = ROW、log_slave_updates = ON，并禁用非必要存储引擎（如 MyISAM）。
- 对于无主键的表，需通过 ALTER TABLE 添加主键或唯一索引以满足要求。
性能与扩展性：
- ROW 格式可能增加日志体积，需结合 binlog_row_image = MINIMAL 优化存储。
- 主键设计需避免热点写入，例如使用分布式 ID 生成策略（如 Snowflake 算法）。

题目 93

You are attempting to start your mysqld.

Examine this log output:

2019-12-12T22:21:40:353800z 0 System DCY-010116 Server /mysql/bin/mysqld mysld 8.0.18-comnercial starting as process 29740
2019-12-12T22:21:40:458802z 1 ERROR DCY-012592 InnoDB Operating system error number 2 in a file operation.
2019-12-12T22:21:40:459259z 1 ERROR DCY-012593 InnoDB The error means the system cannot find the patj specified.
2019-12-12T22:21:40:459423z 1 ERROR DCY-012594 InnoDB If you are installing InnoDB,remember that must create directories yourself,InnoDB does not create them.
2019-12-12T22:21:40:459606z 1 ERROR DCY-012646 InnoDB File ./ibdatali ‘open’ returned os error 71.Cannot continue operation.
2019-12-12T22:21:40:459891z 1 ERROR DCY-012981 InnoDB Cannot continue operation.

Which two things must you check?

A. the configuration file for correct datadir setting

B. that you are using the correct version of MySQL

C. that the TLS/SSL certificates are still valid

D. for the possibility that the files are locked by another process

E. for the presence of the missing files in other locations

F. that the user attempting to connect to the database is using the correct username and password

正确答案

A. the configuration file for correct datadir setting

E. for the presence of the missing files in other locations

关键解析

1. 选项 A 正确性分析

错误日志中明确提到 InnoDB Operating system error number 2 和 cannot find the path specified，这表明数据目录路径配置错误。

配置文件（如 my.cnf 或 my.ini）中的 datadir 参数必须指向正确的目录。若路径不匹配或目录不存在，InnoDB 无法访问数据文件（如 ibdata1、ib_logfile*），导致启动失败。
操作建议：
- 使用 SHOW VARIABLES LIKE 'datadir'; 验证当前配置。
- 检查配置文件中的 datadir 是否与实际路径一致，并确保目录存在且权限正确。

2. 选项 E 正确性分析

错误 os error 71 表示文件系统路径不可达或文件缺失。需检查以下可能性：

数据文件被误删或移动：例如 ibdata1 可能被移动到其他位置，或备份文件未正确还原。
表空间文件（.ibd）的孤立问题：若表空间文件被迁移但未更新元数据，InnoDB 会尝试访问无效路径。
操作建议：
- 使用 SHOW TABLES 结合 INFORMATION_SCHEMA 检查表空间文件路径。
- 若文件被移动，可通过 ALTER TABLE ... DISCARD/IMPORT TABLESPACE 重新关联。

错误选项排除原因

选项	排除原因
B	错误与版本无关，日志未提示兼容性问题。
C	TLS/SSL 证书问题会导致连接错误，而非启动阶段的文件路径问题。
D	文件锁定通常表现为 `error number 11`（资源忙），而非 `error 2` 或 `71`。
F	用户名/密码错误影响连接认证，与启动时的文件访问无关。

补充说明

关键操作步骤：
- 修正 datadir：
  - 在配置文件中将 datadir 调整为正确的绝对路径（如 /var/lib/mysql）。
  - 重启 MySQL 服务前，确保目标目录权限为 mysql:mysql 且权限为 0700。
- 恢复缺失文件：
  - 若文件被误删，从备份恢复 ibdata1 和 ib_logfile*。
  - 若表空间文件孤立，使用 ALTER TABLE 命令重新关联。
验证工具：
- 运行 mysqlcheck --all-databases 检查表一致性。
- 检查错误日志（默认路径 /var/log/mysql/error.log）定位具体缺失的文件。

通过以上分析，A 和 E 是必须检查的项，直接关联日志中的路径和文件缺失问题。

题目 94

Which two statements are true about raw binary backups?

A. They are converted to a highly compressible binary format.

B. They are required to obtain FIPS security compliance.

C. The resulting files are easily human readable.

D. The data format is identical to how MySQL stores the data on disk.

E. They are faster than logical backups because the process is a simple file or file system copy.

正确答案

D. The data format is identical to how MySQL stores the data on disk.

E. They are faster than logical backups because the process is a simple file or file system copy.

关键解析

1. 选项 D 正确性分析

原始二进制备份（Raw Binary Backups）直接复制MySQL在磁盘上的物理数据文件（如 .ibd、ibdata1、ib_logfile* 等），其格式与 MySQL 存储数据的方式完全一致。

InnoDB 存储机制：MySQL 的 InnoDB 引擎将数据组织为固定大小的页（通常 16 KB），并通过二进制格式存储行数据、元数据和索引结构。原始备份直接复制这些页，无需转换或序列化。
二进制日志（Binlog）与数据文件：虽然 Binlog 的格式（如 ROW、STATEMENT）可能因配置而异，但数据文件本身的二进制结构与磁盘存储完全一致。

2. 选项 E 正确性分析

原始二进制备份的速度优势源于其底层文件操作：

文件系统级复制：备份过程仅需复制文件或文件系统块，无需逐行解析 SQL 语句或生成逻辑备份文件（如 .sql），因此 I/O 效率更高。
并行与压缩优化：工具如 MySQL Enterprise Backup 支持多线程操作和直接压缩（如 --compress 选项），进一步加速备份流程。
逻辑备份的瓶颈：逻辑备份（如 mysqldump）需要遍历所有表并生成 INSERT 语句，涉及大量 CPU 和 I/O 资源，速度显著慢于文件复制。

错误选项排除原因

选项	排除原因
A	原始二进制备份的格式已经是紧凑的二进制结构（如 InnoDB 页），但 “highly compressible” 不准确。压缩需额外操作（如使用 `gzip` 或工具内置压缩），并非备份本身的特性。
B	FIPS（联邦信息处理标准）合规性依赖加密和密钥管理，与备份类型无关。MySQL 的安全合规性需通过 TLS/SSL 或加密表空间实现。
C	二进制数据（如 BLOB、InnoDB 页）无法直接阅读，需借助工具（如 `mysqlbinlog` 或 `TO_BASE64()` 函数）转换。

扩展说明

适用场景：
- 大规模数据恢复：原始备份适合 TB 级数据库的快速恢复。
- 主从复制：结合二进制日志（Binlog）可实现高一致性主从同步。
局限性：
- 平台依赖：备份文件需与目标服务器的 MySQL 版本、存储引擎和文件系统兼容。
- 存储占用：未压缩的原始备份可能占用较大空间，需权衡存储成本和性能需求。

通过上述分析，D 和 E 是正确的选项，反映了原始二进制备份的核心特性与优势。

题目 95

Which two methods can be used to determine whether a query uses the hash join algorithm?

A. EXPLAIN FORMAT=JSON

B. EXPLAIN FORMAT=TRADITIONAL

C. EXPLAIN FORMAT=TREE

D. EXPLAIN without any formatting argument

E. EXPLAIN ANALYZE

正确答案

C. EXPLAIN FORMAT=TREE

E. EXPLAIN ANALYZE

关键解析

1. 选项 C 正确性分析

EXPLAIN FORMAT=TREE 是判断 Hash Join 的核心方法。

输出结构：该格式会明确显示执行计划中的 Hash Join 操作符。例如，在查询计划中会直接出现 Inner hash join 或 Left hash join 等描述。
适用性：自 MySQL 8.0.18 版本引入 Hash Join 后，FORMAT=TREE 是唯一能直观展示 Hash Join 算法的默认格式。

示例：

EXPLAIN FORMAT=TREE  
SELECT * FROM t1 JOIN t2 ON t1.c1 = t2.c1;  
-- 输出：-> Inner hash join (t2.c1 = t1.c1)

2. 选项 E 正确性分析

EXPLAIN ANALYZE 结合了执行计划的静态分析与实际运行时的动态数据。

动态验证：此命令会实际执行查询并输出详细的性能指标，包括 Hash Join 的使用情况。
额外信息：除了显示 Hash Join 操作符外，还会包含执行时间、扫描行数等细节，例如 cost=200102.55 rows=200000。
版本兼容性：适用于 MySQL 8.0.18 及以上版本，且支持非等值连接（如 t1.c1 < t2.c1）的 Hash Join 验证。

错误选项排除原因

选项	排除原因
A. `EXPLAIN FORMAT=JSON`	旧版 MySQL（如 8.0.18）的 JSON 格式不直接反映 Hash Join 结构，需设置 `explain_json_format_version=2` 才能显示。默认情况下不适用。
B. `EXPLAIN FORMAT=TRADITIONAL`	传统表格格式仅显示 `Using join buffer`，无法区分 Hash Join 与 Block Nested-Loop Join（BNLJ）。
D. `EXPLAIN without any formatting argument`	等同于传统格式，无法明确展示 Hash Join。

技术扩展

Hash Join 的底层原理：
- 构建阶段：选择较小的表作为构建表（Build Table），将其数据加载到内存 Hash Table 中。
- 探测阶段：遍历另一张表（Probe Table），通过 Hash 值匹配 Build Table 中的记录。
性能优化：
- 内存控制：通过 join_buffer_size 调整内存使用，超限时转为磁盘分片处理。
- 非等值条件处理：Hash Join 支持将非等值条件（如 t1.c1 < t2.c1）作为附加过滤条件（Extra Conditions）。

实践建议

版本检查：确保 MySQL 版本 ≥ 8.0.18，并验证 optimizer_switch 中 hash_join=on。
格式选择：优先使用 EXPLAIN FORMAT=TREE 或 EXPLAIN ANALYZE 查看执行计划。
索引影响：即使存在索引，优化器仍可能选择 Hash Join 以提升大表关联性能。

通过以上分析，C 和 E 是正确的选项，能准确判断 Hash Join 的使用。

题目 96

You have an InnoDB Cluster configured with three servers.

Examine this command, which executes successfully:

mysqldump -uroot -p -d mydatabase > mydatabase_backup.sql

Due to data loss, the cluster is initialized and a restore is attempted resulting in this error:

ERROR 13176 (HY000) at line 23: Cannot update GTID_PURGED with the Group Replication plugin running

Which two actions, either one of which, can fix this error and allow a successful restore of the cluster?

A. Remove the group replication plugin from each instance before restoring.

B. Remove the @@GLOBAL.gtid_executed statement from the dump file.

C. Stop all instances except the primary read/write master instance and run the restore.

D. Restore using the --set-gtid-purged=OFF option.

E. Remove the @@GLOBAL.gtid_purged statement from the dump file.

F. Create the backup by using the --set-gtid-purged=OFF option.

正确答案

D. Restore using the --set-gtid-purged=OFF option.

F. Create the backup by using the--set-gtid-purged=OFF option.

关键解析

1. 选项 D 正确性分析

错误 ERROR 13176 的根源在于 Group Replication（组复制）运行时禁止直接更新 GTID_PURGED。mysqldump 默认生成的备份文件中包含 SET @@GLOBAL.GTID_PURGED 语句，该语句会尝试覆盖集群的 GTID 事务历史，与组复制的全局事务管理机制冲突。

--set-gtid-purged=OFF 的作用：在恢复时通过此选项跳过 GTID_PURGED 的写入，从而避免与组复制的 GTID 管理冲突。

操作示例：

mysql -uroot -p < mydatabase_backup.sql --set-gtid-purged=OFF

2. 选项F正确性分析

在备份阶段使用 --set-gtid-purged=OFF 可直接避免生成包含 GTID_PURGED 的备份文件，从源头解决问题。

备份命令优化：

mysqldump -uroot -p -d mydatabase --set-gtid-purged=OFF > mydatabase_backup.sql

效果：生成的备份文件不包含 SET @@GLOBAL.GTID_PURGED 语句，恢复时不会触发 GTID 冲突。

错误选项排除原因

选项	排除原因
A	移除组复制插件会破坏集群架构，恢复后需重新配置组复制，操作复杂且风险高。
B/E	手动删除备份文件中的 `GTID_PURGED` 或 `GTID_EXECUTED` 语句虽然可能解决问题，但需逐文件修改，易出错且效率低。而使用 `--set-gtid-purged=OFF` 更直接可靠。
C	停止非主节点无法解决 `GTID_PURGED` 冲突问题，且违反组复制的多节点一致性要求。

技术扩展

GTID 在组复制中的角色：
- 全局事务标识：GTID 用于确保集群内事务的全局唯一性和顺序一致性。
- 冲突检测：组复制通过 GTID 追踪事务提交状态，避免数据冲突。
备份恢复最佳实践：
- 备份时：始终结合 --set-gtid-purged=OFF 和 --single-transaction 以确保一致性并避免 GTID 干扰。
- 恢复前：验证备份文件是否包含 GTID_PURGED 语句，必要时使用 grep 检查：
```
grep "GTID_PURGED" mydatabase_backup.sql  
```
- 恢复后：通过 SELECT @@GLOBAL.GTID_EXECUTED 验证事务状态，确保与集群其他节点同步。

通过以上分析，D 和 F 是正确的选项，分别对应恢复和备份阶段的直接解决方案。

题目 97

Which three are types of InnoDB tablespaces?

A. data tablespaces

B. schema tablespaces

C. redo tablespaces

D. temporary table tablespaces

E. undo tablespaces

F. encryption tablespaces

正确答案

A. data tablespaces

D. temporary table tablespaces

E. undo tablespaces

详细解释每个选项：

✅ A. data tablespaces（数据表空间）

这是 InnoDB 的主表空间类型。
包括：
- 系统表空间（system tablespace）：通常为 ibdata1。
- 文件每表表空间（file-per-table tablespaces）：每个 InnoDB 表有自己的 .ibd 文件。
用于存储用户数据和索引。

✅ 属于 InnoDB 表空间类型 ✔

❌ B. schema tablespaces（模式表空间）

MySQL / InnoDB 没有“schema tablespace”这种官方定义的表空间类型。
数据库（schema）只是逻辑结构，不对应特定的物理表空间。

❌ 不属于 InnoDB 表空间类型 ✘

❌ C. redo tablespaces（重做表空间）

虽然 InnoDB 使用 Redo Log（重做日志） 来实现事务的持久性，但 Redo Log 并不是一种表空间。
Redo Log 是单独的日志文件（如 ib_logfile0, ib_logfile1），不属于表空间范畴。

❌ 不属于 InnoDB 表空间类型 ✘

✅ D. temporary table tablespaces（临时表表空间）

InnoDB 使用 临时表空间 来存储会话期间创建的临时表。
默认位于数据目录下的 ibtmp1 文件中。
MySQL 8.0 支持多个临时表空间。

✅ 属于 InnoDB 表空间类型 ✔

✅ E. undo tablespaces（撤销表空间）

InnoDB 使用 Undo Logs 来支持事务回滚、MVCC（多版本并发控制）等功能。
在 MySQL 8.0 中，Undo Logs 可以被配置为使用独立的表空间（即多个 undo_001, undo_002 等文件）。

✅ 属于 InnoDB 表空间类型 ✔

❌ F. encryption tablespaces（加密表空间）

虽然 InnoDB 支持 表空间加密（TDE, Transparent Data Encryption），但这并不是一个独立的表空间类型。
加密可以应用于数据表空间、系统表空间等，但它是一个属性而非新类型。

❌ 不属于 InnoDB 表空间类型 ✘

补充知识（InnoDB 表空间总结）

表空间类型	描述
系统表空间（System）	存储 InnoDB 字典、双写缓冲、change buffer 等
文件每表表空间（File-per-table）	每个表有自己的 `.ibd` 文件
通用表空间（General）	共享表空间，可包含多个表
临时表空间（Temporary）	用于临时表
撤销表空间（Undo）	存储 Undo Log 信息

题目 98

Examine this statement and output:

mysql> SELECT ROW_NUMBER() OVER() AS QN,
query, exec_count, avg_latency, lock_latency
FROM sys.statement_analysis
ORDER BY exec_count;

|----|----------------------------------------------------------------------------|------------|-------------|--------------|
| QN | query                                                                      | exec_count | avg_latency | lock_latency |
|----|----------------------------------------------------------------------------|------------|-------------|--------------|
| 1  | SELECT SUM('k') FROM 'mysch ... () - INTERVAL ? SQL_TSI_HOUR               | 381268     | 31.44 ms    | 1.01 m       |
| 2  | SELECT 'id', 'val', 'a', 'b' ... updated WHERE 'created' < ?               | 150317     | 358.34 us   | 30.06 s      |
| 3  | SELECT 'emp_no', 'val', 'cre ... ated' + INTERVAL ? SQL_TSI_DAY | 600      | 600        | 523.32 ms   | 120.24 s     | 
| 4  | SELECT 'a', 'b', 'c' FROM 'm ... AND ? OR 'k' BETWEEN ? AND ?              | 200        | 10.32 s     | 40.19 s      |
| 5  | SELECT 'a', 'b' FROM myschem G ('emp_no') WHERE 'val' = ?                  | 1          | 21.03 s     | 274.00 us    |
|----|----------------------------------------------------------------------------|------------|-------------|--------------|

You must try to reduce query execution time.

Which two queries should you focus on?

A. QN=2

B. QN=3

C. QN=4

D. QN=1

E. QN=5

正确答案

B. QN=3

C. QN=4

关键解析

从 sys.statement_analysis 的输出分析，优化应优先关注单次执行时间高或资源消耗显著的查询。以下是具体分析：

1. QN=3（平均延迟 523.32 ms）

高单次延迟：平均每次执行耗时超过 500 ms，属于性能敏感型查询。
锁延迟问题：总锁等待时间达 120.24 秒，可能涉及行锁竞争或事务冲突。
执行频率：虽然执行次数（600 次）相对较低，但单次延迟对用户体验和系统资源占用影响较大。

2. QN=4（平均延迟 10.32 s）

极端延迟：单次执行时间高达 10 秒，是典型的慢查询，需立即优化。
潜在全表扫描：条件 AND ? OR 'k' BETWEEN ? AND ? 可能导致索引失效，触发全表扫描。
锁资源占用：总锁等待时间 40.19 秒，可能与表锁或长时间事务有关。

其他选项排除原因

选项	排除原因
QN=1	尽管执行次数最多（381,268 次），但单次延迟仅 31.44 ms，总资源消耗可通过批量优化分散，非紧急优先级。
QN=2	平均延迟极低（358.34 μs），锁延迟虽高（30.06 s），但单次锁等待平均仅 0.2 ms，对整体性能影响有限。
QN=5	执行次数仅 1 次，可能是偶发操作，优化收益低，除非是核心业务逻辑（但题目未提及）。

优化建议

QN=3 优化：

索引优化：检查 WHERE 'created' + INTERVAL ? DAY 的条件，避免函数操作导致索引失效。
事务拆分：减少事务持有锁的时间，避免长事务导致的锁竞争。

QN=4 优化：

条件重写：将 OR 拆分为独立查询或使用联合索引覆盖 BETWEEN 范围查询。
执行计划分析：通过 EXPLAIN 验证是否使用索引，必要时强制索引或重构查询逻辑。

总结

单次执行时间高（QN=3、QN=4）的查询对系统性能影响更直接，而高频低延迟查询（QN=1）可通过负载均衡或异步处理缓解。根据 sys.statement_analysis 的设计目标，优化应优先解决显著性能瓶颈。

题目 99

You are asked to review possible options for a new MySQL instance. It will be a large, busy reporting data warehousing instance.

[mysql]
innodb_data_file_path=

Which two configurations would satisfy long-term storage demands?

A. ibdata1:12M: autoextend

B. ibdata1:12M; ibdata2:12M: autoextend

C. ibdata1:12M; ibdata2:12M; ibdata3:12M

D. ibdata1:12M; /tmp/ibdata2 :12M:autoextend

E. ibdata1:12M

F. ibdata1:12M: autoextend; ibdata2:12M: autoextend

正确答案

A. ibdata1:12M:autoextend

B. ibdata1:12M;ibdata2:12M:autoextend

关键解析

在大型数据仓库场景中，系统表空间（System Tablespace）的配置需满足长期存储扩展性、I/O 性能优化和容错性。以下是关键分析：

1. 选项 A 正确性分析

自动扩展机制：通过 autoextend 属性允许最后一个文件动态扩容，避免因数据增长导致存储不足。
```
innodb_data_file_path=ibdata1:12M:autoextend  
```
适用场景：适合初期存储需求较小但需要灵活扩展的场景，但单文件可能导致 I/O 瓶颈。

2. 选项 B 正确性分析

多文件分散 I/O 负载：配置两个文件（ibdata1 和 ibdata2），并将 autoextend 仅作用于最后一个文件（ibdata2），满足语法规则。
```
innodb_data_file_path=ibdata1:12M;ibdata2:12M:autoextend  
```
性能优势：多文件可分布在不同磁盘，提升并发读写能力（例如 ibdata1 在 SSD，ibdata2 在 HDD）。

错误选项排除原因

选项	排除原因
C	三个文件均未启用 `autoextend`，无法应对数据增长，长期会导致空间耗尽。
D	`/tmp` 为临时目录，重启后可能导致数据丢失，且非持久化存储路径。
E	单文件且无自动扩展，无法满足大型数据仓库的扩展需求。
F	`autoextend` 只能作用于最后一个文件，多文件同时启用违反语法规则。

配置最佳实践

自动扩展与容量限制：

结合 autoextend:max 限制最大文件大小，避免单文件过大（如 ibdata1:12M:autoextend:max:2000M）。

多磁盘部署：

将多个数据文件分散到不同物理磁盘（如 /disk1/ibdata1 和 /disk2/ibdata2），提升 I/O 吞吐量。

监控与维护：

定期检查 SHOW VARIABLES LIKE 'innodb_data_file_path' 确认文件扩展状态。

技术扩展

InnoDB 表空间文件规则：
- 每个文件需独立指定大小（如 12M），且 autoextend 仅限最后一个文件。
- 文件路径可包含绝对路径（如 /data/ibdata1），但需确保目录权限正确。
性能调优：
- 结合 innodb_buffer_pool_size 和 innodb_log_file_size 优化内存与日志配置。

通过以上分析，A 和 B 是满足长期存储需求的配置方案。

题目 100

An existing asynchronous replication setup is running MySQL 8.

Which two steps are a part of implementing GTID replication?

A. Enable GTID by executing this on the master and the slave: SET GLOBAL GTID_ENABLED=on;

B. On the slave, alter the MySQL master connection setting with: ALTER channel CHANGE MASTER TO MASTER_AUTO_POSITION = 1;

C. Execute this on the slave to enable GTID: RESET SLAVE; START SLAVE GTID_NEXT=AUTOMATIC;

D. Execute this on the slave to enable GTID: START SLAVE IO_THREAD WITH GTID;

E. Restart MySQL (master and slave) with these options enabled: --gtid_mode=ON, --log-bin, --log-slave-updates, --enforce-gtid-consistency

F. On the slave, alter the MySQL master connection setting with: CHANGE MASTER TO MASTER_AUTO_POSITION = 1;

正确答案

E. Restart MySQL (master and slave) with these options enabled: --gtid_mode=ON, --log-bin, --log-slave-updates, --enforce-gtid-consistency

F. On the slave, alter the MySQL master connection setting with: CHANGE MASTER TO MASTER_AUTO_POSITION = 1;

关键解析

1. 选项 E 正确性分析

在 MySQL 8 中启用 GTID 复制需要主从库同时配置核心参数并重启生效，具体包括：

gtid_mode=ON：启用 GTID 模式。
enforce-gtid-consistency=ON：强制事务一致性，避免非事务安全的语句破坏 GTID 机制。
log-bin：主库需启用二进制日志以记录事务。
log-slave-updates：从库需记录中继日志到自身 Binlog。

这些参数需写入配置文件（如 my.cnf）并重启 MySQL 服务才能生效。

2. 选项 F 正确性分析

启用 GTID 后，从库需通过 CHANGE MASTER TO MASTER_AUTO_POSITION=1 配置自动定位主库事务，替代传统的 master_log_file 和 master_log_pos 参数。

MASTER_AUTO_POSITION=1：从库基于 GTID 自动同步主库未执行的事务。

错误选项排除原因

选项	排除原因
A	`SET GLOBAL GTID_ENABLED=on` 是无效语法，GTID需通过配置文件设置且无法动态启用。
B	`ALTER channel CHANGE MASTER TO` 语法错误，正确命令是`CHANGE MASTER TO`。
C/D	`RESET SLAVE`、`START SLAVE GTID_NEXT=AUTOMATIC` 或 `WITH GTID` 是无效操作，GTID 复制无需这些额外步骤。

技术扩展

GTID 复制的核心优势：

自动故障恢复：从库通过 GTID 自动定位主库事务，无需手动指定 Binlog位置。
全局事务一致性：GTID 唯一标识全局事务，避免数据冲突。
配置验证与监控：
- 主库状态：SHOW MASTER STATUS 查看当前GTID集合。
- 从库状态：SHOW SLAVE STATUS\G 检查 Retrieved_Gtid_Set 和 Executed_Gtid_Set 确保同步正常。

通过以上分析，选项 E 和 F 是正确的步骤。

题目 101

You plan to install MySQL Server by using the RPM download.

Which two statements are true?

A. You must manually initialize the data directory.

B. You can provide the root password interactively

C. The MySQL RPM package installation supports deploying multiple MySQL versions on the same host.

D. MySQL uses the RPM relocatable installation target feature.

E. You can find the root password in the error log after the first start.

F. The functionality is split among several RPM package files.

正确答案

E. You can find the root password in the error log after the first start.

F. The functionality is split among several RPM package files.

关键解析

1. 选项 E 正确性分析

在通过 RPM 安装 MySQL 后，首次启动服务时会自动生成一个临时 root 密码，并记录在 MySQL 的错误日志中（默认路径为 /var/log/mysqld.log）。用户需要通过以下命令查找临时密码：

sudo grep 'temporary password' /var/log/mysqld.log

2. 选项 F 正确性分析

MySQL 的 RPM 安装包将功能拆分为多个独立的包，主要包括：

MySQL Server RPM：包含服务器核心组件。
MySQL Client RPM：提供客户端工具（如 mysql 命令行）。
MySQL Development RPM：包含开发库和头文件。
MySQL Shared Libraries RPM：共享库文件。

例如：

sudo rpm -ivh mysql-community-server.rpm
sudo rpm -ivh mysql-community-client.rpm

这种分拆设计提高了灵活性，允许按需安装特定组件。因此，选项 F 正确。

错误选项排除原因

选项	排除原因
A	RPM 安装会自动初始化数据目录，无需手动操作。
B	RPM 安装过程中不会交互式提示设置 `root` 密码，密码需通过临时密码修改或运行 `mysql_secure_installation` 脚本设置。
C	同一主机上部署多个 MySQL 版本需通过源码编译或 Docker 等容器化技术，RPM 安装会覆盖旧版本。
D	MySQL RPM 包未使用“可重定位安装”特性，默认路径固定（如 `/var/lib/mysql` 为数据目录）。

技术扩展

RPM 安装的核心优势：

依赖自动管理：通过 yum 或 dnf 工具自动解决依赖。
版本控制与升级：支持通过 yum update 升级版本。

安全配置建议：
1. 运行 mysql_secure_installation 脚本以删除匿名用户、禁止远程root登录等。
2. 修改默认端口并配置防火墙。

通过以上分析，选项 E 和 F 是正确的陈述。

题目 102

Which four connection methods can MySQL clients specify with the --protocol option when connecting to a MySQL server?

A. IPv4

B. SOCKET

C. MEMORY

D. PIPE

E. IPv6

F. FILE

G. TCP

H. DIRECT

正确答案

B. SOCKET

C. MEMORY

D. PIPE

G. TCP

关键解析

MySQL客户端通过 --protocol 选项可以指定以下四种连接协议：

1. TCP（选项 G）

描述：基于 TCP/IP 协议的网络连接，支持 IPv4 和 IPv6 地址，是跨平台的标准连接方式。
适用场景：适用于远程或本地网络环境，通过端口（默认3306）通信。

示例命令：

mysql --protocol=TCP -h 127.0.0.1 -P 3306 -u root -p

2. SOCKET（选项 B）

描述：Unix 域套接字（Unix Socket），仅适用于类 Unix 系统（如 Linux、macOS）。
特点：通过本地套接字文件（如 /tmp/mysql.sock）通信，无需网络协议栈，性能更高。

示例命令：

mysql --protocol=SOCKET -S /tmp/mysql.sock -u root -p

3. PIPE（选项 D）

描述：命名管道（Named Pipe），适用于 Windows 系统。
特点：通过管道文件实现本地进程间通信，类似 Unix Socket，但仅限 Windows 平台。

示例命令：

mysql --protocol=PIPE --pipe -u root -p

4. MEMORY（选项 C）

描述：共享内存（Shared Memory），适用于 Windows 系统。
特点：通过内存区域实现快速本地通信，但需显式启用 shared_memory 参数。
配置与使用：
- 在MySQL配置文件中启用共享内存：
```
[mysqld]  
shared_memory=ON  
```
- 客户端连接命令：
```
mysql --protocol=MEMORY -u root -p  
```

错误选项排除原因

选项	排除原因
A. IPv4 / E. IPv6	并非独立协议类型，而是 TCP 协议下的地址版本，客户端通过 `--host` 指定 IP 地址即可。
F. FILE / H. DIRECT	在 MySQL 官方文档中未提及此类协议支持。

技术扩展

MySQL 客户端默认按以下顺序尝试连接：
- Unix Socket（若客户端与服务器在同一 Linux 主机）。
- TCP/IP（远程或跨平台场景）。
- 命名管道/共享内存（Windows 本地连接）。
性能对比：
- Unix Socket > 共享内存 > TCP/IP（本地环境），因省去网络协议栈开销。
- TCP/IP 在远程访问中更灵活，但受网络延迟影响。

通过以上分析，B、C、D、G 是正确的协议选项。

题目 103

You have a MySQL client installed on your Linux workstation with a default installation. You have your admin login credentials to connect to a MySQL server running Microsoft Windows on remote host 192.0.2.1:3306 to connect to the world database.

Which four options need to be specified to complete this task with a single command?

A. --port=3306

B. --protocol=pipe

C. --host=192.0.2.1

D. --protocol=UDP

E. --user=admin

F. --password

G. --socket=/tmp/mysql.sock

H. --shared-memory-base-name=world

I. --database=world

正确答案

C. --host=192.0.2.1

E. --user=admin

F. --password

I. --database=world

关键解析

要在 Linux 客户端连接远程 Windows 主机的 MySQL 服务器并访问 world 数据库，需通过单一命令指定以下四类参数：

1. 远程主机地址（--host）

必选原因：需明确服务器 IP 地址或域名。题目中远程主机为 192.0.2.1，必须通过 --host=192.0.2.1 指定。
排除其他协议选项：
- --protocol=pipe（选项 B）适用于 Windows 本地命名管道，但客户端是 Linux，无法直接使用。
- --socket（选项 G）和 --shared-memory（选项 H）仅用于本地连接。

2. 身份验证参数（--user 和 --password）

用户权限：需通过 --user=admin 指定管理员账户，--password 提示输入密码（避免明文暴露）。
安全性：MySQL 默认要求密码验证，即使密码为空也需显式指定 --password。

3. 目标数据库（--database）

直接访问需求：题目要求连接后直接操作 world 数据库，需通过 --database=world 指定初始数据库。若省略此参数，需在连接后手动执行 USE world，但题目要求通过单一命令完成。

4. 端口与协议的隐含规则

默认端口：MySQL 默认端口为 3306，若未修改则无需显式指定 --port=3306（选项 A）。
协议默认行为：远程连接默认使用 TCP/IP 协议，无需额外指定 --protocol。

错误选项排除原因

选项	排除原因
A. --port=3306	默认端口无需显式指定。
B. --protocol=pipe	仅适用于 Windows 本地命名管道，Linux 客户端无法使用。
D. --protocol=UDP	MySQL 仅支持 TCP 协议。
G. --socket	仅用于 Unix 域套接字本地连接。
H. --shared-memory	仅适用于 Windows 本地共享内存。

完整命令示例

mysql --host=192.0.2.1 --user=admin --password --database=world

执行后系统会提示输入密码，输入管理员密码即可完成连接。

题目 104

Which three are characteristics of a newly created role?

A. It is stored in the mysql.role table.

B. It can be dropped using the DROP ROLE statement.

C. It can be protected with a password.

D. It can be granted to user accounts.

E. It can be renamed using the RENAME ROLE statement.

F. It is created as a locked account.

正确答案

B. It can be dropped using the DROP ROLE statement.

D. It can be granted to user accounts.

F. It is created as a locked account.

关键解析

1. 选项 B 正确性分析

新创建的角色可以通过 DROP ROLE 语句删除。例如：

DROP ROLE 'analyst';

此操作会从系统中移除角色定义，并撤销所有用户通过该角色继承的权限。

2. 选项 D 正确性分析

角色可以授予用户账户，这是 MySQL 角色管理的核心功能。通过 GRANT 语句将角色分配给用户后，用户将继承角色的权限。例如：

GRANT 'developer' TO 'user1'@'localhost';

这种设计简化了权限管理，尤其适用于需要批量分配相同权限的场景。

3. 选项 F 正确性分析

新创建的角色默认作为锁定账户（即 NOLOGIN 状态），无法直接用于登录数据库。角色本质上是权限集合的抽象，而非实际登录实体。例如，创建角色时无需指定密码，且其账户状态在 mysql.user 表中标记为锁定。

错误选项排除原因

选项	排除原因
A	角色存储在 `mysql.user` 表中（与其他用户账户共用表结构），而非独立的 `mysql.role` 表。
C	角色本身不需要密码保护，密码机制仅适用于用户账户。
E	MySQL不支持 `RENAME ROLE` 语句，重命名角色需通过 `ALTER USER` 实现。

技术扩展

角色与用户账户的区别：
- 角色：权限集合的抽象，不可直接登录，需通过 GRANT 分配给用户。
- 用户：实际登录实体，可设置密码并绑定角色。
角色状态验证：
- 查看角色账户状态：

SELECT account_locked FROM mysql.user WHERE user = 'role_name';

结果应为 Y（锁定状态）。

权限继承机制：
- 用户需通过 SET DEFAULT ROLE 或全局参数 activate_all_roles_on_login 激活角色权限。

通过以上分析，B、D、F 是正确的角色特性。

题目 105

Table t is an InnoDB table. Examine these statements and output:

mysql> selet count(1) from t;
+-----------+
|  count(1) |
+-----------+
|        72 |
+-----------+

mysql> show indexes from t\G
**************************1.row***************************
Table: t
Non_unique:0
Key_name:PRIMARY
Seq_in_index: 1
Column_name: a
Collation:A
Cardinality: 72
Sub_part:NULL
Packed:NULL
Null:
Index_type:STREE
Comment: Index_comment:
Visible:YES
Expression:NULL
**************************2.row***************************
Table: t
Non_unique:1
Key_name:b_idx
Seq_in_index: 1
Column_name: b
Collation:A
Cardinality: 1
Sub_part:NULL
Packed:NULL
Null:YES
Index_type:BTREE
Comment:
Index_comment:
Visible:NO
Expression:NULL
2 row in set (0.00 sec)

Which two are true?

A. ANALYZE TABLE t would update index statistics uniquely for the PRIMARY index.

B. Table t has two viable indexes to be used for queries.

C. SELECT b from t would perform a table scan.

D. Index b_idx has a low number of unique values.

E. SELECT a FROM t would perform a table scan.

正确答案

C. SELECT b from t would perform a table scan.

D. Index b_idx has a low number of unique values.

关键解析

1. 选项 C 正确性分析

表 t 的列 b 上虽然存在索引 b_idx，但 SHOW INDEXES 显示其 Visible 属性为 NO，表示该索引处于不可见状态。MySQL 优化器在生成执行计划时会忽略不可见索引，因此执行 SELECT b FROM t 时无法利用 b_idx，只能通过全表扫描获取数据。

2. 选项 D 正确性分析 索引 b_idx 的 Cardinality（基数）值为 1，而表 t 的总行数为 72。Cardinality 表示索引列中不同值的估计数量，低基数（接近1且远小于总行数）表明该索引列（b）存在大量重复值，区分度极低。这种场景下，即使索引可见，优化器也可能因效率问题放弃使用索引。

错误选项排除原因

选项	排除原因
A	`ANALYZE TABLE` 会更新所有索引的统计信息（包括主键和二级索引），而非仅主键索引。
B	只有主键索引（`PRIMARY`）可用，`b_idx` 因 `Visible=NO` 不可见，无法被查询优化器使用。
E	列 `a` 是主键，查询 `SELECT a FROM t` 会直接通过主键索引（聚簇索引）访问数据，无需全表扫描。

技术扩展

索引可见性（Visible）的作用：
- 通过 ALTER TABLE ... ALTER INDEX ... VISIBLE/INVISIBLE 可动态控制索引是否对优化器可见，用于测试索引性能或临时禁用索引。
- 不可见索引仍会随数据更新维护，但不会被查询计划选中。
Cardinality 与查询优化：
- 高基数列（如主键）适合作为索引，低基数列（如性别、状态字段）的索引可能被优化器忽略。
- 可通过 ANALYZE TABLE 更新统计信息，帮助优化器更准确地选择索引。

通过以上分析，选项 C 和 D 是正确的陈述。

题目 106

Which two statements are true about the mysqld-auto.cnf file?

A. It is always updated with changes to system variables.

B. This file is for logging purposes only and is never processed.

C. It is read and processed at the end of startup configuration.

D. This file is for storing MySQL Server configuration options in JSON format.

E. It is read and processed at the beginning of startup configuration.

F. This file is for storing MySQL server_uuid values only.

正确答案

C. It is read and processed at the end of startup configuration.

D. This file is for storing MySQL Server configuration options in JSON format.

解析与依据

1. 选项 C 正确性分析

mysqld-auto.cnf 文件在 MySQL 服务器启动时最后被处理，优先级高于其他配置文件（如 my.cnf）和命令行参数。这是因为该文件用于存储通过 SET PERSIST 或 SET PERSIST_ONLY 语句持久化的系统变量，需在所有其他配置加载完成后应用这些动态设置的参数。例如，若 max_connections 同时在 my.cnf 和 mysqld-auto.cnf 中定义，后者的值会覆盖前者。

2. 选项 D 正确性分析mysqld-auto.cnf 以 JSON 格式存储持久化的系统变量配置。其内容包含变量名、值及元数据（如修改用户、时间戳等）。例如：

{
  "Version": 2,
  "mysql_dynamic_parse_early_variables": {
    "max_connections": {
      "Value": "1000",
      "Metadata": {
        "Host": "localhost",
        "User": "root",
        "Timestamp": 1735369777874841
      }
    }
  }
}

这一设计使得配置可读性高且易于自动化管理，同时支持加密存储敏感变量（如私钥）。

错误选项排除原因

选项	排除原因
A	并非所有系统变量更改都会更新该文件。仅通过 `SET PERSIST` 或 `SET PERSIST_ONLY` 语句显式持久化的变量会被记录。手动修改其他配置文件（如 `my.cnf`）不会触发更新。
B	文件并非仅用于日志记录。它是核心配置文件之一，直接影响服务器行为。
E	文件在启动时最后处理，而非初始阶段。其优先级高于命令行和其他配置文件。
F	`server_uuid` 存储在 `auto.cnf` 文件中，而非 `mysqld-auto.cnf`。

技术扩展

文件管理机制：
- 该文件由 MySQL 服务器自动维护，禁止手动编辑，否则可能导致启动失败。若需移除配置，应使用 RESET PERSIST 语句。
- 若服务器启动时发现文件格式错误，会直接报错退出。此时需禁用 persisted_globals_load 或删除文件以恢复。
与其他配置的优先级关系：
- 启动顺序优先级：mysqld-auto.cnf > 命令行参数 > my.cnf > 默认值。
- 示例：若 innodb_buffer_pool_size 在 my.cnf 中设为 8G，但通过 SET PERSIST 设为 16G，重启后实际生效值为 16G。
安全特性：
- 从 MySQL 8.0.29 开始，敏感变量（如密码类参数）会以加密形式存储，依赖密钥环组件保障安全性。

通过以上分析，选项 C 和 D 是正确的陈述。

题目 107

Examine this command and output:

mysql> SELECT * FROM data_locks LIMIT 1\G
*************************** 1. row ***************************
               ENGINE: INNODB
       ENGINE_LOCK_ID: 1200:146
ENGINE_TRANSACTION_ID: 1200
            THREAD_ID: 45
             EVENT_ID: 11
        OBJECT_SCHEMA: mydb
          OBJECT_NAME: mytable1
       PARTITION_NAME: NULL
    SUBPARTITION_NAME: NULL
           INDEX_NAME: NULL
OBJECT_INSTANCE_BEGIN: 118793337250203
            LOCK_TYPE: RECORD
            LOCK_MODE: X
         LOCK_STATUS: GRANTED
           LOCK_DATA: 1922,1922

Which two statements are true?

A. The lock is an exclusive lock.

B. The lock is a shared lock.

C. The lock is a row-level lock.

D. The lock is an intentional lock.

E. The lock is at the metadata object level.

F. The lock is at the table object level.

正确答案

A. The lock is an exclusive lock.

C. The lock is a row-level lock.

解析与依据

1. 选项 A 正确性分析

输出中 LOCK_MODE 字段为 X，表示这是一个排他锁（Exclusive Lock）。

排他锁（X锁）的特点：
- 持有该锁的事务可以对记录进行读写（如更新、删除），其他事务无法同时获取共享锁（S锁）或排他锁。
- 在 data_locks 表中，X 锁模式明确对应排他锁，常用于写操作（如 UPDATE、DELETE）。

2. 选项 C 正确性分析

LOCK_TYPE 字段为 RECORD，表示这是一个行级锁（Row-Level Lock）。

行级锁的特性：
- 锁定单行记录（如 LOCK_DATA 中的 1922,1922 可能表示记录的聚簇索引值）。
- 与表级锁（LOCK_TYPE=TABLE）不同，行级锁粒度更细，允许高并发操作。
关键验证：
- 若锁是表级锁，LOCK_TYPE 应为 TABLE，且 INDEX_NAME 可能为 PRIMARY 或其他表级索引。

错误选项排除原因

选项	排除原因
B	`LOCK_MODE` 为 `X` 而非 `S`（共享锁），共享锁允许其他事务读取但禁止写入。
D	意向锁（如 `IS`、`IX`）属于表级锁，而此处 `LOCK_TYPE=RECORD` 明确为行级锁。
E	元数据锁（Metadata Lock）由 `metadata_locks` 表记录，与 `data_locks` 中行级锁无关。
F	表级锁会显示 `LOCK_TYPE=TABLE`，而此处为 `RECORD`。

技术扩展

行级锁与索引的关系：
- 行级锁通过索引实现。若查询未使用索引，InnoDB 会退化为表级锁。
- 示例中的 LOCK_DATA 字段可能包含记录的索引值（如主键或二级索引值），具体取决于查询条件。
锁监控工具：
- SHOW ENGINE INNODB STATUS 可查看当前锁等待和死锁信息。
- performance_schema.data_lock_waits 表记录锁的依赖关系，辅助排查阻塞问题。

通过上述分析，选项 A 和 C 是正确的陈述。

题目 108

Your MySQL installation is running low on space due to binary logs. You need to reduce your log space usage urgently.

Which two sets of actions when completed will accomplish this?

A. Use PURGE BINARY LOGS to <binlog_name>.

B. Use SET GLOBAL binlog_expire_logs_seconds=<value> and run the FLUSH BINARY LOGS command.

C. Use SET GLOBAL binlog_expire_logs_seconds=<value> and restart the server.

D. Use SET PERSIST binlog_expire_logs_seconds=<value>.

E. Set binlog_expire_logs_seconds = 0 in my.cnf and restart the server.

F. Set binlog_expire_logs_seconds in my.cnf.

正确答案

A. Use PURGE BINARY LOGS to <binlog_name>.

B. Use SET GLOBAL binlog_expire_logs_seconds=<value> and run the FLUSH BINARY LOGS command.

关键解析

1. 选项 A：手动清理特定日志文件

通过 PURGE BINARY LOGS 命令可以直接删除指定名称或时间点之前的二进制日志文件，这是立即释放磁盘空间的最快方法。例如：

PURGE BINARY LOGS TO 'binlog.000010';-- 删除编号为000010之前的所有日志

此操作无需等待日志切换或参数生效，适合紧急场景。

2. 选项 B：动态设置过期时间并触发清理

动态设置参数：

SET GLOBAL binlog_expire_logs_seconds=<value> 是动态参数，无需重启即可生效（例如设置为 604800 秒表示保留 7 天日志）。

触发清理：

执行 FLUSH BINARY LOGS 会强制创建新的二进制日志文件，并触发自动删除过期的旧日志文件。

示例操作：

SET GLOBAL binlog_expire_logs_seconds = 604800;
FLUSH BINARY LOGS;-- 立即触发日志切换与过期日志清理

这一组合既能持久化配置（需配合 SET PERSIST 或写入 my.cnf），又可立即生效。

错误选项排除原因

选项	排除原因
C	动态参数 `binlog_expire_logs_seconds` 不需要重启即可生效，重启服务器是冗余操作。
D	`SET PERSIST` 仅持久化参数到配置文件，但未触发日志切换，无法立即释放空间。需配合 `FLUSH` 才能快速生效。
E	设置 `binlog_expire_logs_seconds=0` 会禁用自动清理功能，导致日志文件无法删除，反而加剧空间问题。
F	修改 `my.cnf` 需重启服务器才能生效，无法满足紧急需求。

技术扩展

自动清理机制：
- 当二进制日志文件超过 max_binlog_size 或手动执行 FLUSH LOGS 时，MySQL 会自动删除过期的日志文件（根据 binlog_expire_logs_seconds 判断过期时间）。
参数优先级：
- binlog_expire_logs_seconds 优先级高于已弃用的 expire_logs_days。若两者同时配置，仅前者生效。

通过上述分析，选项 A 和 B 是唯一能快速、可靠解决磁盘空间不足问题的组合。

题目 109

You must run multiple instances of MySQL Server on a single host.

Which three methods are supported?

A. Use system tools to lock each instance to its own CPU.

B. Use resource groups to lock different instances on separate CPUs.

C. Run mysqld with --datadir defined for each instance.

D. Run MySQL Server docker containers.

E. Start mysqld or mysqld_safe using different option files for each instance.

F. Use systemd with different settings for each instance.

正确答案

D. Run MySQL Server docker containers.

E. Start mysql or mysqld_safe using different option files for each instance.

F. Use systemd with different settings for each instance.

关键解析

1. 选项 D：运行 MySQL Server Docker 容器

容器化隔离：通过 Docker 为每个实例创建独立容器，利用容器的资源隔离特性（如网络、文件系统）实现多实例。
优势：
- 完全隔离的运行环境，避免端口/文件冲突。
- 可复用官方镜像，快速部署。

示例命令：

# 启动第一个容器（端口映射 3307:3306）  
docker run -d --name mysql-instance1 -p 3307:3306 -v mysql-data1:/var/lib/mysql mysql:latest  
# 启动第二个容器（端口映射 3308:3306）  
docker run -d --name mysql-instance2 -p 3308:3306 -v mysql-data2:/var/lib/mysql mysql:latest

2. 选项 E：为每个实例使用不同的选项文件

配置文件隔离：通过不同的配置文件（.cnf）定义各实例的端口、数据目录、日志路径等参数。

操作步骤：

创建实例专属配置文件（如 my_instance1.cnf、my_instance2.cnf）：

[mysqld]  
datadir = /var/lib/mysql/instance1  
port = 3307  
socket = /tmp/mysql1.sock  
log-error = /var/log/mysql/error1.log

启动时指定配置文件：

mysqld_safe --defaults-file=/etc/mysql/my_instance1.cnf &  
mysqld_safe --defaults-file=/etc/mysql/my_instance2.cnf &

3. 选项 F：通过 systemd 配置独立服务 systemd 是 Linux 系统服务管理的标准工具，可为每个实例创建独立服务单元（如 mysqld@3307.service），实现启动、停止和监控的标准化管理。

服务文件示例：

# /etc/systemd/system/mysqld@.service
[Unit]
Description=MySQL Server Instance %i

[Service]
User=mysql
Group=mysql
ExecStart=/usr/sbin/mysqld --defaults-file=/etc/mysql/my%i.cnf

启动实例：

systemctl start mysqld@3307
systemctl start mysqld@3308

此方法支持开机自启和日志统一管理。

错误选项排除原因

选项	排除原因
A/B（CPU 绑定）	CPU 绑定是资源优化手段，与多实例部署无直接关系。MySQL 多实例的核心是配置隔离，而非硬件资源分配。
C（为每个实例指定不同的 `--datadir`）	仅定义 `--datadir` 不足以完整支持多实例运行，还需确保端口（`--port`）、套接字文件（`--socket`）等唯一。

示例：

# 实例1  
mysqld --datadir=/var/lib/mysql/instance1 --port=3307 --socket=/tmp/mysql1.sock  
# 实例2  
mysqld --datadir=/var/lib/mysql/instance2 --port=3308 --socket=/tmp/mysql2.sock

技术扩展与最佳实践

端口与文件隔离：
- 每个实例需唯一端口（如 3307、3308）和 socket 文件路径（如 /tmp/mysql3307.sock）。
- 避免权限冲突：数据目录属主应为 mysql 用户，权限设置为 750。
初始化与维护：
- 使用 mysql_install_db 或 mysqld --initialize 初始化数据目录。
- 定期备份不同实例的数据目录，避免交叉影响。
监控与日志：
- 为每个实例配置独立错误日志（log-error=/data/mysql3307/error.log）。
- 使用 SHOW VARIABLES LIKE 'server_id' 验证实例参数。

通过以上方法，可高效、安全地部署和管理多实例 MySQL 环境。

题目 110

The replication for master and slave MySQL Server is up and running .The disk space occupied by the binary log files continues to grow.

Which two methods manage this issue?

A. Execute the FLUSH LOGS statement.

B. Delete all binary log files manually on the file system to release storage space.

C. Execute the PURGE BINARY LOGS statement.

D. On the master server,disable binary logging by removing the --log-bin option

E. Set the binlog_expire_logs_seconds variable.

正确答案

C. Execute the PURGE BINARY LOGS statement.

E. Set the binlog_expire_logs_seconds variable.

关键解析

1. 选项 C：手动清理二进制日志

通过 PURGE BINARY LOGS 命令可以直接删除指定时间点或文件之前的二进制日志，立即释放磁盘空间。

操作示例：

-- 删除 'binlog.000010' 之前的所有日志
PURGE BINARY LOGS TO 'binlog.000010';
-- 删除 3 天前的日志
PURGE BINARY LOGS BEFORE DATE_SUB(NOW(), INTERVAL 3 DAY);

安全性：该命令会根据日志索引文件（mysql-bin.index）清理文件，确保主从复制的连续性。
适用场景：紧急空间释放或临时性清理需求，无需修改全局配置。

2. 选项 E：设置自动清理策略

通过 binlog_expire_logs_seconds 参数可定义二进制日志的保留时间，MySQL 自动触发清理过期文件。

配置方式：

-- 动态设置保留7天（604800秒）
SET GLOBAL binlog_expire_logs_seconds = 604800;

需在 my.cnf 中持久化配置以长期生效。

机制：
- 日志切换（如 FLUSH LOGS 或文件超过 max_binlog_size）时触发自动清理。
- 优先级高于已弃用的 expire_logs_days，且更精确（以秒为单位）。
最佳实践：建议保留时间至少覆盖主从复制的最大延迟期，防止数据丢失。

错误选项排除原因

选项	排除原因
A. `FLUSH LOGS`	仅触发日志轮换（生成新日志文件），不会删除旧文件，无法解决空间问题。
B. 手动删除文件	直接删除文件系统上的日志文件会导致索引不一致，可能破坏主从复制。
D. 禁用二进制日志	主从复制的核心依赖是二进制日志，禁用后复制将中断，属于破坏性操作。

技术扩展与建议

监控与告警：
- 定期检查 SHOW BINARY LOGS 的日志文件大小与数量。
- 结合磁盘空间监控工具（如 df）设置阈值告警。
参数调优：
- max_binlog_size：限制单个日志文件大小（默认1 GB），避免单文件过大。
- binlog_row_image=MINIMAL（仅 MySQL 8.0+）：减少日志记录的数据量。
备份策略：
- 在清理前确保备份已完成，避免因日志删除导致增量恢复失败。

通过以上方法，既可快速释放空间（选项 C），又能长期预防磁盘占用问题（选项 E），符合主从复制环境的安全性与稳定性要求。

题目 111

You administer a three node, single primary InnoDB Cluster.

Examine cluster.status() displayed here:

"statusText": "Cluster is ONLINE and can tolerate up to ONE failure."

Which two statements are true?

A. If two instances are unreachable because of network failure, the cluster will reconfigure to work with a single instance.

B. Reconfiguring the cluster as multi-primary, will increase tolerance to two failures.

C. There is a quorum and transactions can be committed normally.

D. If two instances crash, it will produce an outage.

E. Restarting an arbitrary instance will always provoke primary instance failover.

F. Shutting down two instances with the SHUTDOWN command will produce an outage.

正确答案

C. There is a quorum and transactions can be committed normally.

D. If two instances crash, it will produce an outage.

关键解析

1. 选项 C 正确性分析

当前集群状态显示 "Cluster is ONLINE and can tolerate up to ONE failure"，表明集群处于在线状态且法定人数（Quorum）已达成。在三个节点的单主模式中，法定人数要求至少两个节点在线（即多数，大于 50%）。此时，事务可以正常提交，因为集群满足高可用性要求。因此，选项 C 正确。

2. 选项 D 正确性分析

集群的容错能力为 1 个节点失败。若 2 个节点崩溃，剩余 1 个节点无法形成法定人数（1 < 3/2），导致集群不可用（outage）。因此，选项 D 正确。

错误选项排除原因

选项	排除原因
A	两个节点因网络故障不可达时，剩余节点无法形成多数，集群不会自动重组为单节点运行，而是进入不可用状态。
B	单主模式切换为多主模式不会增加容错能力。仲裁机制仅依赖节点数量，与模式无关，且 InnoDB ClusterSet 明确限制多主模式。
E	仅主节点故障会触发故障转移，重启非主节点不会影响主节点角色。
F	使用 `SHUTDOWN` 命令优雅关闭节点时，集群会自动调整成员关系。若先关闭 2 个节点，剩余 1 个节点仍能形成法定人数（1 = 1/2），集群不会 outage。但题目未明确关闭顺序，存在歧义，故不选。

技术扩展

仲裁机制的核心逻辑
- 三节点集群中，法定人数为 2/3。若两个节点不可用（无论是崩溃或主动关闭），剩余节点无法形成多数，导致服务中断。
- 单主模式下，主节点负责处理写操作，从节点仅支持读操作。若主节点故障，集群会自动选举新主节点。
运维建议
- 监控仲裁状态：通过 cluster.status() 或 SELECT * FROM performance_schema.replication_group_members 实时监控节点状态。
- 避免单点风险：建议部署至少五节点集群以提高容错能力（可容忍两个节点故障）。
- 紧急恢复：若集群因仲裁丢失中断，需手动通过 group_replication_force_members 强制重置成员关系。

通过以上分析，选项 C 和 D 是正确的陈述。

题目 112

Which two MySQL Server accounts are locked by default?

A. any new ROLE accounts

B. any internal system accounts

C. any user created with a username, but missing the host name

D. any user set as DEFINER for stored programs

E. any user created without a password

正确答案

A. any new ROLE accounts

B. any internal system accounts

关键解析

1. 选项 A 正确性分析

在 MySQL 8.0 中，使用 CREATE ROLE 创建的新角色默认是被锁定的，无法直接用于登录数据库。需要手动解锁或激活角色后，用户才能通过该角色访问数据库。例如：

[(none)]> create role 'tom'@'localhost';
Query OK, 0 rows affected (0.01 sec)

[(none)]> select host,user,account_locked from mysql.user where user='tom';
+-----------+------+----------------+
| host      | user | account_locked |
+-----------+------+----------------+
| localhost | tom  | Y              |
+-----------+------+----------------+
1 row in set (0.00 sec)

2. 选项 B 正确性分析

MySQL 初始化时会自动创建以下三个系统账户，并默认锁定（无法通过客户端连接）：

[(none)]> select host,user,account_locked from mysql.user;
+-----------+------------------+----------------+
| host      | user             | account_locked |
+-----------+------------------+----------------+
| localhost | mysql.infoschema | Y              |
| localhost | mysql.session    | Y              |
| localhost | mysql.sys        | Y              |
| localhost | root             | N              |
+-----------+------------------+----------------+
7 rows in set (0.00 sec)

其中：

mysql.infoschema@localhost：用于管理 information_schema 视图的权限隔离。
mysql.session@localhost：供 MySQL 内部插件（如 InnoDB Cluster 或 Group Replication）使用。
mysql.sys@localhost：作为 sys 系统库中对象的定义者（DEFINER），避免直接使用 root 账户带来的安全风险。

这些账户的锁定状态通过 mysql.user 表的 account_locked 列标识（值为 Y）。即使尝试连接，也会返回错误：

Access denied for user 'user_name'@'host_name'. Account is locked.

2. 其他选项排除原因

选项	排除原因
C. 未指定主机名的用户	若用户创建时未指定主机名（如 `user@%`），默认允许从任何主机连接，且不锁定。
D. 存储程序的 DEFINER 用户	仅当存储程序的 `DEFINER` 是系统账户（如 `mysql.sys`）时才默认锁定，并非所有 `DEFINER` 用户均锁定。
E. 无密码用户	没有设置密码的账户不会被锁定。

创建用户并不指定密码：

[(none)]> CREATE USER 'stone'@'localhost';
Query OK, 0 rows affected (0.01 sec)

[(none)]> select host,user,account_locked from mysql.user where user='stone';
+-----------+-------+----------------+
| host      | user  | account_locked |
+-----------+-------+----------------+
| localhost | stone | N              |
+-----------+-------+----------------+
1 row in set (0.00 sec)

技术扩展

锁定账户的意义：
- 防止通过系统账户直接登录，减少攻击面。
- 避免因误操作修改关键系统表（如 mysql.user）。
账户锁定与解锁操作：
- 手动锁定：CREATE USER ... ACCOUNT LOCK 或 ALTER USER ... ACCOUNT LOCK。
- 解锁：ALTER USER ... ACCOUNT UNLOCK。

通过上述分析，选项 A 和 B 是正确的陈述。

题目 113

Examine this command, which executes successfully:

mysqlpump --user=root --password > full_backup.sql

Which two databases will be excluded from this dump?

A. mysql

B. information_schema

C. world

D. employee

E. sys

正确答案

B. information_schema

E. sys

关键解析

1. 默认排除的数据库

mysqlpump 在执行备份时，默认会排除系统数据库 information_schema 和 sys。这是因为：

information_schema：包含关于 MySQL 服务器中所有数据库的元数据信息。它提供了对数据库结构、表、列、索引、权限、状态等信息的只读访问，是 MySQL 中非常重要的元数据查询接口。information_schema 并非真实的物理数据库，其数据来自服务器的内部系统表和运行时状态，不占用实际存储空间。
sys：作为 MySQL 的性能监控工具库，其内容由视图和存储过程动态生成，备份后无法直接恢复，因此默认跳过。

2. 命令行为分析

用户执行的命令 mysqlpump --user=root --password > full_backup.sql 未指定任何排除或包含参数，因此遵循默认行为。此时：

mysql 数据库会被包含在备份中（除非显式排除）。
用户自定义数据库（如 world、employee）也会被包含。

错误选项排除原因

选项	排除原因
A. mysql	`mysql` 数据库存储用户权限和系统表，默认会被备份。
C. world	用户自定义数据库默认包含在备份中。
D. employee	同上，用户自定义数据库默认包含。

技术扩展

mysqlpump 的默认排除机制
- mysqlpump 默认通过参数 --exclude-databases=information_schema,performance_schema,sys 实现系统库的过滤。
- 若需包含这些库，需显式使用 --include-databases 参数。
相关参数应用
- 排除指定库：通过 --exclude-databases=db1,db2 指定排除的数据库。
- 仅备份用户账号：结合 --users 和 --exclude-databases=* 实现。

通过上述分析，选项 B 和 E 是正确的答案。

题目 114

Which three commands can report all the current connections running on the MySQL server?

A. SELECT * FROM performance_schema.events_transactions_current

B. SELECT * FROM performance_schema.threads

C. SHOW FULL PROCESSLIST

D. SELECT * FROM information_schema.processlist

E. SHOW EVENTS

F. SELECT * FROM sys.metrics

G. SELECT * FROM information_schema.events

H. SELECT * FROM sys.statement_analysis

正确答案

B. SELECT * FROM performance_schema.threads

C. SHOW FULL PROCESSLIST

D. SELECT * FROM information_schema.processlist

关键解析

1. 选项 B：performance_schema.threads表

performance_schema.threads 表记录了 MySQL 所有线程的详细信息，包括前台用户连接线程和后台系统线程。该表的关键字段包括：

THREAD_ID：线程唯一标识符。
PROCESSLIST_ID：与 SHOW PROCESSLIST 中的 Id 对应。
PROCESSLIST_USER 和 PROCESSLIST_HOST：连接的客户端用户和主机地址。
PROCESSLIST_DB：当前使用的数据库。
PROCESSLIST_STATE：线程的当前状态（如执行查询、等待锁等）。

通过此表可以查看所有活动连接，但需注意：默认情况下可能需启用相关配置（如 performance_schema 是否开启）。

2. 选项 C：SHOW FULL PROCESSLIST 命令

这是 MySQL 最常用的实时查看当前连接状态的命令。其输出包含以下核心字段：

Id：连接的唯一标识符。
User 和 Host：客户端用户及来源地址。
db：当前使用的数据库。
Command：线程正在执行的命令类型（如 Query、Sleep）。
Time：线程当前状态的持续时间（秒）。
State：线程的详细状态（如 Sending data）。
Info：正在执行的 SQL 语句（若存在）。

此命令直接反映实时连接状态，适合快速诊断高负载或阻塞问题。

3. 选项 D：information_schema.processlist表

information_schema.processlist 表提供与 SHOW FULL PROCESSLIST 相同的信息，但以结构化表的形式呈现，便于通过 SQL 筛选和分析。关键字段包括：

ID：与 SHOW PROCESSLIST 的 Id 对应。
USER 和 HOST：客户端用户及主机地址。
DB 和 COMMAND：当前数据库和线程命令类型。
TIME 和 STATE：线程运行时间和状态。
INFO：完整的 SQL 语句（需使用 FULL 模式）。

此表特别适合通过 SQL 聚合分析（如按用户或主机统计连接数）。

错误选项排除原因

选项	排除原因
A. `events_transactions_current`	仅记录当前事务的事件信息，与连接无关。
E. `SHOW EVENTS`	显示定时任务（Event Scheduler）的配置，不涉及连接状态。
F. `sys.metrics`	提供性能指标汇总，不直接显示连接列表。
G. `information_schema.events`	存储事件（Event）元数据，与连接无关。
H. `sys.statement_analysis`	汇总 SQL 语句性能分析数据，不展示实时连接。

技术扩展

性能监控工具选择：
- SHOW PROCESSLIST 适合快速查看实时连接状态。
- information_schema.processlist 适合通过 SQL 进行自动化监控（如筛选长时间空闲连接）。
- performance_schema.threads 提供更底层线程信息，结合其他表（如 events_statements_current）可分析 SQL 执行细节。
连接管理实践：
- 通过 KILL <Id> 终止异常连接。
- 使用 max_connections 参数限制最大连接数，避免资源耗尽。
- 定期清理长时间 Sleep 状态的空闲连接。

题目 115

Identify three functions of MySQL Enterprise Monitor.

A. Analyze query performance.

B. Start a logical backup.

C. Determine the availability of monitored MySQL servers.

D. Centrally manage users.

E. Start a MySQL Enterprise backup.

F. Centrally manage server configurations.

G. Start and stop MySQL Server.

H. Create customized alerts and provide notification alerts.

正确答案

A. Analyze query performance.

C. Determine the availability of monitored MySQL servers.

H. Create customized alerts and provide notification alerts.

关键解析

1. 选项 A：分析查询性能（Analyze query performance）

MySQL Enterprise Monitor（MEM）的核心功能之一是实时监控并分析 SQL 查询的性能。通过内置的 Query Analyzer，MEM 可以追踪查询的响应时间、执行频率及资源消耗情况，并生成可视化图表帮助用户快速定位低效查询。例如：

通过查询响应时间指标（QRTi）评估查询效率（0-1，1 为最优）。
提供索引使用建议，优化缺失或低效的索引配置。
结合历史数据趋势，预测潜在性能瓶颈。

2. 选项 C：确定被监控 MySQL 服务器的可用性（Determine availability of monitored MySQL servers）

MEM 能够实时监控 MySQL 实例的可用性，确保其符合服务级别协议（SLA）。主要功能包括：

健康检查：持续检测服务器运行状态（如进程存活、端口响应）。
复制拓扑监控：自动发现主从复制架构，并实时监测复制延迟与同步状态。
高可用性集群管理：支持 InnoDB Cluster 与 ClusterSet 的监控，提供故障转移事件的实时警报。

3. 选项 H：创建自定义警报并提供通知（Create customized alerts and provide notification alerts）

MEM 提供灵活的告警配置功能，允许用户根据阈值或条件设置触发规则：

自定义监控项：可针对 CPU 使用率、内存不足、慢查询数量等指标设定告警阈值。
多通道通知：支持邮件、SNMP 协议等方式推送告警信息。
事件关联分析：结合历史数据与上下文，帮助管理员理解告警根源。

错误选项排除原因

选项	排除原因
B. Start a logical backup	逻辑备份由 MySQL Enterprise Backup 或 `mysqldump` 工具实现，MEM 仅监控备份状态而非触发备份操作。
D. Centrally manage users	用户管理属于 MySQL Workbench 或命令行工具（如 `CREATE USER`）的功能，MEM 不涉及此操作。
E. Start a MySQL Enterprise backup	同选项 B，备份操作由独立工具（如 MySQL Enterprise Backup）执行，MEM 仅监控其执行结果。
F. Centrally manage server configurations	配置管理需通过 MySQL Shell 或手动修改 `my.cnf` 文件，MEM 仅提供配置参数的健康检查建议。
G. Start and stop MySQL Server	启停 MySQL 服务需通过系统命令（如 `systemctl`），MEM 无法直接控制服务状态。

技术扩展

MEM架构与部署：
- MEM 由 Service Manager（集中式管理后台）和 Monitor Agent（数据采集代理）组成，支持有代理（收集主机硬件指标）和无代理（仅监控数据库实例）两种部署模式。
集成能力：
- MEM 可与其他 MySQL 产品（如 InnoDB Cluster、Enterprise Backup）集成，提供端到端的监控解决方案。
安全性与合规：
- 结合 MySQL Enterprise Audit 与 Firewall，MEM 可检测权限变更与潜在安全漏洞（如 SQL 注入），满足审计合规要求。

通过以上分析，选项 A、C、H 是 MEM 的核心功能，而其他选项涉及的操作需依赖其他工具或手动完成。

题目 116

Which three actions will secure a MySQL server from network-based attacks?

A. Construct a perimeter network to allow public traffic.

B. Place the MySQL instance behind a firewall.

C. Use network file system (NFS) for storing data.

D. Change the listening port to 3307.

E. Use MySQL Router to proxy connections to the MySQL server.

F. Allow connections from the application server only.

正确答案

B. Place the MySQL instance behind a firewall.

E. Use MySQL Router to proxy connections to the MySQL server.

F. Allow connections from the application server only.

关键解析

1. 选项 B：将 MySQL 实例置于防火墙后

防火墙是防御网络攻击的核心措施，通过规则限制对 MySQL 端口的访问（如仅允许特定 IP 或内网段）。例如：

使用 Linux 的 iptables 或 ufw 工具，仅允许应用服务器 IP 访问 3306 端口。
禁用默认的 0.0.0.0 监听（即配置 bind-address 为内网 IP），减少暴露面。
华为云等云服务商建议通过安全组限制源 IP，仅开放必要端口。

2. 选项 E：使用 MySQL Router 代理连接

MySQL Router 作为中间层代理，可增强安全性：

流量加密：支持 SSL/TLS 加密客户端与 Router 之间的通信，防止数据窃听。
负载均衡与故障转移：自动将请求路由至健康的 MySQL 节点，避免单点故障被攻击利用。
连接池管理：限制并发连接数，防止 DDoS 攻击耗尽数据库资源。
隐藏后端拓扑：对外暴露 Router 的 IP 而非真实数据库 IP，降低直接攻击风险。

3. 选项 F：仅允许应用服务器连接

通过最小化连接来源降低风险：

白名单机制：在MySQL配置文件中设置 bind-address 或使用 --allow-ips 参数，仅允许应用服务器IP访问。例如：

[mysqld]
bind-address = 192.168.1.100# 仅允许该IP连接

防火墙规则细化：结合网络层 ACL（如 iptables），拒绝非授权 IP 的 3306 端口请求。
云环境安全组：在阿里云、华为云等平台，设置安全组仅放行应用服务器所在子网。

错误选项排除原因

选项	排除原因
A. 构建外围网络允许公网流量	外围网络（DMZ）通常用于隔离公网服务（如Web服务器），但直接允许公网访问MySQL会扩大攻击面，违反最小权限原则。
C. 使用 NFS 存储数据	NFS 协议本身存在安全漏洞（如未加密传输），且与网络攻击防护无直接关联，反而可能引入新的攻击向量。
D. 修改监听端口为 3307	通过“隐蔽性”增强安全（Security through obscurity）不可靠，端口扫描工具可快速发现新端口。

技术扩展

分层防御策略：
- 网络层：防火墙 + VPN/VPC 隔离。
  - 传输层：强制 SSL 加密（REQUIRE SSL）。
  - 应用层：MySQL Enterprise Firewall 过滤异常 SQL 模式。
自动化监控：
- 通过工具（如 Prometheus + Grafana）实时监控连接数、慢查询等指标。
  - 结合日志分析（如 ELK Stack）检测异常登录或 SQL 注入尝试。

通过以上措施，可构建多层次的 MySQL 网络安全防护体系，有效抵御端口扫描、暴力破解、DDoS 等攻击。

题目 117

Which two statements are true about MySQL server multi-source replication?

A. It must use GTID replication.

B. It is not compatible with auto- positioning.

C. It needs to be re-instanced after a crash to maintain consistency.

D. It uses only time-based replication conflict resolution.

E. It does not attempt to detect or resolve replication conflicts.

F. It relies on relay_log_recovery for resilient operations.

正确答案

E. It does not attempt to detect or resolve replication conflicts.

F. It relies on relay_log_recovery for resilient operations.

关键解析

1. 选项 E：多源复制不尝试检测或解决复制冲突

MySQL 多源复制的核心设计是将多个主库的数据并行复制到单个从库，但不会自动处理数据冲突。其应用场景需满足以下条件之一：

数据无冲突：各主库操作完全独立的数据（例如不同数据库或表分片）。
冲突由应用层解决：例如在跨地域同步场景中，业务逻辑需自行处理冲突（如时间戳覆盖或唯一键约束）。

示例场景：主库 A 负责用户表，主库 B 负责订单表，从库聚合两类数据时无需冲突检测。

2. 选项 F：依赖 relay_log_recovery 实现高可用性

多源复制的容错机制依赖于relay_log_recovery参数，该参数在从库崩溃恢复时确保中继日志的完整性：

中继日志恢复机制：若从库异常宕机，重启后通过 relay_log_recovery=ON 自动定位未处理的中继日志位置，避免数据丢失或重复。
多线程复制的协调：结合 replica_parallel_workers 参数，每个复制通道独立管理线程池，确保并行复制的稳定性。

错误选项排除原因

选项	排除原因
A. 必须使用 GTID 复制	多源复制支持 GTID 和基于二进制日志位置两种复制方式，例如配置时可通过 `MASTER_AUTO_POSITION=1`（GTID）或手动指定 `MASTER_LOG_FILE` 和 `MASTER_LOG_POS` （传统方式）。
B. 不兼容自动定位	GTID 模式下，可通过 `MASTER_AUTO_POSITION=1` 实现自动定位主库事务位置，与多源复制完全兼容。
C. 崩溃后需重新实例化	从库崩溃后可通过 `relay_log_recovery` 和 GTID 自动恢复，无需重新全量同步。
D. 仅基于时间的冲突解决	MySQL 未内置任何冲突解决机制（包括时间戳），冲突完全依赖应用层处理。

技术扩展

多源复制的典型配置步骤：
- 主库配置：开启 GTID（gtid_mode=ON）和二进制日志（log-bin）。
- 从库配置：设置 master_info_repository=TABLE 和 relay_log_info_repository=TABLE，确保多通道元数据持久化。
- 添加主库通道：
```
CHANGE MASTER TO MASTER_HOST='主库A', MASTER_USER='repl', ... FOR CHANNEL 'channel-A';
CHANGE MASTER TO MASTER_HOST='主库B', MASTER_USER='repl', ... FOR CHANNEL 'channel-B';
```
- 启动多线程复制：SET GLOBAL replica_parallel_workers=4;
监控与管理工具：
- 性能视图：通过 performance_schema.replication_connection_status 查看各通道状态。
- 命令操作：使用 START/STOP SLAVE FOR CHANNEL 'channel-A' 控制单个通道。
冲突规避策略：
- 分库分表：各主库操作独立数据库或表分片。
- 业务逻辑隔离：例如通过地域或业务线划分主库写入范围。

通过以上分析，选项 E 和 F 为正确答案，其他选项均与 MySQL 多源复制的实际机制相悖。

题目 118

Which two statements are true about using MySQL Enterprise Monitor Query Analyzer?

A. It is possible to retrieve a normalized statement, but never the exact statement that was executed.

B. The single query QRTi pie chart in the Query Analyzer view is based on the average execution of all statements.

C. It is possible to import data into the Query Analyzer from heterogeneous sources, such as CSV

D. It is possible to list and analyze statements in an arbitrary graph range selection from timeseries graphs.

E. It is possible to configure the Query Analysis built-in advisor to get notified about slow query execution.

正确答案

D. It is possible to list and analyze statements in an arbitrary graph range selection from timeseries graphs.

E. It is possible to configure the Query Analysis built-in advisor to get notified about slow query execution.

关键解析

1. 选项 D：支持从时间序列图选择任意时间范围分析语句

MySQL Enterprise Monitor Query Analyzer 提供灵活的时间序列图功能，允许用户通过交互式图表选择特定时间段，并查看该时间段内所有执行的 SQL 语句的详细性能数据。例如：

在时间序列图中，用户可以通过拖动时间轴选择任意区间（如上午 10:00 至下午 2:00），Query Analyzer 会自动筛选并展示该区间内的所有查询及其性能指标（如执行次数、平均延迟、QRTi 等）。
这一功能特别适用于排查特定时间段内的性能波动或异常查询。

2. 选项 E：可配置内置顾问接收慢查询通知

Query Analyzer 支持自定义告警规则，用户可以通过设置阈值触发慢查询通知：

例如，当某个查询的 QRTi（Query Response Time index）低于设定阈值（如 0.5）时，系统会自动通过邮件或 SNMP 发送告警。
告警规则支持基于执行时间、临时表使用、全表扫描等条件配置，帮助管理员实时监控潜在性能问题。

错误选项排除原因

选项	排除原因
A. 仅能检索规范化语句，无法获取实际执行语句	Query Analyzer 虽然会对 SQL 进行规范化（去除具体参数），但通过点击查询详情页可查看实际执行的示例语句及 EXPLAIN 计划。
B. QRTi 饼图基于所有语句的平均执行时间	QRTi 饼图并非基于平均值，而是根据查询在最佳（绿色）、可接受（黄色）、不可接受（红色）三个时间段的执行次数占比计算得出。
C. 支持从 CSV 等异构数据源导入数据	Query Analyzer 的数据来源于 MySQL 服务器的 Performance Schema 和代理采集，不支持外部数据导入（如 CSV）。

技术扩展

QRTi 计算逻辑
- QRTi 值是基于查询在不同时间段的执行次数计算的加权平均值。例如：
  - 若某查询在最佳时间范围内执行了 60 次，可接受范围内 30 次，不可接受范围内 10 次，则其 QRTi 为 (60×1 + 30×0.5 + 10×0)/100 = 0.75。
- 这一指标直观反映查询的整体响应效率，低 QRTi 值通常意味着较多慢查询。
时间序列图与动态分析
- 用户可通过时间序列图观察查询的执行趋势（如高峰期延迟突增），并结合过滤条件（如数据库名、查询类型）快速定位问题。
- 图表支持联动筛选，例如选择高延迟时段后，下方列表自动展示该时段内所有相关查询的详细信息。
告警与自动化优化
- 除了慢查询告警，Query Analyzer 还提供索引建议和配置优化提示（如临时表配置或锁等待超时调整）。
- 结合 MySQL Enterprise Monitor 的全局监控能力，可实现从查询分析到资源调优的全链路性能管理。

通过以上分析，选项 D 和 E 为正确答案，其他选项均与 Query Analyzer 的实际功能不符。

题目 119

You must export data from a set of tables in the world_x database.

Examine this set of tables:

Tables (country, countryinfo, location)

Which two options will export data into one or more files?

A. shell> mysqldump world_x country countryinfo location > mydump.sql

B. mysql> SELECT * INTO OUTFILE '/output/country. txt' FROM world_x.country; mysql> SELECT * INTO OUTFILE '/output/countryinfo. txt' FROM world_x.countryinfo; mysql> SELECT * INTO OUTFILE '/output/location. txt' FROM world_x.location;

C. shell> mysqlexport world_x country countryinfo location > mydump.sql

D. mysql> CLONE LOCAL DATA DIRECTORY = '/var/lib/mysql/world_x/country'; mysql> CLONE LOCAL DATA DIRECTORY = '/var/lib/mysql/world_x/countryinfo'; mysql> CLONE LOCAL DATA DIRECTORY = '/var/lib/mysql/world_x/location' ;

E. shell> mysql --batch world_x.country world_x.countryinfo world_x.1ocation > mydump.sql

正确答案

A. shell> mysqldump world_x country countryinfo location > mydump.sql

关键解析

1. 选项 A：mysqldump 导出多个表到单个文件

mysqldump 是 MySQL 官方推荐的逻辑备份工具，支持导出单个数据库中的多个表数据到一个文件。其核心功能包括：

多表导出：通过命令行直接列出表名（如 country, countryinfo, location），所有表的数据和结构会被合并到指定文件中（如 mydump.sql）。
事务一致性：若使用 --single-transaction 选项，可在 InnoDB 引擎下实现一致性快照导出，避免锁表。
灵活格式：默认导出 SQL 语句（含表结构和数据），可通过 --no-create-info 仅导出数据。

示例命令：

shell> mysqldump world_x country countryinfo location > mydump.sql

该命令会将三张表的数据和结构整合到 mydump.sql 文件中。

2. 选项 B：SELECT ... INTO OUTFILE 导出多表到多个文件

SELECT ... INTO OUTFILE 是 MySQL 原生 SQL 语句，用于将查询结果直接写入文件系统，每张表生成一个独立文件。其特点包括：

按表导出：每个 SELECT 语句对应一个文件（如 /output/country.txt、/output/countryinfo.txt 等），文件格式可自定义（如 CSV）。
精确控制：可指定字段分隔符（FIELDS TERMINATED BY）、行结束符（LINES TERMINATED BY）等，适合与其他系统（如 Excel 或 Hive）交互。
权限要求：需确保 MySQL 用户有 FILE 权限，且输出目录对 MySQL 服务可写。

示例命令：

mysql> SELECT * INTO OUTFILE '/output/country.txt' FROM world_x.country;
mysql> SELECT * INTO OUTFILE '/output/countryinfo.txt' FROM world_x.countryinfo;
mysql> SELECT * INTO OUTFILE '/output/location.txt' FROM world_x.location;

此操作会为每张表生成一个独立文本文件。

错误选项排除原因

选项	排除原因
C. `mysqlexport`	`mysqlexport` 并非 MySQL 官方工具，搜索结果中未提及该命令。
D. `CLONE LOCAL DATA DIRECTORY`	`CLONE` 语句用于克隆整个数据库或表空间，而非导出特定表数据到文件。
E. `mysql --batch`	`--batch` 仅改变输出格式（如去除边框），不会生成结构化数据文件，且无法按表拆分。

技术扩展

适用场景对比：
- mysqldump：适合全量备份或迁移，支持跨版本兼容，但大表导出可能较慢。
- SELECT ... INTO OUTFILE：适合按需导出部分数据或定制格式，但需手动管理文件命名和权限。
性能优化：
- 使用 --quick 选项减少内存占用（大表导出时）。
- 结合压缩工具（如 gzip）减少导出文件体积。
安全建议：
- 避免将文件输出到 Web 可访问目录，防止数据泄露。
- 定期清理临时导出文件，避免磁盘空间耗尽。

通过以上分析，选项 A 和 B 为正确答案，分别对应单文件批量导出和多文件按需导出的场景。

题目 120

Which are three benefits of using mysqlbackup instead of mysqldump?

A. mysqlbackup can perform partial backup of stored programs.

B. mysqlbackup allows logical backups with concurrency resulting in faster backups and restores.

C. mysqlbackup integrates tape backup and has the virtual tape option.

D. mysqlbackup can back up tables with the InnoDB engine without blocking reducing wait times due to contention.

E. mysqlbackup does not back up MySQL system tables, which shortens backup time.

F. mysqlbackup restores data from physical backups, which are faster than logical backups.

正确答案

C. mysqlbackup integrates tape backup and has the virtual tape option.

D. mysqlbackup can back up tables with the InnoDB engine without blocking, reducing wait times due to contention.

F. mysqlbackup restores data from physical backups, which are faster than logical backups.

关键解析

1. 选项 C：支持磁带备份与虚拟磁带选项

MySQL Enterprise Backup（mysqlbackup）提供与磁带备份系统的集成能力，支持将备份直接写入虚拟磁带（Virtual Tape）或物理磁带。这一功能特别适用于企业级数据归档和长期存储需求。例如，通过 --backup-image 选项可将备份生成镜像文件，并兼容磁带存储格式，简化大规模数据的管理流程。

2. 选项 D：非阻塞备份InnoDB表

mysqlbackup 通过热备份（Hot Backup）机制实现对 InnoDB 表的无锁备份。其核心原理是：

基于 LSN（Log Sequence Number）：在备份过程中，通过记录Redo Log的 LSN 点，确保数据一致性，同时允许 DML 操作继续执行，无需全局锁表。
并行处理：支持多线程备份（如 --parallel 选项），显著减少备份时间，避免因锁争用导致的性能瓶颈。

相比之下，mysqldump 在备份InnoDB表时需使用 --single-transaction 选项实现一致性快照，但若涉及 DDL 操作仍可能阻塞写入。

3. 选项 F：物理备份恢复更快

物理备份直接复制数据文件（如 .ibd 和 ibdata），恢复时仅需文件拷贝，无需重建 SQL 语句，因此速度远快于逻辑备份。例如：

恢复效率对比：物理备份恢复时间与数据量成线性关系，而逻辑备份需逐行执行 INSERT 语句并重建索引，耗时可能增加数倍。
适用场景：对于 TB 级数据库，mysqlbackup 的物理备份恢复时间通常比 mysqldump 缩短 90% 以上。

错误选项排除原因

选项	排除原因
A. 支持部分备份存储程序	`mysqlbackup` 的“部分备份”指按表或库筛选（如 `--include` 或 `--databases`），而非仅备份存储过程。存储程序的备份仍需全库逻辑导出。
B. 逻辑备份并发加速	`mysqlbackup` 本质是物理备份工具，其性能优势源于直接操作文件而非逻辑导出，因此“逻辑备份并发”描述错误。
E. 不备份系统表以缩短时间	`mysqlbackup` 默认备份所有系统表（如 `mysql` 库中的权限表），且系统表备份是恢复元数据的关键步骤，此选项与实际情况相悖。

技术扩展

物理备份的容灾优势
- mysqlbackup 支持增量备份（基于 LSN 差异），仅备份自上次全量后的变更数据，显著减少备份数据量。结合 apply-log 和 copy-back 命令，可实现高效恢复。
与存储引擎的深度集成
- mysqlbackup 直接解析 InnoDB 表空间文件，确保备份与存储引擎的内部结构兼容，避免因版本差异导致的数据损坏。
企业级功能
- 加密与压缩：支持备份文件加密（AES-256）和压缩（如 --compress 选项），兼顾安全性与存储成本。
- 自动化监控：通过 mysql.backup_history 表记录备份历史，便于审计与故障排查。

通过以上分析，选项 C、D、F 为正确答案，体现了 mysqlbackup 在企业级备份场景中的核心优势。

题目 121

All MySQL Server instances belonging to InnoDB Cluster have SSL configured and enabled. You must configure InnoDB Cluster to use SSL for group communication.

Which two statements are true?

A. An existing InnoDB Cluster must be dissolved and created from scratch to enable SSL for group communication.

B. If only some InnoDB Cluster members are enabled for SSL group communication, and --ssl-mode=PREFERRED, communication will fall back to unencrypted connection.

C. SSL group communication must be enabled at cluster creation time by specifying createCluster ({memberSslMode: 'REQUIRED'}).

D. SSL group communication can be enabled for an existing cluster, one instance at time, by setting group_replication_ssl_mode.

E. SSL group communication requires the use of an additional set of parameters group_replication_recovery_*.

F. Configuring SSL group communication also configures SSL distributed recovery.

正确答案

C. SSL group communication must be enabled at cluster creation time by specifying createCluster ({memberSslMode: 'REQUIRED'}).

D. SSL group communication can be enabled for an existing cluster, one instance at a time, by setting group_replication_ssl_mode.

关键解析：

1. 选项 C：在创建集群时必须通过 createCluster({memberSslMode: 'REQUIRED'}) 启用 SSL 组通信

正确原因：根据MySQL 官方文档，InnoDB Cluster 支持在创建时通过 memberSslMode 参数强制 SSL 通信。例如，使用 mysqlsh 工具创建集群时，可以通过以下方式指定 SSL 模式：
```
mysqlsh --uri root@localhost:3306 -e "dba.createCluster('mycluster', {memberSslMode: 'REQUIRED'})"
```
这会确保所有成员在加入集群时必须使用 SSL 加密通信。

2. 选项 D：可以为现有集群逐个实例启用 SSL 组通信，通过设置 group_replication_ssl_mode

正确原因：MySQL 支持在集群运行时动态修改 SSL 模式。对于已存在的集群，可以通过以下步骤逐个实例启用 SSL：
- 修改实例的 group_replication_ssl_mode 参数（如 REQUIRED）。
- 重启实例或重新加入集群。
- 确保所有实例均启用 SSL 后，集群的组通信将强制使用加密。

排除其他选项的原因

1. 选项 A: 必须解散现有集群并从头开始创建以启用 SSL 组通信

错误原因：MySQL InnoDB Cluster 支持 动态修改 SSL 配置，无需解散集群。例如，可以通过 Cluster.setOption() 或直接修改 group_replication_ssl_mode 参数来启用 SSL。

2. 选项 B: 如果部分成员启用 SSL 组通信且 --ssl-mode=PREFERRED，通信将回退到非加密连接

错误原因：Group Replication 要求所有成员使用一致的 SSL 模式。如果部分成员未启用 SSL，即使设置 --ssl-mode=PREFERRED，通信也会失败（而非回退），因为组复制依赖于所有成员的同步。

3. 选项 E: SSL 组通信需要额外的参数 group_replication_recovery_*

错误原因：group_replication_recovery_* 参数用于 分布式恢复（如故障转移时的自动数据同步），而非组通信本身。SSL 组通信的核心参数是 group_replication_ssl_mode。

4. 选项 F: 配置 SSL 组通信也会配置 SSL 分布式恢复

错误原因：分布式恢复的 SSL 配置需要单独启用。例如，需在 my.cnf 中设置 group_replication_recovery_use_ssl=1，与组通信的 SSL 模式无关。

总结：

选项 C 和 D 是正确答案：
- C：创建集群时可通过 memberSslMode 强制 SSL 通信。
- D：可逐个实例启用 SSL，无需解散集群。
其他选项（A、B、E、F）均不符合 MySQL InnoDB Cluster 的实际配置逻辑或知识库描述。

题目 122

After installing MySQL 8.0 on Oracle Linux 7, you initialize the data directory with the mysqld --initialize command.

Which two will assist in locating the root password?

A. the root_pw variable stored in the mysql.install table

B. the root password displayed on the screen via a [Warning] message

C. the root password inserted in the error log set by the --log-error=[file_name] variable

D. the root password written to the /root/.my.cnf file

E. as root, executing the SHOW PASSWORD command by using the SHA-256 password encryption plugin

正确答案

B. the root password displayed on the screen via a [Warning] message

C. the root password inserted in the error log set by the --log-error=[file_name] variable

关键解析

1. 选项 B：通过 [Warning] 消息在屏幕上显示的 root 密码

当使用 mysqld --initialize 命令初始化 MySQL 数据目录时，若未显式指定 --console 参数，临时密码通常不会直接显示在控制台。但根据实际安装流程，某些环境（如 Oracle Linux 7）或特定配置下，初始化过程中可能仍会以警告（Warning）或提示（Note）的形式在控制台输出临时密码。例如：

在初始化命令执行后，控制台可能显示类似 [Note] A temporary password is generated for root@localhost: xxxxxx 的信息。
若未看到密码，需结合错误日志进一步验证。

2. 选项 C：通过 --log-error 参数设置的错误日志中的 root 密码

无论是否显式指定 --log-error 参数，MySQL 初始化时默认会将临时密码写入错误日志文件。具体表现为：

默认错误日志路径：通常位于数据目录（如 /var/lib/mysql）下的 .err 文件（如 hostname.err）或系统日志目录 /var/log/mysqld.log。
显式指定日志路径：若通过 --log-error=file_name 自定义错误日志位置，密码将写入该文件。

例如，通过以下命令可快速定位密码：

grep 'temporary password' /var/log/mysqld.log

错误选项排除原因

选项	排除原因
A. `mysql.install` 表中的 `root_pw` 变量	`mysql.install` 表不存在，MySQL 用户密码存储于 `mysql.user` 表，且初始化时不会生成此类变量。
D. `/root/.my.cnf` 文件中的密码	`.my.cnf` 是用户自定义配置文件，初始化流程不会自动写入密码。
E. 使用 `SHOW PASSWORD` 命令	`SHOW PASSWORD` 并非有效 MySQL 命令，且 SHA-256 插件不提供此功能。

技术扩展

初始化参数差异
- --initialize 与 --initialize-insecure：前者生成随机临时密码并写入错误日志；后者不生成密码（需手动设置）。
- --console 参数的作用：显式要求 MySQL 将初始化日志输出到控制台，便于直接查看临时密码。
密码安全实践
- 首次登录后需立即修改密码，否则无法执行任何操作。
- 密码复杂度要求：需包含大小写字母、数字和特殊字符（可通过调整 validate_password 策略放宽限制）。
错误日志管理
- 默认路径：数据目录下的 .err 文件（如 /var/lib/mysql/hostname.err）。
- 手动定位：若未找到日志文件，可通过 SHOW VARIABLES LIKE 'log_error%'; 查询当前配置路径。

通过以上分析，选项 B 和 C 为正确答案，分别对应控制台输出（特定场景）和错误日志中的密码记录。

题目 123

Identify two ways to significantly improve data security.

A. Configure mysqld to run as the system admin account, such as root.

B. Use a private network behind a firewall.

C. Configure mysqld to use only networked disks.

D. Configure MySQL to have only one administrative account.

E. Configure mysqld to use only local disks or attached disks and to have its own account in the host system.

正确答案

B. Use a private network behind a firewall.

E. Configure mysqld to use only local disks or attached disks and to have its own account in the host system.

关键解析

1. 选项 B：使用防火墙后的私有网络

通过将 MySQL 服务器部署在私有网络并配置防火墙规则，可以有效限制对数据库的非法访问，显著降低外部攻击风险。具体优势包括：

网络隔离：仅允许受信任的 IP 地址或内部服务访问数据库端口（如 3306），阻止公网扫描和恶意连接。
防止中间人攻击：私有网络结合防火墙可减少数据传输过程中被窃听或篡改的可能性，尤其是在未启用 SSL/TLS 加密的场景下。
合规性支持：符合企业级安全架构要求，适用于金融、医疗等敏感行业的数据保护需求。

2. 选项 E：限制存储为本地或附加磁盘，并为 MySQL 创建独立系统账户

此措施从存储安全和权限控制两方面提升数据库安全性：

存储隔离：使用本地磁盘或专用附加存储（如 SAN/NAS）可避免网络磁盘（如 NFS）因配置不当导致的未授权访问或数据泄露。
最小权限原则：为 MySQL 服务创建独立的系统账户（如 mysql 用户），而非默认使用 root 账户运行，可限制潜在攻击的横向扩散。例如，若攻击者通过 SQL 注入获取文件系统权限，独立账户的权限将被严格限制在数据库相关目录。
防止提权攻击：独立账户减少了因服务漏洞导致操作系统级提权的可能性，符合安全加固的最佳实践。

错误选项排除原因

选项	排除原因
A. 以 `root` 账户运行 `mysqld`	以 `root` 运行 MySQL 服务会赋予攻击者最高系统权限，极大增加提权和数据泄露风险。所有安全指南均建议使用非特权账户运行数据库服务。
C. 仅使用网络磁盘	网络磁盘（如云存储或共享存储）若未加密或配置 ACL，可能暴露数据路径，增加中间人攻击或未授权访问风险。本地存储更可控。
D. 仅保留一个管理账户	虽然减少管理员账户数量可简化权限管理，但关键点在于权限分配的精细度（如 RBAC），而非单纯数量限制。单一账户可能成为单点故障。

技术扩展

防火墙与私有网络的最佳实践
- 白名单策略：仅允许应用服务器和运维终端访问 MySQL 端口，拒绝其他所有流量。例如，使用 iptables 或云平台安全组实现。
- VPN 隧道：对于跨地域访问，可通过 VPN 建立加密通道，避免直接暴露数据库到公网。
存储与账户安全强化
- 文件系统权限：确保 MySQL 数据目录（如 /var/lib/mysql）权限设置为 mysql:mysql，避免其他用户读取敏感文件（如 ibdata1 或 *.ibd）。
- 磁盘加密：对本地磁盘使用 LUKS 或 BitLocker 加密，防止物理设备丢失导致的数据泄露。
综合防御体系
- 结合 SSL/TLS 加密传输（如配置 require_secure_transport=ON）和定期漏洞扫描，形成多层次防护。
- 通过审计日志（如启用 audit_log 插件）监控异常连接和操作，及时发现潜在威胁。

通过以上措施，选项 B 和 E 能够显著提升 MySQL 数据安全性，同时符合企业级安全架构的要求。

题目 124

Which two are valid uses for binary logs on a MySQL instance?

A. recording the order in which queries are issued

B. audit of all queries

C. point-in-time recovery

D. replication

E. logging the duration and locks for all queries

正确答案

C. point-in-time recovery

D. replication

关键解析

1. 选项 C：时间点恢复（Point-in-Time Recovery）

二进制日志（Binary Log）记录了所有对数据库的数据修改操作（如 INSERT、UPDATE、DELETE），这使得可以通过回放日志中的事件将数据库恢复到某个特定时间点。例如：

全量备份结合增量恢复：若数据库因误操作导致数据丢失，可以先用全量备份恢复基础数据，再通过二进制日志回放备份时间点之后的事件，精确恢复到误操作前的状态。
基于事件位置的恢复：通过 mysqlbinlog 工具解析日志中的事件位置（如 --start-position 和 --stop-position），选择性地应用日志片段。

2. 选项 D：复制（Replication）

二进制日志是实现主从复制（Master-Slave Replication）的核心组件：

主库记录变更：主库将所有数据修改事件写入二进制日志。
从库同步数据：从库通过 I/O 线程读取主库的二进制日志并写入本地中继日志（Relay Log），再由 SQL 线程重放事件，保持数据一致性。
高可用与负载均衡：通过多副本架构分散读请求，提升系统性能和容灾能力。

错误选项排除原因

选项	排除原因
A. 记录查询顺序	二进制日志仅记录数据修改操作（如 DDL/DML），不记录 `SELECT` 等纯查询操作，因此无法用于追踪查询顺序。
B. 审计所有查询	审计所有查询需依赖通用查询日志（General Query Log）或慢查询日志（Slow Query Log），而二进制日志仅记录数据变更，无法覆盖所有查询。
E. 记录查询持续时间和锁信息	此类信息属于性能监控或事务分析的范畴，需通过 `SHOW ENGINE INNODB STATUS` 或慢查询日志获取，二进制日志不记录这些细节。

技术扩展

二进制日志格式与性能优化
- 格式选择：
  - STATEMENT：记录 SQL 语句，日志量小但可能因非确定性函数导致主从不一致。
  - ROW（推荐）：记录行级变更，数据一致性高但日志量大。
  - MIXED：混合模式，根据操作类型自动选择格式。
- 日志管理：
- 通过 max_binlog_size 控制单个日志文件大小，避免文件过大影响性能。
- 使用 expire_logs_days 自动清理过期日志，节省存储空间。
主从复制的容灾实践
- GTID（全局事务标识符）：通过唯一事务 ID 简化复制拓扑管理，避免因日志文件名或位置变化导致同步中断。
- 半同步复制（Semi-Synchronous Replication）：确保事务提交后至少一个从库确认接收日志，提升数据可靠性。
与存储引擎的协作
- InnoDB Redo Log：二进制日志与存储引擎的 Redo Log 分工协作，前者用于跨实例数据同步，后者确保事务的持久性和崩溃恢复。
- 物理备份与逻辑备份结合：物理备份（如 mysqlbackup）加速恢复，二进制日志补充增量变更，形成完整的灾备方案。

通过以上分析，选项 C 和 D 为正确答案，体现了二进制日志在数据恢复和分布式架构中的核心作用。

题目 125

Which two are features of MySQL Enterprise Firewall?

A. blocking of potential threats by configuring pre-approved whitelists

B. modifying SQL statement dynamically with substitutions

C. recording incoming SQL statement to facilitate the creation of a whitelist of permitted commands

D. automatic locking of user accounts who break your firewall

E. provides stateless firewall access to TCP/3306

正确答案

A. blocking of potential threats by configuring pre-approved whitelists

C. recording incoming SQL statement to facilitate the creation of a whitelist of permitted commands

关键解析

1. 选项 A：通过预定义白名单阻止潜在威胁

MySQL 企业防火墙（MySQL Enterprise Firewall）的核心功能是基于白名单的防护机制。通过配置预定义的允许规则（白名单），防火墙会拦截所有不符合规则的 SQL 语句，从而阻止潜在的恶意攻击（如 SQL 注入）。例如：

在 PROTECTING 模式下，防火墙会将用户提交的 SQL 语句与白名单中的规则进行匹配。若未匹配，则直接拒绝执行并记录错误日志。
白名单规则基于 SQL 语句的规范化格式（digest），例如 SELECT * FROM t1 WHERE c1 = ?，从而覆盖同一类操作的不同参数值。

2. 选项 C：记录传入的 SQL 语句以生成白名单

防火墙提供 RECORDING 模式，用于学习和生成白名单。在此模式下，所有用户执行的 SQL 语句会被记录并转换为规范化格式，形成白名单规则。例如：

管理员可以通过训练阶段（模拟正常业务操作）自动收集合法的 SQL 语句模式。
生成的规则存储在系统表（如 mysql.firewall_whitelist）中，后续可切换至保护模式（PROTECTING）以启用拦截功能。

错误选项排除原因

选项	排除原因
B. 动态替换修改 SQL 语句	MySQL 防火墙仅负责匹配或拦截 SQL 语句，不会动态修改其内容。该功能属于应用层逻辑或代理工具（如 ProxySQL）的范畴，与防火墙无关。
D. 自动锁定违规用户账户	防火墙仅控制 SQL 语句的执行权限，不涉及账户锁定。账户锁定需通过其他机制（如 `max_connection_errors` 或审计插件）实现。
E. 提供对 TCP/3306 端口的无状态防火墙访问	此功能属于网络防火墙（如 `iptables` 或云安全组）的职责，而 MySQL 企业防火墙是应用层防火墙，专注于 SQL 语句的合法性验证，与端口访问控制无关。

技术扩展

防火墙模式与工作流程
- RECORDING 模式：学习合法 SQL 模式，生成白名单规则。
- PROTECTING 模式：严格拦截非白名单语句，保护数据库安全。
- DETECTING 模式：记录可疑语句但不拦截，用于灰度测试。
白名单规则管理
- 规则存储于 mysql.firewall_whitelist 表中，支持通过存储过程（如 sp_reload_firewall_rules()）动态加载。
- 管理员可手动调整规则或重新训练以适应业务变化。
性能与安全平衡
- 规范化规则：通过 SQL 摘要（digest）减少规则数量，避免因参数变化导致规则爆炸。
- 参数 max_digest_length：需合理设置以支持长 SQL 语句的规范化处理。

通过上述分析，选项 A 和 C 为正确答案，体现了 MySQL 企业防火墙在主动防御与智能学习方面的核心能力。

题目 126

Which three methods display the complete table definition of an InnoDB table?

A. hexdump -v -C table.frm

B. REPAIR TABLE table USE_FRM

C. mysqldump --no-data schema table

D. Query the Information Schema.

E. SELECT * FROM table 1\G

F. SHOW CREATE TABLE

正确答案

C. mysqldump --no-data schema table

D. Query the Information Schema.

F. SHOW CREATE TABLE

关键解析

1. 选项 C：mysqldump --no-data schema table

使用 mysqldump 工具配合 --no-data 参数可以导出表的完整结构定义（包括列定义、索引、存储引擎、字符集等），但不包含数据。例如：

mysqldump -u root -p --no-data your_database your_table

生成的 SQL 脚本中包含 CREATE TABLE 语句，清晰展示表的所有属性。

2. 选项 D：查询信息模式（Information Schema）

通过查询 INFORMATION_SCHEMA.TABLES 和 INFORMATION_SCHEMA.COLUMNS 等系统表，可以获取表的元数据信息，例如列名、数据类型、约束、存储引擎等。示例查询：

SELECT * FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA = 'your_database' AND TABLE_NAME = 'your_table';

该方式支持灵活筛选和格式化输出，适用于自动化脚本或复杂分析。

3. 选项 F：SHOW CREATE TABLE

直接执行 SHOW CREATE TABLE 命令会返回创建表的完整 SQL 语句，包含所有结构细节（如主键、外键、索引、存储引擎、行格式等）。例如：

SHOW CREATE TABLE your_table \G

参数 \G 可优化显示格式，便于阅读。

错误选项排除原因

选项	排除原因
A. `hexdump -v -C table.frm`	InnoDB 表在 MySQL 8.0 后不再依赖 `.frm` 文件存储结构（系统表已全面转为 InnoDB 引擎），因此无法通过此方式获取定义。
B. `REPAIR TABLE table USE_FRM`	该命令用于修复表数据而非显示结构，且仅适用于 MyISAM 引擎，与 InnoDB 无关。
E. `SELECT * FROM table 1\G`	此命令仅查询表中的数据行，不涉及表结构信息。

技术扩展

mysqldump 的进阶用法
- 添加 --compact 参数可简化输出，移除注释和版本信息。
- 结合 --skip-add-drop-table 避免生成 DROP TABLE 语句，防止误操作。
信息模式（Information Schema）的深度应用
- 联合查询 INNODB_SYS_TABLES 和 INNODB_SYS_INDEXES 可获取 InnoDB 内部存储细节（如表空间 ID、索引类型）。
- 通过 COLUMN_DEFAULT 字段可查看列的默认值约束。
SHOW CREATE TABLE 的隐藏信息
- 输出中包含表的字符集（CHARSET）和校对规则（COLLATE），对多语言环境部署至关重要。
- 若表使用动态行格式（ROW_FORMAT=DYNAMIC），输出中会明确标注。

通过以上分析，选项 C、D、F 为正确答案，覆盖了从命令行工具到 SQL 查询的多种表定义查看方式。

题目 127

Which two statements are true about the mysql_config_editor program?

A. It provides an interface to change my.cnf files.

B. It can move datadir to a new location.

C. It will use [client] options by default unless you provide --login-path.

D. It can be used to create and edit SSL certificates and log locations.

E. It manages the configuration of user privileges for accessing the server.

F. It manages the configuration of the MySQL Firewall feature.

G. It manages the configuration of client programs.

正确答案

C. It will use [client] options by default unless you provide --login-path.

G. It manages the configuration of client programs.

关键解析

1. 选项 C：默认使用 [client] 配置组，除非指定 --login-path

mysql_config_editor 默认操作的是名为 [client] 的登录路径。例如：

当执行 mysql_config_editor set 命令时，若未通过 --login-path 指定名称，配置将写入 [client] 组。
客户端程序（如 mysql）默认也会读取 [client] 组的配置，除非通过 --login-path 显式指定其他路径。

2. 选项 G：管理客户端程序的配置

mysql_config_editor 的核心功能是管理客户端程序的连接配置，包括加密存储用户名、密码、主机、端口等信息到 .mylogin.cnf 文件中。例如：

通过 set 命令创建登录路径后，客户端程序（如 mysql、mysqldump）可直接使用 --login-path=name 连接数据库，避免在命令行中明文输入密码。
该工具还支持查看（print）、删除（remove）和重置（reset）配置，覆盖客户端连接的完整生命周期管理。

错误选项排除原因

选项	排除原因
A. 修改 `my.cnf` 文件	`mysql_config_editor` 操作的是 `.mylogin.cnf` 文件，而非 `my.cnf`。前者专门存储加密的客户端登录信息，后者是全局配置文件。
B. 移动数据目录	数据目录（`datadir`）的配置属于 MySQL 服务端范畴，需通过 `my.cnf` 或启动参数调整，与客户端工具无关。
D. 管理 SSL 证书和日志位置	SSL 证书和日志路径需在 `my.cnf` 中配置，或通过客户端命令参数指定（如 `--ssl-ca`），`mysql_config_editor` 不支持此类操作。
E. 管理用户权限	用户权限由 MySQL 的 `GRANT` 和 `REVOKE` 语句管理，与客户端配置工具无关。
F. 管理 MySQL 防火墙	MySQL 防火墙（Enterprise Firewall）是独立的安全功能，需通过插件或企业版工具配置，与 `mysql_config_editor` 无关。

技术扩展

.mylogin.cnf 文件的安全性
- 文件内容经过模糊处理，无法直接以明文读取（如 cat 或文本编辑器打开）。
- 通过 print 命令查看时，密码会显示为 *****，进一步保障敏感信息不被泄露。
配置的优先级规则
- 客户端程序读取配置的优先级为：命令行参数 > .mylogin.cnf > 其他选项文件（如 my.cnf）。
- 即使使用 --no-defaults 忽略其他配置文件，.mylogin.cnf 仍会被读取。
多环境配置管理
- 可为不同服务器创建多个登录路径（如 prod、dev），通过 --login-path 快速切换连接目标。
- 示例：

mysql_config_editor set --login-path=prod --host=10.0.0.1 --user=admin --port=3306
mysql --login-path=prod# 连接生产环境

通过以上分析，选项 C 和 G 为正确答案，体现了 mysql_config_editor 在客户端连接配置中的核心作用。

题目 128

A MySQL server is monitored using MySQL Enterprise Monitor 's agentless installation.

Which three features are available with this installation method?

A. MySQL Replication monitoring

B. security-related advisor warnings

C. CPU utilization

D. disk usage and disk characteristics including disk advisors warnings

E. MySQL Query Analysis data

F. operating system memory utilization

G. network-related information and network characteristics

正确答案

A. MySQL Replication monitoring

B. security-related advisor warnings

E. MySQL Query Analysis data

关键解析

1. 选项 A：MySQL Replication monitoring（MySQL 复制监控）

MySQL Enterprise Monitor（MEM）的无代理安装支持自动发现并监控复制拓扑，即使未安装代理程序，也能通过服务管理器直接连接 MySQL 实例获取复制状态信息。例如：

自动拓扑发现：MEM 可以自动识别主从关系，并在 Dashboard 中展示复制的延迟、同步状态等关键指标。
历史数据可视化：通过图形化界面展示复制链路的性能趋势，帮助管理员快速定位同步问题。

2. 选项 B：security-related advisor warnings（安全顾问警告）

MEM 提供安全策略审计功能，基于预定义的最佳实践规则检测潜在漏洞，例如弱密码、未加密连接、权限配置不当等。这些检测无需依赖主机代理，仅需访问 MySQL 的系统表（如 mysql.user）和配置参数即可实现。例如：

权限变更监控：实时检测用户权限的修改并发出告警。
SSL 配置检查：验证是否启用 SSL/TLS 加密传输，确保数据传输安全。

3. 选项 E：MySQL Query Analysis data（查询分析数据）

MEM 的查询分析器（Query Analyzer）通过解析 Performance Schema 或慢查询日志，收集 SQL 执行统计信息（如响应时间、执行频率、索引使用情况），并生成可视化报告。例如：

高开销查询识别：通过 QRTi（Query Response Time Index）指标快速定位低效 SQL。
执行计划分析：结合 EXPLAIN 结果提供索引优化建议，减少全表扫描。

排除选项的原因

选项	排除原因
C. CPU utilization	无代理安装无法直接获取主机级别的 CPU 使用率等操作系统指标，需依赖代理程序收集。
D. disk usage and disk characteristics	磁盘使用率和特性（如 I/O 负载、文件系统容量）需代理程序监控主机硬件，无代理模式下不可用。
F. operating system memory utilization	操作系统内存使用情况需代理程序监控，无代理安装无法获取。
G. network-related information	网络流量、端口状态等主机层网络特性需代理程序支持，无代理模式下不可用。

技术扩展

无代理架构的局限性
- 数据范围受限：仅能获取 MySQL 实例内部的元数据和性能指标（如 InnoDB 缓冲池状态、线程活动），无法监控主机硬件或操作系统资源。
- 依赖数据库权限：需确保 MEM 服务管理器具有足够的 MySQL 用户权限（如 PROCESS、SUPER）以访问 Performance Schema 和系统表。
功能实现机制
- 复制监控：通过 SHOW SLAVE STATUS 和 SHOW MASTER STATUS 命令获取复制链路状态。
- 安全审计：基于 INFORMATION_SCHEMA 和 mysql 系统表的查询结果匹配安全规则库。
- 查询分析：从 performance_schema.events_statements_summary_by_digest 表中提取 SQL 执行统计。
适用场景
- 云环境监控：适用于 AWS RDS、Azure Database 等托管服务，无需安装代理即可集成监控。
- 快速部署：简化监控配置流程，特别适合临时诊断或轻量级监控需求。

通过以上分析，选项 A、B、E 为正确答案，体现了无代理安装模式下 MEM 在数据库层监控的核心能力。

题目 129

Examine this statement:

mysql> DROP ROLE r_role1, r_role2;

Which two are true?

A. You must revoke r_role1 and r_role2 from all users and other roles before dropping the roles.

B. You must revoke all privileges from r_role1 and r_role2 before dropping the roles.

C. It fails if at least one of the roles does not exist.

D. Existing connections can continue to use the roles' privileges until they reconnect.

E. It fails if you do not have the ADMIN OPTION of the roles r_role1 and r_role2.

F. It fails if any of the roles is specified in the mandatory_roles variable.

正确答案

C. It fails if at least one of the roles does not exist.

F. It fails if any of the roles is specified in the mandatory_roles variable.

关键解析

1. 选项 C：如果角色不存在则操作失败

MySQL 的 DROP ROLE 语句默认情况下，若尝试删除一个不存在的角色且未使用 IF EXISTS 子句，会直接报错并终止操作。例如：

-- 若 r_role2 不存在，以下语句会失败
DROP ROLE r_role1, r_role2;

此行为符合 SQL 标准，旨在避免误删不存在的对象。

2. 选项 F：若角色被定义为强制角色则操作失败

强制角色通过系统变量 mandatory_roles 设置，这些角色会被自动授予所有用户且无法手动撤销。若尝试删除这些角色，必须先将其从 mandatory_roles 中移除，否则 DROP ROLE 会失败。例如：

-- 设置强制角色
SET PERSIST mandatory_roles = 'r_role1';
-- 删除强制角色 r_role1 会失败
DROP ROLE r_role1;

错误选项排除原因

选项	排除原因
A. 需先撤销角色分配	MySQL 删除角色时会自动撤销其所有授权，无需手动操作。
B. 需先撤销角色权限	删除角色会连带撤销其所有权限，无需单独操作权限。
D. 现有连接可继续使用权限	此描述存在争议。根据 MySQL 机制，删除角色后，当前会话中已激活的权限可能失效（取决于权限缓存机制），而非必须重新连接。
E. 需 ADMIN OPTION 权限	`DROP ROLE` 需要 `DROP ROLE` 或 `CREATE USER` 权限，而非 `ADMIN OPTION`。

技术扩展

强制角色的特殊处理
- 强制角色通过 mandatory_roles 定义，需通过 SET PERSIST 修改该变量后才能删除。
- 强制角色常用于全局权限管理（如审计日志访问），确保所有用户自动继承基础权限。
IF EXISTS 子句的作用
- 使用 IF EXISTS 可避免因角色不存在而报错，例如：

DROP ROLE IF EXISTS r_role1, r_role2;

此子句适用于批量操作或自动化脚本，提升容错性。

权限与依赖关系
- 若角色被其他角色或用户继承，删除时会自动级联撤销依赖关系。
- 通过 SHOW GRANTS 可验证角色的授权状态，例如：

SHOW GRANTS FOR 'user1'@'localhost' USING 'r_role1';

总结

正确选项为 C 和 F，体现了 MySQL 删除角色时的严格校验机制，尤其是对强制角色的保护。其他选项混淆了权限撤销逻辑和会话状态管理，需结合具体机制判断。

题目 130

Which two are true about differences between logical and physical upgrades of MySQL databases?

A. Logical upgrades are much faster because they do not require restarting the mysqld process.

B. Physical upgrades are much faster because they do not require restarting the mysqld process.

C. Physical upgrades are performed for current instances on bare metal deployments, whereas logical upgrades are used for virtual machines or containerized instances.

D. Post-upgrade table storage requirements after physical upgrades are usually smaller than that after logical upgrades.

E. Post-upgrade table storage requirements after logical upgrades are usually smaller than that after physical upgrades.

F. Physical upgrades leave data in place, whereas logical upgrades require data to be restored from mysqldump-type backups taken before the upgrades.

正确答案

E. Post-upgrade table storage requirements after logical upgrades are usually smaller than that after physical upgrades.

F. Physical upgrades leave data in place, whereas logical upgrades require data to be restored from mysqldump-type backups taken before the upgrades.

关键解析

1. 选项 E：逻辑升级后的存储需求通常更小

逻辑升级通过 mysqldump 等工具导出数据并重新导入到新版本数据库中，这一过程会重建表结构并优化存储（如整理碎片、使用新版本的索引压缩技术），因此存储空间通常比物理升级更小。物理升级直接保留原有数据文件，可能存在旧版本存储格式的碎片或冗余数据，导致存储需求更大。

2. 选项 F：物理升级保留数据，逻辑升级需从备份恢复

物理升级（In-Place Upgrade）：直接替换 MySQL 二进制文件或数据文件，不迁移数据，数据仍位于原路径。例如，通过更新 RPM 包后重启服务完成升级。
逻辑升级（Logical Upgrade）：需先通过 mysqldump 备份数据，再导入到新版本实例中，本质上是一种数据迁移过程。

错误选项排除原因

选项	排除原因
A. 逻辑升级更快（无需重启mysqld）	逻辑升级需启动旧实例导出数据和新实例导入数据，依赖 mysqld 进程运行，且耗时较长，速度并不快。
B. 物理升级更快（无需重启mysqld）	物理升级需停止旧进程并重启新进程（如替换二进制文件后重启服务），因此需要停机时间。
C. 物理升级仅用于裸金属，逻辑用于虚拟机/容器	升级方式的选择与部署环境无关，物理和逻辑升级均可用于裸金属、虚拟机或容器。
D. 物理升级后存储需求更小	物理升级直接保留原数据文件，可能因旧版本碎片或存储格式导致存储需求更大。

技术扩展

物理升级的核心流程
- 停止旧版本 MySQL 服务 → 替换二进制文件或数据文件 → 启动新版本服务 → 执行 mysql_upgrade 升级系统表。
- 优势：无需数据迁移，适合数据量大的场景。
- 局限性：无法跨操作系统或大版本升级（如 5.5 → 5.7）。
逻辑升级的典型场景
- 通过 mysqldump 导出全量数据 → 安装新版本 MySQL → 导入数据 → 应用增量日志（如二进制日志或 GTID）。
- 优势：支持跨环境迁移（如从 CentOS 迁移到 Ubuntu）。
- 劣势：耗时较长，且需处理字符集、存储引擎兼容性问题。
存储优化的底层机制
- 逻辑升级重建表时，InnoDB 会按新版本的页压缩算法或动态行格式存储数据，减少空间占用。
- 物理升级直接使用旧数据文件，可能保留旧版本的未优化页结构（如冗余索引或碎片）。

总结

正确选项为 E 和 F，体现了逻辑与物理升级在存储优化和数据操作方式上的本质差异。其他选项混淆了升级流程的依赖条件和性能特征，需结合具体机制判断。

题目 131

You made some table definition changes to a schema in your MySQL Server.

Which two statements reflect how MySQL Server handles the table definition changes?

A. MySQL Server stores a copy of the serialized data in the InnoDB user tablespace.

B. MySQL writes SDI to the binary log for distributed backups.

C. MySQL implicitly executes FLUSH TABLES and stores a snapshot backup of the metadata.

D. The metadata is serialized in Serialized Dictionary Information (SDI).

E. MySQL keeps InnoDB metadata changes in .sdi files in datadir.

正确答案

A. MySQL Server stores a copy of the serialized data in the InnoDB user tablespace.

D. The metadata is serialized in Serialized Dictionary Information (SDI).

关键解析

1. 选项 A：InnoDB 用户表空间存储序列化数据

对于 InnoDB 存储引擎，SDI 数据直接嵌入表空间文件（如 .ibd 文件）中，而非单独保存。例如，每张 InnoDB 表的 SDI 记录存储在其表空间的第 0-1 个段中，默认占用 16 KB 的索引页（经过压缩）。因此，表结构变更后，更新后的元数据会直接写入表空间文件，确保元数据与数据文件的一致性。

2. 选项 D：元数据序列化到 SDI

MySQL 8.0 引入了 Serialized Dictionary Information（SDI）机制，用于存储表、表空间等对象的元数据。SDI 以 JSON 格式序列化表结构信息（如列定义、索引、约束等），提供元数据的冗余备份，即使数据字典不可用，也能通过工具（如 ibd2sdi）直接从表空间文件中提取元数据。例如，执行表结构变更（如 ALTER TABLE）时，InnoDB 会更新 SDI 记录以反映最新元数据状态。

错误选项排除原因

选项	排除原因
B. SDI 写入二进制日志	SDI 主要用于元数据冗余和恢复，与二进制日志无关。二进制日志记录的是数据操作（DML）而非元数据变更。
C. 隐式执行 `FLUSH TABLES` 并备份元数据快照	MySQL 未通过 `FLUSH TABLES` 或快照机制处理元数据变更。SDI 的更新是事务性的，与 DDL 操作直接关联。
E. InnoDB 元数据变更保存到 `.sdi` 文件	`.sdi` 文件是 MyISAM 引擎的元数据存储方式。InnoDB 的 SDI 数据存储在表空间文件（`.ibd`）中，而非 `datadir` 的独立文件。

技术扩展

SDI 的核心作用
- 元数据冗余：SDI 提供了独立于数据字典的元数据备份，可用于数据恢复或跨版本迁移。
- 崩溃安全性：通过事务性更新 SDI，确保元数据变更的原子性和持久性。
SDI 的物理存储细节
- InnoDB 表空间的 SDI 数据存储在第 0-1 个段中，默认占用 16 KB 的索引页（压缩后占用更少空间）。
- 分区表的 SDI 仅存储在第一个分区的表空间文件中。
SDI 的运维工具
- ibd2sdi 工具：可直接从 .ibd 文件中提取 SDI 的 JSON 元数据，用于手动修复或分析表结构。例如：

ibd2sdi --dump-file=table_metadata.json table_name.ibd

总结

正确选项为 A 和 D，体现了 MySQL 通过 SDI 机制序列化元数据并嵌入 InnoDB 表空间的特性。其他选项混淆了 SDI 的存储位置、用途及 MySQL 的日志机制，需结合 SDI 的设计原理和引擎差异判断。

题目 132

Which three settings control global buffers shared by all threads on a MySQL server?

A. tmp_table_size

B. innodb_buffer_pool_size

C. table_open_cache

D. sort_buffer_size

E. key_buffer_size

F. read_buffer_size

正确答案

B. innodb_buffer_pool_size

C. table_open_cache

E. key_buffer_size

关键解析

1. 选项 B：innodb_buffer_pool_size

作用：控制 InnoDB 存储引擎的缓冲池大小，用于缓存数据页和索引页，是所有线程共享的全局内存区域。它是 MySQL 性能优化的核心参数，直接影响磁盘 I/O 效率和查询速度。

全局性：所有线程共享同一缓冲池，数据缓存对所有连接透明。
默认值：128 MB，建议设置为物理内存的 50%-80%。

2. 选项 E：key_buffer_size

作用：管理 MyISAM 存储引擎的索引缓冲区，用于加速 MyISAM 表的索引查询操作。

全局性：所有使用 MyISAM 表的线程共享该缓冲区，即使默认存储引擎为 InnoDB，内部临时表（如某些排序操作生成的表）仍可能使用 MyISAM 引擎，因此需要此缓冲区支持。
默认值：8.0 版本后默认值为 8 MB，需根据 MyISAM 表的使用频率调整。

3. 选项 C：table_open_cache

作用：控制所有线程打开表的数量，缓存表结构信息（如表定义、字段属性等），减少重复打开表的开销。

全局性：所有线程共享表缓存，避免频繁访问表时重复加载元数据。
默认值：通常为 2000，需根据实际表数量和并发连接数调整。

错误选项排除原因

选项	排除原因
A. `tmp_table_size`	控制单个会话内存临时表的最大大小，属于会话私有内存，非全局共享。
D. `sort_buffer_size`	每个会话独立分配排序缓冲区，用于处理 `ORDER BY` 操作，属于会话级内存。
F. `read_buffer_size`	每个会话为顺序扫描操作（如全表扫描）分配独立缓冲区，属于会话私有内存。

技术扩展

全局缓冲区的优化策略
- innodb_buffer_pool_size：根据服务器物理内存动态调整，例如 32 GB 内存的服务器可设置为 24 GB（75%），并启用多实例（innodb_buffer_pool_instances）分散锁竞争。
- key_buffer_size：若使用 MyISAM 表，建议设置为总内存的 20%-30%；若仅少量使用，可降低至 16 MB 以下。
- table_open_cache：监控 Open_tables 和 Opened_tables 状态变量，若 Opened_tables 持续增长，需增大此值以减少表重新打开次数。
全局与会话内存的区分
- 全局内存：启动时分配，生命周期与服务器一致，如 innodb_log_buffer_size（日志缓冲区）。
- 会话内存：按需为每个连接分配，如 join_buffer_size（连接操作缓冲区）和 read_rnd_buffer_size（随机读缓冲区）。

通过以上分析，B、C、E 为正确答案，体现了 MySQL 全局缓冲区的核心配置及其对性能的影响。

题目 134

You are using mysqlcheck for server maintenance.

Which two statements are true?

A. The mysqlcheck --check --all-databases command takes table write locks while performing a series of checks.

B. The mysqlcheck --repair --all-databases command can repair an InnoDB corrupted table.

C. The mysqlcheck --analyze --all-databases command performs a series of checks to spot eventual table corruptions.

D. The mysqlcheck command can be renamed mysqlrepair so that it repairs tables by default.

E. The mysqlcheck --optimize --all-databases command reclaims free space from table files.

正确答案

D. The mysqlcheck command can be renamed mysqlrepair so that it repairs tables by default.

E. The mysqlcheck --optimize --all-databases command reclaims free space from table files.

关键解析

1. 选项 D 的正确性

重命名行为：根据官方文档，mysqlcheck 的默认行为可以通过重命名二进制文件来改变。例如，将其重命名为 mysqlrepair 后，执行该命令会默认执行表修复操作（--repair）。
功能扩展：这种设计允许用户通过不同的别名直接调用特定功能（如修复、分析或优化），无需手动指定参数。

2. 选项 E 的正确性

空间回收：--optimize 选项对应 OPTIMIZE TABLE 操作，主要用于整理表碎片、回收未使用的存储空间，并优化索引结构。对于 MyISAM 引擎表，这会直接减少物理文件大小；对于 InnoDB 引擎，虽然空间可能不会立即释放到操作系统，但内部碎片会被整理以提高性能。
适用性：此操作对 MyISAM、ARCHIVE 引擎有效，且通过 --all-databases 可全局执行。

错误选项排除原因

选项	排除原因
A. `--check` 使用写锁	`mysqlcheck` 的检查操作（`--check`）仅对表施加读锁（READ），允许其他会话读取但不能写入。写锁（WRITE）仅用于修复或优化操作。
B. 修复 InnoDB 表	`mysqlcheck` 的 `--repair` 选项不支持 InnoDB 表。InnoDB 引擎的表损坏需通过 `innodb_force_recovery` 参数或专业工具处理。
C. `--analyze` 检查损坏	`--analyze` 用于更新表的统计信息（如索引分布），与检查表损坏无关。检查损坏应使用 `--check` 或 `CHECK TABLE` 命令。

技术扩展

mysqlcheck 的默认行为与重命名机制
- 默认行为为 --check（检查表），但通过重命名可改变默认操作：
  - mysqlrepair → 默认执行 --repair
  - mysqlanalyze → 默认执行 --analyze
  - mysqloptimize → 默认执行 --optimize
--optimize 的实际效果
- MyISAM：减少 .MYD 文件大小，释放磁盘空间。
- InnoDB：优化页合并和索引结构，但空间可能保留在表空间文件中（需配合 innodb_file_per_table 配置）。
操作锁机制
- 读锁：用于检查（CHECK）和分析（ANALYZE），允许并发读取。
- 写锁：用于修复（REPAIR）和优化（OPTIMIZE），阻塞其他会话的读写操作。

总结

正确选项为 D 和 E，分别体现了 mysqlcheck 的灵活别名机制和存储空间优化功能。其他选项混淆了操作类型、锁机制及引擎支持范围，需结合官方文档和实际场景验证。

题目 135

Your MySQL server is running on the Microsoft Windows platform.

Which three local connection protocols are available to you?

A. UDP

B. shared memory

C. SOCKET

D. named pipes

E. X Protocol

F. TCP/IP

正确答案

B. shared memory

D. named pipes

F. TCP/IP

关键解析

在 Windows 平台上，MySQL 支持以下三种本地连接协议：

1. Shared Memory（共享内存）

定义与适用性：共享内存协议通过内存直接传递数据，仅适用于本地连接，无需经过网络栈，因此效率极高。
配置要求：需在 MySQL 服务端配置文件中启用 shared_memory 参数，且默认共享内存名称为 MYSQL。
限制：同一主机上仅能运行一个 MySQL 实例（即使端口不同）。

2. Named Pipes（命名管道）

定义与适用性：一种基于本地进程间通信（IPC）的协议，适用于 Windows 环境，可通过管道名称（如 \\.\pipe\MySQL）建立连接。
配置要求：需在服务端启用 named_pipe 参数，且连接用户需属于 named_pipe_full_access_group 指定的 Windows 用户组。
优势：在网络禁用 TCP/IP 时仍可连接本地数据库。

3. TCP/IP

定义与适用性：基于网络的通用协议，通过本地环回地址（如 127.0.0.1 或 localhost）实现本地通信。
默认行为：在 Windows 上，若未显式指定协议，连接 localhost 时默认使用 TCP/IP 协议（通过 127.0.0.1）。
灵活性：支持加密（如 SSL/TLS）和远程连接，但本地使用时需确保防火墙允许端口 3306。

错误选项排除原因

选项	排除原因
A. UDP	MySQL 不支持 UDP 协议传输数据，仅依赖 TCP/IP 的可靠性。
C. SOCKET	Unix Socket 协议仅适用于类 Unix 系统（如 Linux/macOS），Windows 不支持。
E. X Protocol	这是 MySQL 8.0 引入的扩展协议，主要用于 NoSQL 和文档存储功能，且需显式启用，不属于本地连接的默认选项。

技术扩展

协议选择建议：
- 高性能本地通信：优先使用共享内存（无网络开销）或命名管道（适用于禁用 TCP/IP 的场景）。
- 兼容性与通用性：TCP/IP 是跨平台和远程连接的首选，且支持加密配置。
验证本地连接方式：
共享内存：

mysql --protocol=memory --user=root -p

命名管道：

mysql --protocol=pipe --user=root -p

TCP/IP：

mysql -h 127.0.0.1 -u root -p

安全注意事项：
- 共享内存/命名管道：本地安全性依赖操作系统权限控制，建议限制用户组访问。
- TCP/IP：可通过 SSL/TLS 加密防止数据泄露（如配置 --ssl-mode=REQUIRED）。

通过上述分析，B、D、F 为正确答案，反映了 Windows 平台下 MySQL 本地连接协议的核心支持与适用场景。

题目 136

Which two statements are true about the data dictionary object cache?

A. The dictionary object caches use a Least Recently Used (LRU) algorithm to manage entries in each cache.

B. Character set and collation definition objects are not cached.

C. All dictionary object caches have a hard-coded size.

D. If the dictionary object cache becomes full, MySQL server will be unable to create any more tables/objects.

E. tablespace_definition_cache sets the number of tablespace objects that can be stored in the dictionary object cache.

正确答案

A. The dictionary object caches use a Least Recently Used (LRU) algorithm to manage entries in each cache.

E. tablespace_definition_cache sets the number of tablespace objects that can be stored in the dictionary object cache.

关键解析

1. 选项 A 的正确性

字典对象缓存确实采用 LRU（最近最少使用）算法管理缓存条目。当缓存空间不足时，系统会自动淘汰最近最少访问的元数据对象，以释放内存空间供新对象使用。

2. 选项 E 的正确性

tablespace_definition_cache 是专门用于控制表空间定义对象在字典对象缓存中存储数量的可配置参数。默认值为 256，用户可根据实际需求调整该参数以优化内存使用。

错误选项排除原因

选项	排除原因
B. 字符集和校对定义对象未被缓存	字符集和校对定义对象明确被缓存，且其缓存分区有硬编码的容量限制（均为 256 个对象）。
C. 所有缓存大小均为硬编码	部分缓存分区（如表空间、模式、表定义缓存）大小可配置（如通过 `tablespace_definition_cache`、`schema_definition_cache`），而字符集、校对等缓存分区为硬编码。
D. 缓存满时无法创建新对象	缓存满时会通过 LRU 策略淘汰旧对象，而非直接阻止新对象创建。

技术扩展

字典对象缓存的分类与配置
- 可配置的缓存分区：
  - 表空间定义：tablespace_definition_cache（默认 256）。
  - 模式定义：schema_definition_cache（默认 256）。
  - 表定义：容量与 max_connections 参数相关（默认 151）。
- 硬编码的缓存分区：
  - 字符集定义：固定 256 个对象。
  - 校对定义：固定 256 个对象。
LRU 算法的实际应用
- 缓存淘汰策略确保高频访问的元数据（如表结构、索引信息）优先保留，减少磁盘 I/O。例如，频繁查询的表定义会长期驻留缓存，而较少使用的字符集定义可能被淘汰。
性能优化建议
- 动态调整参数：根据业务负载调整 tablespace_definition_cache 和 schema_definition_cache，避免频繁缓存淘汰。
- 监控缓存命中率：通过状态变量（如 Innodb_dictionary_cache_hit_rate）评估缓存效率，必要时扩容。

总结

正确选项为 A 和 E，体现了字典对象缓存的 LRU 管理机制及可配置特性。其他选项混淆了缓存类型、淘汰策略及配置方式，需结合官方文档与实际场景验证。

题目 137

Examine this statement, which executes successfully:

CREATE USER mary@192.0.2.100 IDENTIFIED BY 'P@SSw0rd' REQUIRE NONE PASSWORD EXPIRE;

Which two are true?

A. Mary must connect using the username 'mary@192.0.2.100'.

B. Mary requires no password to connect to the MySQL server.

C. Mary must connect from the client machine 192.0.2.100.

D. Mary cannot connect to the MySQL server until the DBA resets her password.

E. Mary cannot query data until she changes her password.

正确答案

C. Mary must connect from the client machine 192.0.2.100.

E. Mary cannot query data until she changes her password.

关键解析

1. 选项 C 的正确性

在 MySQL 中，CREATE USER 语句的格式为 'username'@'host'，其中 host 字段严格限制用户只能从指定主机或IP地址连接。题目中用户定义为 mary@192.0.2.100，表示 Mary 仅允许从 IP 地址为 192.0.2.100 的客户端连接到 MySQL 服务器。若尝试从其他 IP 地址连接，即使用户名和密码正确，也会因权限不匹配被拒绝。

2. 选项 E 的正确性

PASSWORD EXPIRE 子句会强制用户密码立即过期，用户首次登录时必须修改密码才能执行任何操作（包括查询数据）。即使 Mary 提供了正确的密码 P@SSw0rd，在未修改密码前，其账户处于锁定状态，无法执行数据查询或其他操作。这一机制是 MySQL 密码安全策略的核心设计，用于防止长期使用弱密码。

错误选项排除原因

选项	排除原因
A. 必须使用完整用户名 `mary@192.0.2.100`	连接时仅需提供用户名 `mary`，主机信息由 MySQL 根据客户端 IP 自动匹配，无需在用户名中包含主机部分。
B. 无需密码连接	`IDENTIFIED BY 'P@SSw0rd'` 明确要求密码验证，Mary 必须提供密码才能连接。
D. 需 DBA 重置密码	`PASSWORD EXPIRE` 仅要求用户自行修改密码，而非等待管理员重置。Mary 可通过 `ALTER USER` 或首次登录时修改密码。

技术扩展

用户权限与主机限制
- 主机通配符：若需允许从任意主机连接，应使用 %（如 mary@%）。
- 安全建议：生产环境应限制主机范围，避免开放 % 以减少攻击面。
密码过期策略的实际影响
- 首次登录流程：用户首次登录时，MySQL 会提示修改密码，否则所有操作（包括 SELECT）均被拒绝。
- 强制修改密码：可通过 ALTER USER 'mary'@'192.0.2.100' PASSWORD EXPIRE; 动态设置密码过期。
安全策略配置
- 密码复杂度：建议结合 validate_password 插件强制密码包含大小写字母、数字及特殊字符。
- 定期过期：通过 default_password_lifetime 参数设置密码有效期（如 90 天），增强安全性。

总结

正确选项为 C 和 E，体现了 MySQL 用户访问控制的主机限制和密码过期机制。其他选项混淆了用户名格式、密码验证流程及权限管理逻辑，需结合官方文档与实际配置验证。

题目 138

Examine this command, which executes successfully on InnoDB Cluster:

dba.dropMetadataschema()

Which two statements are true?

A. The mysql_innodb_cluster_metadata schema is dropped from the instance where the connection was established.

B. Group Replication is still operational, but InnoDB Cluster must be reimported under MySQL Shell.

C. The command drops the mysql_innodb_cluster_metadata schema and re-creates it.

D. Connections driven by MySQL Router are not affected by the command.

E. The mysql_innodb_cluster_metadata schema is dropped from all reachable members of the cluster.

F. Group Replication will be dissolved and all metadata purged.

正确答案

A. The mysql_innodb_cluster_metadata schema is dropped from the instance where the connection was established.

F. Group Replication will be dissolved and all metadata purged.

关键解析

1. 选项 A 的正确性

dba.dropMetadataschema() 命令会删除当前连接实例上的 mysql_innodb_cluster_metadata 元数据模式。该操作是本地化的，仅影响执行命令的实例，而不会自动同步到其他集群节点。例如，若在节点 192.168.1.41 上执行该命令，则仅该节点的元数据被删除，其他节点的元数据仍保留。

2. 选项 F 的正确性

删除元数据模式会直接导致 Group Replication 被解散。这是因为 InnoDB Cluster 的元数据是集群管理的核心，存储了复制组配置、节点状态等信息。元数据被删除后，Group Replication 的成员因无法获取集群配置而自动停止运行，最终导致复制组解散。例如，若元数据被删除，cluster.status() 将无法获取集群状态，且所有节点会脱离复制组。

错误选项排除原因

选项	排除原因
B. Group Replication 仍运行，但需重新导入	元数据删除后，Group Replication 无法继续运行，因为复制组依赖元数据中的配置信息。
C. 删除并重新创建元数据	`dba.dropMetadataschema()` 仅删除元数据，不会自动重建。需手动调用 `dba.createCluster()` 重新初始化。
D. MySQL Router 连接不受影响	元数据删除后，Router 将因无法获取集群路由信息而中断现有连接并拒绝新连接。
E. 所有集群成员的元数据被删除	该命令仅作用于当前连接的实例，不会自动删除其他节点的元数据，需在每个节点上单独执行。

技术扩展

元数据的作用与依赖
- 核心功能：mysql_innodb_cluster_metadata 存储了集群拓扑、节点角色、路由配置等关键信息，是 MySQL Shell 和 Router 管理集群的基础。
- Group Replication 依赖：若元数据丢失，Group Replication 成员无法验证自身状态，最终导致复制组解散。
恢复策略
- 重建元数据：需通过 dba.createCluster() 重新创建集群，并手动添加所有节点。
- 数据一致性验证：若节点间数据不一致，需使用 clone 或备份恢复数据后重新加入。
操作风险
- 生产环境慎用：dba.dropMetadataschema() 会导致集群管理功能完全失效，仅在彻底解散集群或故障恢复时使用。

总结

正确选项为 A 和 F，体现了元数据删除的本地化影响及对 Group Replication 的全局破坏性。其他选项混淆了元数据的作用范围、恢复流程及集群依赖关系。

题目 139

User account baduser@hostname on your MySQL instance has been compromised.

Which two commands stop any new connections using the compromised account?

A. ALTER USER baduser@hostname PASSWORD DISABLED;

B. ALTER USER baduser@hostname DEFAULT ROLE NONE;

C. ALTER USER baduser@hostname MAX_USER_CONNECTIONS 0;

D. ALTER USER baduser@hostname IDENTIFIED WITH mysql_no_login;

E. ALTER USER baduser@hostname ACCOUNT LOCK;

正确答案

D. ALTER USER baduser@hostname IDENTIFIED WITH mysql_no_login;

E. ALTER USER baduser@hostname ACCOUNT LOCK;

关键解析

1. 选项 D 的正确性

通过 IDENTIFIED WITH mysql_no_login 指定认证插件为 mysql_no_login，该插件会完全禁止用户通过密码登录，即使密码正确也无法建立新连接。此方法通过修改认证逻辑实现账户禁用，属于更彻底的阻断方式。

2. 选项 E 的正确性

ACCOUNT LOCK 直接锁定用户账户，立即阻止所有新连接，但已存在的连接不会被强制中断。该操作是 MySQL 官方推荐的快速禁用账户的标准方法。

错误选项排除原因

选项	排除原因
A. `PASSWORD DISABLED`	`PASSWORD DISABLED` 是无效的 MySQL 语法，无法执行。MySQL 禁用密码需通过其他方式（如锁定或修改认证插件）。
B. `DEFAULT ROLE NONE`	撤销默认角色仅影响权限继承，不会阻止新连接。用户仍可通过基础权限（如 `USAGE`）连接服务器。
C. `MAX_USER_CONNECTIONS 0`	虽然 `MAX_USER_CONNECTIONS 0` 理论上限制连接数为零，但实际执行时会报错（参数值需 ≥ 1）。即使通过全局变量设置，仍需重启服务生效，无法快速阻断。

技术扩展

mysql_no_login 插件的配置
- 安装插件：需先加载 mysql_no_login 插件（非默认安装），例如：

INSTALL PLUGIN mysql_no_login SONAME 'mysql_no_login.so';

适用场景：适用于需要长期禁用账户且无需删除的场景（如审计保留）。

ACCOUNT LOCK 的实时性
- 锁定操作无需重启服务或刷新权限，立即生效。通过查询 mysql.user 表的 account_locked 字段可验证状态：

SELECT user, host, account_locked FROM mysql.user WHERE user = 'baduser';

结果为 Y 表示已锁定。

安全恢复建议
- 彻底删除风险：确认账户无保留价值后，直接执行 DROP USER 删除账户。
- 密码重置与审计：若需恢复账户，建议重置密码并启用二次认证，同时通过审计日志排查历史操作风险。

总结

正确选项为 D 和 E，分别通过认证插件阻断和账户锁定实现新连接的即时禁止。其他选项或因语法错误、逻辑不相关被排除。实际生产中，建议优先使用 ACCOUNT LOCK 实现快速响应，并结合审计插件追踪异常行为。

题目 140

Which two are use cases of MySQL asynchronous replication?

A. You can scale reads by adding multiple slaves.

B. MySQL Enterprise Backup will automatically back up from an available slave.

C. You can scale writes by creating a replicated mesh.

D. It guarantees near real-time replication between a master and a slave.

E. It allows backup to be done on the slave without impacting the master.

正确答案

A. You can scale reads by adding multiple slaves.

E. It allows backup to be done on the slave without impacting the master.

关键解析

1. 选项 A 的正确性

MySQL异步复制的核心优势之一是支持读写分离。通过添加多个从库，可以将读请求分发到不同从节点，显著提升系统的整体读吞吐量。例如：

应用场景：在电商大促期间，90% 的查询流量可通过多个从库分担。
技术原理：主库（Master）专注于处理写操作（如 INSERT/UPDATE），从库（Slave）异步拉取二进制日志（Binlog）并重放，从而保证数据最终一致性。
性能提升：某头部社交平台通过增加 8 个从库，读 QPS 从 5 万提升至 40 万。

2. 选项 E 的正确性

在异步复制架构中，从库可作为备份节点，执行备份任务时不会占用主库资源，避免主库因备份操作导致的性能下降或阻塞。例如：

数据安全：从库保存主库的数据副本，支持通过 mysqldump 或第三方工具（如 Percona XtraBackup）进行备份。
实践案例：某银行系统通过从库备份将月度报表生成时间从 12 小时缩短至 2 小时。

错误选项排除原因

选项	排除原因
B. 企业版备份自动选择从库	备份操作通常需手动指定从库节点。
C. 通过复制网格扩展写能力	异步复制本身不支持多主架构，扩展写能力需依赖其他技术（如组复制或 Galera Cluster）。
D. 保证主从近实时同步	异步复制的核心缺点是存在延迟（如网络带宽不足或从库负载过高时），无法保证实时一致性。

技术扩展

异步复制的典型架构
- 一主多从：主库处理写操作，多个从库分担读请求，适合读多写少的场景（如新闻网站）。
- 异地灾备：从库可部署在异地机房，防范物理灾难（如地震、火灾）。
备份与恢复策略
- 逻辑备份：使用 mysqldump 导出数据，适合小规模数据。
- 物理备份：通过工具（如 Percona XtraBackup）直接备份数据文件，效率更高，适合生产环境。
- 一致性校验：推荐使用 pt-table-checksum 检查主从数据一致性，未校验的系统年数据不一致率可能达 0.3%。
延迟监控与优化
- 核心指标：Seconds_Behind_Master 显示从库延迟时间，建议设置告警阈值为 500 ms。
- 优化手段：启用并行复制（MTS）、优化网络带宽或调整 binlog 格式为 ROW 以减少日志量。

总结

异步复制的核心应用场景是扩展读能力和安全备份（选项 A 和 E）。其他选项或因功能不匹配、或因技术原理错误被排除。实际生产中，建议结合半同步复制（Semi-Sync）或组复制（MGR）提升数据一致性保障。

题目 141

Which two MySQL Shell commands are excluded from the InnoDB Cluster creation procedure?

A. cluster.addInstance()

B. dba.configureLocalInstance()

C. dba.checkInstanceConfiguration()

D. cluster.setPrimaryInstance()

E. dba.configureInstance()

F. dba.createCluster()

G. cluster.forceQuorumUsingPartitionOf()

正确答案

D. cluster.setPrimaryInstance()

G. cluster.forceQuorumUsingPartitionOf()

关键解析

1. 选项 D: cluster.setPrimaryInstance()

排除原因：这个命令用于手动设置主实例（Primary Instance），通常在集群运行期间进行故障切换（Switchover）或故障转移（Failover）时使用。
- **创建集群的流程：**在创建 InnoDB Cluster 时，主实例是通过集群初始化时自动选举产生的（默认第一个加入集群的实例为主实例）。
  - 例如，使用 dba.createCluster('myCluster') 创建集群时，第一个实例会自动成为主实例，无需手动指定。
- **cluster.setPrimaryInstance() 的用途：**该命令仅用于集群运行后，主动切换主实例的场景（如计划内维护），不属于集群创建的标准流程。
- 结论：该命令不在 InnoDB Cluster 创建过程中，因此是正确答案之一。

2. 选项 G: cluster.forceQuorumUsingPartitionOf()

**排除原因：这个命令用于在集群失去多数成员（Quorum）**的情况下，强制恢复集群的可用性。
- **创建集群的流程：**在创建集群时，集群需要满足 Group Replication 的 Quorum 要求（至少有大多数成员在线）。如果创建失败，通常是因为配置错误或网络问题，而不是 Quorum 丢失。
- **forceQuorumUsingPartitionOf() 的用途：该命令仅在集群运行期间发生分区（Split-Brain）**或 Quorum 丢失时使用，与集群创建无关。
- 结论：该命令不在 InnoDB Cluster 创建过程中，因此是正确答案之一。

其他选项解析

1. 选项 A：cluster.addInstance()

用途：
- 向已创建的 InnoDB Cluster 添加新节点。
属于创建过程：
- 是的。在创建集群后，添加节点是扩展集群的必要步骤。
结论：
- 属于创建过程，排除。

2. 选项B：dba.configureLocalInstance()

用途：
- 配置当前本地实例以符合 InnoDB Cluster 的要求（如启用 GTID、组复制等）。
属于创建过程：
- 是的。这是创建集群前的必要准备步骤。
结论：
- 属于创建过程，排除。

3. 选项 C：dba.checkInstanceConfiguration()

用途：
- 检查实例是否已正确配置以支持 InnoDB Cluster。
属于创建过程：
- 是的。这是创建集群前的验证步骤。
结论：
- 属于创建过程，排除。

4. 选项E：dba.configureInstance()

用途：
- 远程配置其他实例以符合 InnoDB Cluster 的要求。
属于创建过程：
- 是的。这是创建集群前的必要准备步骤。
结论：
- 属于创建过程，排除。

5. F：dba.createCluster()

用途：
- 创建一个新的 InnoDB Cluster。
属于创建过程：
- 是的。这是创建集群的核心命令。
结论：
- 属于创建过程，排除。

结论

在 InnoDB Cluster 的创建过程中，cluster.setPrimaryInstance() 和 cluster.forceQuorumUsingPartitionOf() 是不属于创建流程的命令，因此是正确答案。

题目 142

Examine this command, which executes successfully:

shell> mysqldump --master-data=2 --single-transaction --result-file=dump.sql mydb

Which two statements are true?

A. This option uses the READ COMMITTED transaction isolation mode.

B. It enforces consistent backups for all storage engines.

C. It is a cold backup.

D. The backup created is a consistent data dump.

E. It executes flush tables with read lock.

正确答案

D. The backup created is a consistent data dump.

E. It executes flush tables with read lock.

关键解析

1. 选项 D 的正确性

通过 --single-transaction 参数，mysqldump 会在备份开始时启动一个事务（隔离级别为 REPEATABLE READ），利用 InnoDB 引擎的多版本并发控制（MVCC）特性创建一致性快照。这使得备份过程中读取的数据始终对应事务启动时的状态，确保数据的一致性（对 InnoDB 表有效）。例如，在备份过程中若有其他会话修改数据，不会影响已备份的数据内容。

2. 选项 E 的正确性

当 --master-data=2 与 --single-transaction 结合使用时，mysqldump 会短暂执行 FLUSH TABLES WITH READ LOCK（FTWRL）以获取二进制日志的精确位置（MASTER_LOG_FILE 和 MASTER_LOG_POS），随后立即释放锁。此操作确保记录的主库日志位置与备份数据的一致性快照对齐，但不会长时间阻塞写入操作。

错误选项排除原因

选项	排除原因
A. 使用 READ COMMITTED 隔离级别	`--single-transaction` 实际使用 `REPEATABLE READ` 隔离级别，而非 `READ COMMITTED`。
B. 保证所有存储引擎的一致性	仅对 InnoDB 有效，MyISAM 或 MEMORY 引擎仍需通过锁表（如 `--lock-tables`）实现一致性，但此命令未包含此类参数。
C. 冷备份	`mysqldump` 是逻辑备份工具，`--single-transaction` 属于热备份（在线备份），无需关闭数据库。

技术扩展

参数组合的作用机制
- --master-data=2：在备份文件中以注释形式记录二进制日志位置，便于后续搭建主从复制或增量恢复。
- --single-transaction：通过事务保证 InnoDB 表的一致性，但需注意以下限制：
  - DDL 操作冲突：若备份期间执行 ALTER TABLE、DROP TABLE 等操作，会导致快照失效，备份失败或数据不一致。
  - 非事务引擎限制：MyISAM 表仍需依赖 --lock-tables 实现一致性，但此命令未包含该参数。
备份流程的关键步骤
- 步骤1：执行 FLUSH TABLES WITH READ LOCK 获取全局锁，记录二进制日志位置。
- 步骤2：释放全局锁，开启事务并创建一致性快照。
- 步骤3：逐表导出数据，利用 MVCC 读取快照数据，避免锁表阻塞写入。
典型应用场景
- 主从复制搭建：通过 --master-data=2 记录的主库日志位置，可直接在从库执行 CHANGE MASTER TO 实现同步起点对齐。
- 跨时区恢复：若未使用 --skip-tz-utc，需确保恢复环境的时区与备份一致，避免时间戳数据错误。

总结

正确选项为 D 和 E。--single-transaction 确保 InnoDB 表的一致性快照，而 --master-data=2 触发短暂全局锁以记录二进制日志位置。其他选项因隔离级别误判、引擎限制或备份类型错误被排除。实际生产中，建议结合 --routines 和 --triggers 参数备份存储过程和触发器，确保数据完整性。

题目 143

Which two methods allow a DBA to reset a user's password?

A. SET PASSWORD statement

B. mysql_secure_installation utility

C. ALTER USER statement

D. GRANT statement

E. mysqladmin client program

正确答案

C. ALTER USER statement

E. mysqladmin client program

关键解析

1. ALTER USER 语句（选项 C）

这是 MySQL 8.0 官方推荐的密码重置方法。通过该语句可以直接修改用户的认证信息和密码，支持最新的安全特性（如密码复杂度校验和认证插件）。

语法示例：

ALTER USER '用户名'@'主机名' IDENTIFIED WITH mysql_native_password BY '新密码';

特点：

兼容性：支持 MySQL 8.0 及更高版本，且默认使用 caching_sha2_password 加密插件。
安全性：允许指定加密方式（如切换回传统插件 mysql_native_password），避免因新插件导致的兼容性问题。
场景：无论是普通用户还是 root 用户，均可直接使用，无需重启服务。

案例：

在忘记 root 密码时，若需通过跳过权限表（--skip-grant-tables）重置，最终仍需通过 ALTER USER 完成密码更新。

2. mysqladmin 客户端程序（选项 E） 这是命令行工具，适用于已知旧密码时的快速重置操作。

语法示例：

mysqladmin -uroot -p旧密码 password '新密码'

特点：

便捷性：无需登录 MySQL 交互界面，直接通过命令行完成修改。
限制：需已知旧密码；若完全忘记密码，需结合其他方法（如跳过权限表）。

案例：

若 root 用户密码为已知但需修改，可直接运行上述命令，输入旧密码后立即生效。

错误选项排除原因

选项	排除原因
A. SET PASSWORD	在 MySQL 8.0 中，直接使用 `SET PASSWORD` 会触发错误 1820，强制要求改用 `ALTER USER`。
B. mysql_secure_installation	该工具用于初始化安全配置（如删除匿名用户），不支持重置已有用户密码。
D. GRANT	`GRANT` 语句在 MySQL 8.0 中已不推荐用于密码管理，且官方文档未将其列为密码重置方法。

技术扩展

密码复杂度：
- MySQL 8.0 默认启用密码策略（如最小长度、混合字符），可通过以下命令查看：

SHOW VARIABLES LIKE 'validate_password%';

若需临时降低复杂度要求（例如测试环境）：

SET GLOBAL validate_password.policy = LOW;

跳过权限表重置密码：
- 完全忘记密码时，需通过 --skip-grant-tables 启动 MySQL，清空密码字段后使用 ALTER USER 完成重置。

总结

在 MySQL 8.0 中，C（ALTER USER）和 E（mysqladmin）是两种有效的密码重置方法。前者是官方标准语法，支持所有场景；后者适用于已知旧密码的快速修改。其他选项或因兼容性问题、功能不相关被排除。实际操作中，建议优先使用 ALTER USER 以保证安全性和规范性。

题目 144

Examine Joe's account:

CREATE USER 'joe'@'%' IDENTIFIED BY 'secret';
GRANT ALL PRIVILEGES ON *.* TO 'joe'@'%';

All existing connections for joe are killed.

Which two commands will stop joe establishing access to the MySQL instance?

A. ALTER USER 'joe'@'%' ACCOUNT LOCK;

B. ALTER USER 'joe'@'%' PASSWORD HISTORY 0;

C. REVOKE ALL PRIVILEGES ON **.** FROM 'joe'@'%';

D. ALTER USER 'joe'@'%' SET password='invalid';

E. ALTER USER 'joe'@'%' IDENTIFIED BY 'invalid' PASSWORD EXPIRE;

F. REVOKE USAGE ON **.** FROM 'joe'@'%';

正确答案

A. ALTER USER 'joe'@'%' ACCOUNT LOCK;

E. ALTER USER 'joe'@'%' IDENTIFIED BY 'invalid' PASSWORD EXPIRE;

关键解析

1. 选项 A 的正确性：账户锁定

通过 ALTER USER ... ACCOUNT LOCK 可直接锁定用户账户，彻底阻止所有新连接尝试。

效果：用户 joe 尝试登录时会收到错误：Access denied for user... Account is locked，且无法建立连接。
验证方式：查询 mysql.user 表的 account_locked 字段，若值为 Y 表示已锁定。
适用场景：紧急阻断恶意账户或泄露账户的最直接方式，无需依赖密码状态或权限设置。

2. 选项 E 的正确性：密码修改与过期

通过 ALTER USER ... IDENTIFIED BY 'invalid' PASSWORD EXPIRE 实现双重阻断：

修改密码：将密码设为未知值（如 invalid），原密码 secret 失效。
密码过期：强制用户下次登录时必须更改密码。
效果：
- 若用户不知道新密码 invalid，直接认证失败。
- 即使知道密码，因密码已过期，非交互式客户端（如应用程序）会因无法完成密码更新而连接失败。
验证方式：查询 mysql.user 表的 password_expired 字段，若值为 Y 表示密码已过期。

错误选项排除原因

选项	排除原因
B. `PASSWORD HISTORY 0`	仅控制密码重用历史策略，不影响当前连接权限。
C. `REVOKE ALL PRIVILEGES`	收回权限后，用户仍可通过 `USAGE` 权限连接服务器（仅限制操作权限）。
D. `SET password='invalid'`	不支持 `SET password` 子句。
F. `REVOKE USAGE`	`USAGE` 是默认权限且不可撤销，操作无效。

技术扩展

账户锁定（A）：
- 立即生效，无需依赖密码状态或客户端行为，是最高优先级的阻断方式。
- 适用场景：账户泄露、紧急安全事件。
密码修改与过期（D）：
- 适用于需保留账户但阻断已知密码的场景（如密码泄露后重置）。
- 可结合审计策略记录登录失败尝试。
REVOKE ALL PRIVILEGES：用户仍可连接服务器执行无权限操作（如 SHOW DATABASES），存在安全隐患。
PASSWORD EXPIRE 单独使用：若用户知道当前密码且客户端支持交互式密码更新（如命令行工具），仍可登录。

总结

在 MySQL 8.0 中，A（锁定账户）和 E（修改密码并设置过期）是彻底阻止用户 joe 访问的有效方法。前者直接阻断所有连接，后者通过密码失效和过期机制实现双重认证失败。其他选项或因权限逻辑缺陷、功能不相关被排除。实际生产环境中，建议优先使用账户锁定以确保即时生效，并结合密码策略更新以增强安全性。

题目 145

Which two can minimize security risks when creating user accounts?

A. Avoid the use of wildcards in host names.

B. Avoid the use of wildcards in usernames.

C. Require the use of mixed case usernames.

D. Do not allow accounts without passwords.

E. Require users to have the FIREWALL USER privilege defined.

正确答案

A. Avoid the use of wildcards in host names.

D. Do not allow accounts without passwords.

关键解析

在 MySQL 8.0 中，最小化用户账户创建安全风险的两种有效方法是：

1. 选项 A 的正确性

避免在主机名中使用通配符（如 % 或 _）可以限制用户仅从特定网络或IP访问，防止权限意外扩大。例如：

若使用 'user'@'%'，用户可从任意主机连接，增加了被攻击的风险。
通配符可能导致权限匹配到非预期的数据库或主机（如 db_1 可能匹配 db01、dba1 等），引发安全隐患。

建议实践：

使用具体 IP（如 'user'@'192.168.1.0'）替代通配符。
若必须使用通配符，需对特殊字符进行转义（如 db\_1）。

2. 选项 D 的正确性

禁止无密码账户是基本安全原则，空密码账户极易被恶意利用。

MySQL 默认不允许空密码，但需通过配置强制检查（如启用 validate_password 插件）。
安全策略应要求密码复杂度（长度、混合字符等）并定期更新。

示例配置：

-- 创建用户时必须设置密码
CREATE USER 'secure_user'@'localhost' IDENTIFIED BY 'StrongPass123!';

其他选项的排除原因

选项	排除原因
B. 避免用户名通配符	MySQL 用户名不支持通配符（如 `%`、`_`），此选项无实际意义。
C. 强制混合大小写用户名	MySQL 用户名区分大小写，但混合大小写并非安全风险的关键控制点，且未在安全策略中明确要求。
E. 要求 FIREWALL USER 权限	MySQL 8.0 无内置 `FIREWALL USER` 权限，此为干扰项。

技术扩展

最小权限原则：
- 按需授权（如仅授予 SELECT 而非 ALL PRIVILEGES），避免过度权限。
- 定期审计权限，及时回收冗余授权。
主机名限制的进阶实践：
- 使用 SSL/TLS 加密连接（REQUIRE SSL）强化通信安全。
- 结合防火墙限制数据库端口开放范围。
密码策略强化：
- 启用 validate_password 插件，设置复杂度策略（如长度 ≥ 8、包含大小写字母和特殊字符）。
- 配置密码过期（default_password_lifetime）和历史记录（password_history）防止重复使用。

总结

通过 A（限制主机名通配符）和 D（禁用空密码），可显著降低账户创建时的安全风险。其他选项或因功能不相关、或因策略不直接作用于安全核心而被排除。实际应用中，建议结合最小权限原则、密码策略和网络访问控制，构建多层次安全防护体系。

题目 146

Mary connects to a Linux MySQL Server from a client on a Windows machine. Examine this statement and output:

mysql> SELECT USER() , CURRENT_USER();
+------------------+----------------+
| USER()           | CURRENT_USER() |
+------------------+----------------+
| mary@192.0.2.101 | mary@%         |
+------------------+----------------+
1 row in set (0.00 sec)

Which two are true?

A. Mary connected from a client machine whose IP address is 192.0.2.101.

B. Mary connected to the database server whose IP address is 192.0.2.101.

C. Mary has the privileges of account mary@%.

D. Mary connected using a UNIX socket.

E. Mary authenticated to the account mary@192.0.2.101.

正确答案

A. Mary connected from a client machine whose IP address is 192.0.2.101.

C. Mary has the privileges of account mary@%.

关键解析

1. 选项 A 的正确性

USER() 函数返回当前连接的客户端用户名和来源地址。在输出结果中，USER() 的值为 mary@192.0.2.101，表明 Mary 是从 IP 地址为 192.0.2.101 的客户端机器连接到 MySQL 服务器的。这与选项 A 的描述完全一致。

2. 选项 C 的正确性

CURRENT_USER() 返回的是 MySQL 服务器用于认证的授权账户（即权限关联的账户）。输出中 CURRENT_USER() 的值为 mary@%，说明 Mary 的权限由 mary@% 账户定义，而非客户端地址相关的账户。因此，她拥有 mary@% 账户的所有权限，符合选项 C 的描述。

错误选项排除原因

选项	排除原因
B. 数据库服务器 IP 是 192.0.2.101	`USER()` 中的 IP 地址是客户端的连接来源，而非服务器地址。服务器地址通常由 `@@hostname` 或网络配置决定，此处未体现。
D. 使用 UNIX Socket 连接	若通过 UNIX Socket 连接，`USER()` 通常会显示 `localhost` 或主机名（如 `mary@localhost`），而非 IP 地址。输出中的 IP 表明是 TCP/IP 连接。
E. 认证到 `mary@192.0.2.101`	`CURRENT_USER()` 显示授权账户为 `mary@%`，说明认证时使用的账户是 `mary@%`，而非客户端 IP 关联的账户。MySQL 的权限验证基于授权账户，而非客户端地址。

技术扩展：USER() 和 CURRENT_USER() 的核心区别

功能差异：
- USER()：返回客户端连接时提供的用户名和实际来源地址（如 mary@192.0.2.101），反映连接行为。
- CURRENT_USER()：返回 MySQL 服务器用于权限验证的账户（如 mary@%），决定实际权限。
代理用户场景：
- 若使用代理用户（如用户 A 代理用户 B），USER() 返回代理发起者的信息，而 CURRENT_USER() 返回被代理用户的账户。
权限验证逻辑：
- 权限检查基于 CURRENT_USER() 的授权账户。即使 USER() 显示不同客户端信息，只要 CURRENT_USER() 的账户有权限，操作仍可执行。

总结

在 MySQL 中，A（客户端 IP 地址）和 C（授权账户权限）是本题的正确答案。通过 USER() 和 CURRENT_USER() 的差异，可精准判断连接来源和权限归属。其他选项或因混淆客户端与服务器地址，或因误解认证机制被排除。实际运维中，建议结合 SHOW GRANTS 进一步验证账户权限细节。

题目 147

Which two actions can obtain information about deadlocks?

A. Run the SHOW ENGINE INNODB MUTEX command from the mysql client.

B. Enable the innodb_status_output_locks global parameter

C. Enable the innodb_print_all_deadlocks global parameter.

D. Run the SHOW ENGINE INNODB STATUS command from the mysql client.

E. Use the sys.innodb_lock_waits view.

正确答案

C. Enable the innodb_print_all_deadlocks global parameter.

D. Run the SHOW ENGINE INNODB STATUS command from the mysql client.

关键解析

1. 选项 C 的正确性

启用 innodb_print_all_deadlocks 参数后，所有死锁事件会被记录到 MySQL 错误日志，便于长期监控和分析。

操作方式：

SET GLOBAL innodb_print_all_deadlocks = 1;

优势：
- 记录完整的死锁信息，包括事务操作语句、等待资源和回滚状态。
- 无需实时捕获，适合事后排查和审计。

2. 选项 D 的正确性

执行 SHOW ENGINE INNODB STATUS 命令可直接获取最近一次死锁的详细信息，包括事务操作步骤和资源争用情况。

关键信息位置：在输出结果中查找 LATEST DETECTED DEADLOCK 段落。
优势：
- 实时性强，适合快速定位当前死锁。
- 包含事务 ID、锁类型（如行锁、表锁）、等待资源等细节。

错误选项排除原因

选项	排除原因
A. `SHOW ENGINE INNODB MUTEX`	该命令用于显示互斥锁（Mutex）状态，与死锁无关。
B. `innodb_status_output_locks`	此参数增强锁信息输出的详细程度，但需结合 `SHOW ENGINE INNODB STATUS` 使用，本身不直接提供死锁信息。
E. `sys.innodb_lock_waits`	该视图仅显示当前锁等待情况，无法获取已发生的死锁信息。

技术扩展：死锁信息的完整获取流程

实时捕获最新死锁：
- 通过 SHOW ENGINE INNODB STATUS 获取最后一次死锁的完整上下文。
- 结合 performance_schema.data_locks 和 data_lock_waits 表分析锁持有和等待关系。
长期监控与日志记录：
- 启用 innodb_print_all_deadlocks 参数，所有死锁记录持久化到错误日志。
- 使用工具（如 pt-deadlock-logger）定期解析日志并生成报告。
调试环境：优先使用 SHOW ENGINE INNODB STATUS 快速定位问题。
生产环境：启用 innodb_print_all_deadlocks 避免遗漏历史死锁事件，结合错误日志分析根本原因。

总结

在 MySQL 8.0 中，C（记录所有死锁日志）和 D（查看最新死锁详情）是获取死锁信息的核心方法。前者适合长期监控，后者用于即时诊断。其他选项或因功能不相关、或因信息不完整被排除。实际运维中，建议同时启用这两种机制以全面覆盖死锁排查需求。

题目 148

A scientific data gathering application uses a MySQL instance back end for data management. There is a high concurrency of transactions at thousands of transactions per second of volatile data. A restore from binary logs is planned using the command:

mysqlbinlog \
--start-datetime=‘2019-08-01 11:00:00‘ \
--stop-datetime=‘2019-08-10 08:30:25‘ binlog.000238 binlog.000239 binlog.000240 | mysql

Which two characteristics cause the restore to be inconsistent to the original data?

A. Transaction rate is too high to get a consistent restore.

B. Multiple binary logs cannot be specified on the command line.

C. Temporary tables cannot persist across binary logs.

D. The temporal values do not offer high enough precision.

E. The time span of binary logs is too long to restore.

正确答案

C. Temporary tables cannot persist across binary logs.

D. The temporal values do not offer high enough precision.

关键解析

1. 选项 C 的正确性

在 MySQL 中，临时表（Temporary Tables）的生命周期仅限于当前会话。当使用 mysqlbinlog 工具恢复数据时，如果恢复操作涉及多个二进制日志文件（如 binlog.000238、binlog.000239、binlog.000240），临时表的定义和操作可能分散在不同日志文件中。由于临时表在会话结束后自动销毁，跨日志文件的恢复会导致临时表数据丢失或上下文不连续，从而破坏事务的完整性。例如：

若某个事务在 binlog.000238 中创建了临时表，并在 binlog.000239 中引用该表，恢复时可能因临时表未持久化而失败。

2. 选项 D 的正确性

MySQL 二进制日志中的时间戳默认精度为秒级（如 2019-08-01 11:00:00），但在高并发场景（每秒数千事务）下，同一秒内可能发生多个事务。若恢复命令仅基于秒级时间范围（--start-datetime 和 --stop-datetime），无法精确区分毫秒级的事务顺序，可能导致恢复时事务重放顺序错误，进而引发数据不一致。例如：

两个事务在 11:00:00.123 和 11:00:00.456 提交，但恢复时会视为同一秒内的事务，顺序可能颠倒。

错误选项排除原因

选项	排除原因
A. 事务率过高导致恢复不一致	MySQL 的二进制日志通过两阶段提交（2PC）保证事务原子性，即使高并发也能确保日志顺序一致性。恢复不一致的根源是临时表或时间精度问题，而非事务速率本身。
B. 命令行无法指定多个二进制日志	`mysqlbinlog` 支持同时指定多个二进制日志文件（如示例中的 `binlog.000238`、`binlog.000239`、`binlog.000240`），此选项与实际情况矛盾。
E. 二进制日志时间跨度过长	时间跨度长短不影响恢复逻辑一致性，仅影响恢复耗时。只要日志完整且无其他干扰因素（如临时表、时间精度），长跨度恢复是可行的。

技术扩展

临时表与恢复的局限性

临时表生命周期：临时表仅在创建它的会话中可见，且会话结束后自动删除。跨日志恢复时，若临时表操作分散在多个日志中，恢复进程无法重建完整的会话上下文。
解决方案：
- 避免在事务中使用临时表。
- 使用 --skip-temporary-tables 参数跳过临时表操作（但可能导致数据丢失）。

时间戳精度问题

MySQL 时间精度：MySQL 5.6.4 及以上版本支持微秒级时间戳（如 DATETIME(6)），但二进制日志的 --start-datetime 和 --stop-datetime 参数仍仅支持秒级精度。
精准恢复替代方案：
- 使用 --start-position 和 --stop-position 基于二进制日志事件位置恢复，避免时间精度限制。
- 启用 GTID（全局事务标识符）确保事务顺序一致性。

总结

在高并发事务场景下，临时表的跨日志持久化问题（C）和时间戳精度不足（D）是导致数据恢复不一致的核心原因。其他选项或因功能不相关、或因与 MySQL 实际机制矛盾被排除。实际运维中，建议结合 GTID 和精确位置恢复策略，规避上述问题。

题目 149

Which two are contained in the InnoDB system tablespace (ibdata1) by default?

A. doublewrite buffer

B. change buffer

C. InnoDB Data Dictionary

D. primary indexes

E. table data

F. user privileges

正确答案

A. doublewrite buffer

B. change buffer

关键解析

1. 选项 A 的正确性

双重写入缓冲区（doublewrite buffer） 是 InnoDB 系统表空间（ibdata1）的一部分。
它用于防止操作系统或磁盘的写入操作导致数据页损坏，确保数据写入的原子性。
无论是否启用 innodb_file_per_table，doublewrite buffer 始终存储在系统表空间中。

2. 选项 B 的正确性

更改缓冲区（change buffer） 也存储在系统表空间中，用于缓存对非主键索引的更新操作。
它通过减少随机 I/O 操作来提升性能，尤其适用于写多读少的场景。
与 doublewrite buffer 类似，change buffer 默认存储在系统表空间中，与是否启用独立表空间无关。

其他选项的排除原因

选项	排除原因
C. InnoDB Data Dictionary	数据字典在 MySQL 8.0 中已迁移至系统表（如 `information_schema` 和 `mysql` 数据库），并以 Serialized Dictionary Information (SDI) 存储在 `.ibd` 文件中。
D. primary indexes	主索引默认存储在独立表空间（`.ibd` 文件）中，除非显式禁用 `innodb_file_per_table`。
E. table data	表数据默认通过 `innodb_file_per_table=1` 分离到 `.ibd` 文件，仅当禁用此参数时才存入 `ibdata1`。
F. user privileges	用户权限信息存储在 `mysql` 系统数据库（如 `mysql.user` 表），与 `ibdata1` 无关。

技术扩展

避免 ibdata1 膨胀：
- 启用 innodb_file_per_table 分离表数据。
监控工具：
- 使用 SHOW ENGINE INNODB STATUS 查看双写缓冲区的状态。
- 通过 information_schema.TABLES 分析数据字典的元数据信息。

结论

A 和 B 是唯一两个默认情况下始终存储在 InnoDB 系统表空间（ibdata1）中的选项。其他选项（C、D、E、F）的正确性取决于配置或版本，无法确定为默认行为。

题目 150

Examine these InnoDB Cluster parameter settings:

cluster.setInstanceOption('host1:3377', 'memberWeight', 40)
cluster.setInstanceOption('host2:3377', 'memberWeight', 30)
cluster.setInstanceOption('host3:3377', 'memberweight', 40)
cluster.setInstanceOption('host3:3377', 'exitstateAction', "ABORT_SERVER")
cluster.setOption ("expelTimeout",1)

Now examine the partial status:

"topology": {
    "host1:3377": {
        "address": "host1:3377",
        "mode": "R/O",
        [...]
        "status": "ONLINE",
        "version": "8.0.18"
    },
    "host2:3377": {
        "address": "host2:3377",
        "mode": "R/O",
        [...]
        "status": "ONLINE",
        "version": "8.0.18"
    },
    "host3:3377": {
        "address": "host3:3377",
        "mode": "R/W",
        [...]
        "status": "ONLINE",
        "version": "8.0.18"
    }
}

A permanent network failure isolates host3.

Which two statements are true?

A. The instance deployed on host3 will automatically rejoin the cluster when connectivity is re-established.

B. Failure of the instance deployed on host1 provokes an outage.

C. The instance deployed on host3 is expelled from the cluster and must be rejoined using cluster.addInstance('host3:3377').

D. The primary instance can be specified by using the command cluster.setPrimaryInstance (<host>:<port>).

E. The instance deployed on host2 is elected as the new primary instance.

F. The issuing command cluster.switchToMultiPrimaryMode() will fail to enable multi-primary mode.

正确答案

B. Failure of the instance deployed on host1 provokes an outage.

D. The primary instance can be specified by using the command cluster.setPrimaryInstance (<host>:<port>).

关键解析

1. 选项 B 的正确性

当 host3 因网络隔离被驱逐后，集群剩余 host1 和 host2。此时集群处于 OK_NO_TOLERANCE 状态（仅能容忍零节点故障）。若 host1 再发生故障，剩余 host2 将无法达到多数派（原集群总节点数为 3，需至少 2 个在线节点才能形成法定人数），导致集群无法处理写操作，最终进入 NO_QUORUM 状态并中断服务。

2. 选项 D 的正确性

在单主模式下，即使主节点被驱逐，管理员仍可通过 cluster.setPrimaryInstance(<host>:<port>) 手动指定新的主实例。例如，若当前主节点为 host1，可将其切换为 host2，前提是集群仍处于健康状态（即多数节点在线）。

错误选项排除原因

选项	排除原因
A	`exitStateAction=ABORT_SERVER` 会导致 `host3` 被驱逐时 MySQL 服务终止，需手动重启并执行 `rejoinInstance()` 而非自动重新加入。
C	驱逐后若 `host3` 的 UUID 未变，应使用 `rejoinInstance()` 而非 `addInstance()`。`addInstance()` 仅用于完全新实例的加入。
E	`host1` 的 `memberWeight=40` 高于 `host2` 的 `30`，因此 `host1` 会被优先选举为新主节点。
F	在剩余两节点形成多数派的情况下，`switchToMultiPrimaryMode()` 可正常执行，不会因节点数量不足而失败。

技术扩展

成员权重与选举逻辑
- memberWeight 决定了节点在选举中的优先级。权重越高越可能成为主节点。此场景中，host1 和 host3 的权重均为 40，但 host3 被驱逐后，host1 因权重更高自动成为新主。
驱逐与恢复机制
- expelTimeout=1 表示集群在 1 秒内检测到节点不可达后立即驱逐。
- exitStateAction=ABORT_SERVER 确保被驱逐节点立即停止服务，避免脑裂风险。恢复时需手动重启 MySQL 并调用 rejoinInstance()。
集群状态与容错能力
- OK_NO_TOLERANCE：集群可运行但无冗余，任一节点故障将导致中断。
- NO_QUORUM：无法形成多数派，所有写操作被阻塞，需人工介入修复。

总结

当 host3 被隔离后，集群的可用性高度依赖剩余节点的稳定性。通过合理配置 memberWeight 和 exitStateAction，可优化故障恢复流程，而手动指定主节点（选项D）和警惕单点故障风险（选项B）是维护高可用的关键策略。

题目 151

A clean shutdown was performed with innodb_fast_shutdown=0.

While you were manipulating files, all files were accidentally deleted from the top-level data directory.

Which two files must be restored from backup to allow the DB to restart cleanly?

A. ib_buffer_pool

B. ib_logfile0

C. mysql.ibd

D. ibdata1

E. ibtmp1

F. undo_001

正确答案

C. mysql.ibd

D. ibdata1

关键解析

1. ibdata1（系统表空间文件）

核心作用：
- 存储 InnoDB 的元数据（数据字典）、双写缓冲（Doublewrite Buffer）、更改缓冲（Change Buffer）及撤销日志（Undo Logs）。
- 是 InnoDB 存储引擎启动的基础，缺失会导致数据库无法初始化。
不可替代性：
- 即使启用了 innodb_file_per_table（独立表空间模式），ibdata1 仍必须存在以支持元数据管理和事务回滚。

2. mysql.ibd（系统表文件）

核心作用：
- 存储 MySQL 系统数据库（如 mysql.user、mysql.db 等）的表结构和权限信息。
- 若丢失，数据库无法验证用户身份或加载系统配置，导致启动失败。
恢复必要性：
- 即使其他文件恢复，若 mysql.ibd 缺失，系统表无法重建，数据库仍无法正常启动。

错误选项排除原因

选项	排除原因
A. ib_buffer_pool	缓冲池的磁盘映像（`ib_buffer_pool`）用于加速启动时内存预热，缺失仅影响性能，不影响启动。
B. ib_logfile0	因为是干净关闭，故不需要重做日志文件进行崩溃恢复。
E. ibtmp1	临时表空间文件（`ibtmp1`）在每次启动时自动生成，无需恢复。
F. undo_001	撤销日志（`undo_001`）仅在启用独立 Undo 表空间时存在，默认情况下撤销日志存储在 `ibdata1` 中。

技术扩展

innodb_fast_shutdown=0 的影响：
- 此参数确保关闭时执行完整的清理操作（如合并更改缓冲、刷新脏页），生成一致的日志和表空间状态。
- 若文件丢失，即使关闭过程完整，仍需通过备份恢复核心文件。
其他恢复场景：
- 重做日志损坏：若 ib_logfile0/1 损坏，数据库会尝试自动重建，但需确保 ibdata1 和 mysql.ibd 完整。
- 独立表空间丢失：若 .ibd 文件丢失，可通过 ALTER TABLE ... IMPORT TABLESPACE 从备份恢复，但 ibdata1 和 mysql.ibd 仍是启动前提。

总结

在误删数据目录文件的情况下，ibdata1（系统表空间）和 mysql.ibd（系统表文件）是必须从备份恢复的核心文件，其他文件可通过自动重建或临时生成恢复。恢复后需验证数据一致性，并确保备份策略覆盖关键组件。

题目 152

Examine this command and output:

SELECT * FROM performance_schema.table_io_waits_summary_by_table WHERE COUNT_STAR > 0;

********************************2.row **************************************
OBJECT_TYPE:TABLE
OBJECT_SCHEMA:test
OBJECT_NAME:demo_test
CONUNT_STAR:61567093
SUM_TIMER_WAIT:59009007572922
MIN_TIMER_WAIT:395922
AVG_TIMER_WAIT:958095
MAX_TIMER_WAIT:558852005358
COUNT_READ:38665056
SUM_TIMER_READ:20598719962188
MIN_TIMER_READ:395922
AVG_TIMER_READ:532728
MAX_TIMER_READ:558852005358
COUNT_WRITE:22902028
SUM_TIMER_WRITE:38410287610743
MIN_TIMER_WRITE:1130688
AVG_TIMER_WRITE:1677006
MAX_TIMER_WRITE:17205682920
    COUNT_FETCH:38665056
SUM_TIMER_FETCH:20598719962188
MIN_TIMER_FETCH:395922
AVG_TIMER_FETCH:532728
MAX_TIMER_FETCH:558852005358
 .....
 COUNT_DELETE:22902028
SUM_TIMER_DELETE:38410287610743
MIN_TIMER_DELETE:1130688
AVG_TIMER_DELETE:1677006
MAX_TIMER_DELETE:17205682920

Which two statements are true?

A. Average read times are approximately three times faster than writes.

B. 22902028 rows were deleted. These columns aggregate all delete operations.

C. The longest I/O wait was for writes.

D. The I/O average time is 532728. These columns aggregate all fetch operations.

E. I/O distribution is approximately 50/50 read/write.

正确答案

A. Average read times are approximately three times faster than writes.

D. The I/O average time is 532728. These columns aggregate all fetch operations.

关键解析

1. 选项 A 的正确性

根据输出数据中的 AVG_TIMER_READ=532728（读取平均时间）和 AVG_TIMER_WRITE=1677006（写入平均时间），写入的平均时间大约是读取的 3.15 倍（1677006 ÷ 532728 ≈ 3.15），因此读取速度约为写入的 3 倍。

关键数据：

读取平均耗时：532728 皮秒（约 0.53 毫秒）
写入平均耗时：1677006 皮秒（约 1.67 毫秒）

2. 选项 D 的正确性

AVG_TIMER_FETCH=532728 表示所有 FETCH 操作（如行数据检索）的平均耗时。COUNT_FETCH=38665056 表明该列统计了所有 FETCH 操作的次数和耗时，因此描述正确。

关键数据：

FETCH 操作总次数：38,665,056 次
操作平均耗时：532728 皮秒

错误选项排除原因

选项	排除原因
B	`COUNT_DELETE=22,902,028` 统计的是删除操作次数，而非实际删除的行数（例如，一条 DELETE 语句可能删除多行）。
C	`MAX_TIMER_READ=558,852,005,358`（读取最大耗时）远高于 `MAX_TIMER_WRITE=17,205,682,920`（写入最大耗时），因此最长 I/O 等待发生在读取操作。
E	读取操作占比为 63%（38,665,056 ÷ 61,567,093），写入操作占比 37%（22,902,028 ÷ 61,567,093），分布不均衡。

技术扩展

性能监控工具的使用：
- table_io_waits_summary_by_table 是 Performance Schema 的核心表之一，用于定位高 I/O 负载的表。
- 通过 SUM_TIMER_WAIT 和 COUNT_STAR 可计算全局 I/O 压力，结合 AVG_TIMER_* 可优化慢查询或存储引擎配置。
计时器单位与转换：
- MySQL 的计时器单位为皮秒（1 秒=10¹² 皮秒），需转换为毫秒（1 毫秒=10⁹ 皮秒）便于理解。
- 示例：AVG_TIMER_READ=532,728 皮秒 ≈ 0.53毫秒。
优化建议：
- 读写分离：若写入耗时较高，可考虑将写操作分散到副本或使用异步提交。
- 索引优化：高读取耗时可能因全表扫描或低效索引导致，需检查执行计划。

总结

通过Performance Schema 的 table_io_waits_summary_by_table 表，可精准定位 I/O 瓶颈。本题中，读取性能显著优于写入（选项 A），而 FETCH 操作的耗时统计验证了性能监控的粒度（选项 D）。实际运维中需结合此类数据优化查询和存储配置。

题目 153

Which two statements are true about using backups of the binary log?

A. Binary logs are relatively small, and therefore, excellent for long-term storage and disaster recovery.

B. Binary logs can always be used to unapply unwanted schema changes.

C. Multiple binary logs can be used to restore data.

D. They allow for point-in-time recovery of the data.

E. Multiple binary logs can be applied in parallel for faster data restoration.

正确答案

C. Multiple binary logs can be used to restore data.

D. They allow for point-in-time recovery of the data.

关键解析

1. 选项 C 的正确性

二进制日志文件按顺序生成（如 mysql-bin.000001、mysql-bin.000002），每个文件记录了特定时间段内的数据库变更事件。在数据恢复时，需按顺序应用多个日志文件，覆盖从全量备份到故障点的所有操作。例如：

mysqlbinlog mysql-bin.000001 mysql-bin.000002 | mysql -u root -p

此操作会合并两个日志文件的内容并顺序执行，确保数据连续性。

2. 选项 D 的正确性

二进制日志的核心功能之一是支持时间点恢复（PITR）。通过解析日志中的时间戳或事件位置，可将数据库恢复到任意时间点的状态。例如：

mysqlbinlog --start-datetime="2025-05-20 00:00:00" --stop-datetime="2025-05-20 23:59:59" mysql-bin.000003 | mysql -u root -p

此命令可将数据库恢复到 2025 年 5 月 20 日当天的状态。此功能尤其适用于误删数据后的恢复场景。

错误选项排除原因

选项	排除原因
A	二进制日志可能因频繁操作变得非常庞大（例如 `max_binlog_size` 默认限制为 1 GB），需定期清理或滚动生成新文件。因此不适合长期存储。
B	若误操作（如 `DROP TABLE`）已提交，需通过时间点恢复排除该事件，而非直接“撤销”操作。仅当明确知道误操作位置时才能选择性跳过。
E	二进制日志必须按生成顺序串行应用，并行执行会导致事务顺序错乱，破坏数据一致性。

技术扩展

二进制日志管理策略
- 日志滚动：通过 max_binlog_size 控制单个文件大小，超过阈值自动生成新文件。
- 自动清理：设置 expire_logs_days 参数（如 7 天）自动删除过期日志。
- 索引文件：mysql-bin.index 记录所有日志文件路径，便于恢复时快速定位。

恢复流程示例：

全量备份恢复：

mysql -u root -p < full_backup.sql

增量恢复：

mysqlbinlog mysql-bin.000001 mysql-bin.000002 | mysql -u root -p

结合全量备份与增量日志，实现完整恢复。

主从复制的依赖：

二进制日志是主从同步的基础。主库将日志发送给从库，从库重放事件以实现数据一致性。

总结

二进制日志通过记录所有数据变更事件，支持多文件顺序恢复（C）和精准时间点恢复（D），是 MySQL 高可用架构的核心组件。实际运维中需结合全量备份与日志管理策略，确保数据安全与恢复效率。

题目 154

You are backing up raw InnoDB files by using mysqlbackup.

Which two groups of files will be backed up during a full backup?

A. *.ibd files

B. ibbackup files

C. *.CSM files

D. ib_logfile* files

E. *.sdi files

正确答案

A. *.ibd files

D. ib_logfile* files

关键解析

1. 选项 A 的正确性

*.ibd 文件是 InnoDB 的独立表空间文件，每个表对应一个 .ibd 文件（当启用 innodb_file_per_table 时）。mysqlbackup 的全备份会直接复制这些文件，包含用户表数据和索引。

关键点：

独立表空间文件是 InnoDB 物理备份的核心内容。
系统表空间 ibdata* 文件也包含部分用户表数据（如果未启用独立表空间），但 .ibd 文件是显式备份的独立表空间文件。

2. 选项 D 的正确性

虽然 ib_logfile*（重做日志文件）在备份时不会直接复制原始文件，但 mysqlbackup 会提取日志内容并存储到新文件 ibbackup_logfile 中。此文件包含备份期间产生的所有重做日志信息，用于恢复时保证数据一致性。

关键点：

重做日志的实时变化通过 ibbackup_logfile 捕获，而非直接备份原 ib_logfile* 文件。
这一过程确保了备份期间未丢失任何事务操作。

其他选项排除原因

选项	排除原因
B. `ibbackup` 文件	`ibbackup` 文件是由 `mysqlbackup` 工具生成的备份文件相关产物，并不是原始 InnoDB 需要备份的文件，而是备份过程中产生的文件，所以在备份原始 InnoDB 文件时不会备份它
C. `*.CSM` 文件	`*.CSM` 是 MyISAM 压缩表的元数据文件，与 InnoDB 无关。
E. `*.sdi`文件	`.sdi`文件存储表的元数据（MySQL 8.0+），但题目描述中未明确提及，且mysqlbackup通过`mysql.ibd`（数据字典）和`.ibd`文件已涵盖必要元信息。

技术扩展

备份文件分类
- 核心数据文件：
  - ibdata*：系统表空间（元数据、Undo Log 等）。
  - mysql.ibd：存储数据字典（如 mysql.user 表）。
  - .ibd：独立表空间文件（用户表数据及索引）。
- 日志处理：
  - 重做日志（ib_logfile*）的内容被提取到 ibbackup_logfile，而非直接备份原文件。
  - 撤销日志（undo_*）若启用独立表空间则备份，否则存储在ibdata*中。
恢复流程
- 物理恢复：通过复制备份的 .ibd 和 ibdata* 文件到数据目录，结合 ibbackup_logfile 回放事务日志，确保数据一致性。
- 元数据依赖：mysql.ibd 的完整性是关键，否则无法重建系统表结构。

总结

mysqlbackup 的完整备份包含独立表空间文件（.ibd）和处理后的重做日志信息（通过 ibbackup_logfile）。其他文件（如 ibdata* 和 undo_*）根据配置选择性包含，但题目选项中仅需选择明确提及的 A 和 D。

题目 155

Which two are characteristics of snapshot-based backups?

A. The frozen file system can be cloned to another virtual machine immediately into active service.

B. There is no need for InnoDB tables to perform its own recovery when restoring from the snapshot backup.

C. Snapshot-based backups greatly reduce time during which the database and applications are unavailable.

D. A separate physical copy must be made before releasing the snapshot backup.

E. Snapshot backups can be used only in virtual machines.

正确答案

C. Snapshot-based backups greatly reduce time during which the database and applications are unavailable.

D. A separate physical copy must be made before releasing the snapshot backup.

关键解析

1. 选项 C 的正确性

快照备份的核心优势在于其瞬时性和低资源占用。通过创建数据在某一时间点的镜像（如存储设备级的快照或文件系统级的硬链接），备份过程几乎无需暂停数据库或应用服务。例如：

写时复制（COW）：仅需在首次修改数据块时复制旧数据到快照区域，备份期间数据库仍可正常运行。
虚拟化环境：VMware 和 Hyper-V 的快照功能允许在几秒内完成数据状态捕获，极大缩短备份窗口。

此特性在关键业务场景（如 SRE 故障恢复、高并发事务处理）中尤为重要，确保业务连续性。

2. 选项 D 的正确性

快照备份的底层实现要求物理副本分离：

COW 机制：修改数据块前需将旧数据复制到快照空间，形成独立副本，否则释放快照会导致数据丢失。
存储设备实现：如 NetApp 的 SnapMirror 技术，快照释放前需确保数据镜像已完全写入独立存储区域，而非仅保留指针。

错误选项排除原因

选项	排除原因
A	快照克隆需依赖存储设备功能（如 HyperSnap 的 LUN 克隆），并非所有环境均支持“立即激活服务”。且克隆后的数据需验证一致性，无法保证零延迟切换。
B	InnoDB 恢复依赖事务日志（如 `ib_logfile*`），快照备份仅提供数据文件镜像，恢复时仍需应用日志以修复未提交事务。
E	快照技术广泛用于物理存储（如 ZFS、Azure Blob Storage）、数据库（如 MySQL、SQL Server）及虚拟化环境，不局限于虚拟机。

技术扩展

快照备份的实现层级：
- 存储级：如 ZFS 的 zfs snapshot，直接基于存储卷生成数据镜像。
- 文件系统级：如 rsnapshot 利用硬链接减少磁盘占用，但需定期合并增量。
- 数据库级：MySQL 的 FLUSH TABLES WITH READ LOCK 配合文件系统快照，确保数据一致性。
备份与恢复流程优化：
- 增量快照：仅记录变化数据块，减少存储开销（如 Azure 的每日快照+事务日志备份）。
- 并行恢复：通过分布式快照协议（如 Chandy-Lamport 算法）加速大规模系统恢复。
混合备份策略：
- 快照 + 逻辑备份：快照用于快速恢复，逻辑备份（如 mysqldump）保障数据逻辑一致性。
- 多版本保留：通过保留多个时间点的快照，支持灵活的时间点恢复（PITR）。

总结

快照备份通过瞬时捕获数据状态和分离物理副本的特性，成为现代数据保护的核心技术。正确选项 C 和 D 分别体现了其效率优势和底层实现要求，而其他选项因依赖特定场景或忽略技术细节被排除。实际应用中需结合存储架构、业务负载选择适配的快照策略。

题目 156

Examine these statements, which execute successfully:

TRUNCATE test;
BEGIN;
INSERT INTO test (id, name) VALUES(1, "Hello") ;
ROLLBACK;
SELECT id FROM test;

Which three storage engines would return a nonempty recordset for the test table when executing the statements?

A. MEMORY

B. BLACKHOLE

C. ARCHIVE

D. NDB

E. MyISAM

F. InnoDB

正确答案

A. MEMORY

C. ARCHIVE

E. MyISAM

关键解析

存储引擎的事务支持与操作行为分析

题目中的 SQL 执行流程如下：

TRUNCATE test;：清空表数据（DDL 操作，不可回滚）。
BEGIN;：开启事务（仅对支持事务的引擎有效）。
INSERT INTO test (id, name) VALUES(1, "Hello");：插入数据。
ROLLBACK;：回滚事务（仅对支持事务的引擎有效）。
SELECT id FROM test;：查询结果。

关键点在于：

事务支持：若存储引擎支持事务，则 ROLLBACK 会撤销 INSERT 操作，查询结果为空。
事务不支持的引擎：ROLLBACK 无效，INSERT 操作会立即提交，查询结果包含插入的数据。
TRUNCATE 特性：TRUNCATE 是 DDL 操作，无论引擎是否支持事务，均会立即清空数据且不可回滚。

各存储引擎的行为对比

MEMORY (A)
- 特性：基于内存存储，不支持事务。
- 行为：ROLLBACK 无法撤销 INSERT，数据保留，查询结果非空。
ARCHIVE (C)
- 特性：设计用于日志和归档存储，不支持事务和行级锁。
- 行为：ROLLBACK 无效，INSERT 操作直接生效，查询结果非空。
MyISAM (E)
- 特性：非事务型引擎，仅支持表级锁。
- 行为：BEGIN 和 ROLLBACK 被忽略，INSERT 立即提交，查询结果非空。

排除其他选项的原因

BLACKHOLE (B)：黑洞引擎不存储数据，所有 INSERT 操作被丢弃，查询结果始终为空。
NDB (D)：NDB（Cluster）支持事务，ROLLBACK 会撤销 INSERT，结果为空。
InnoDB (F)：支持事务，ROLLBACK 撤销 INSERT，结果为空。

技术扩展

事务与非事务引擎的核心差异
- 事务引擎（如 InnoDB、NDB）：通过 UNDO_LOG 记录操作，支持回滚和数据一致性。
- 非事务引擎（如 MyISAM、MEMORY）：操作直接持久化，无法回滚，依赖应用层处理错误。
TRUNCATE 与 DELETE 的差异
- TRUNCATE：DDL 操作，删除所有数据并释放表空间，不可回滚。
- DELETE：DML 操作，逐行删除并记录日志，支持回滚。
应用场景建议
- 高并发写入：选择事务引擎（如 InnoDB）保障数据一致性。
- 临时数据或高速缓存：使用 MEMORY 引擎提升性能，但需注意数据易失性。
- 日志归档：ARCHIVE 引擎压缩存储，节省空间。

总结

本题通过分析存储引擎的事务支持特性，结合 SQL 操作流程，得出 MEMORY、ARCHIVE 和 MyISAM 会返回非空记录集。其他引擎因事务支持或黑洞特性导致结果为空。实际开发中需根据业务需求合理选择存储引擎。

题目 157

Which two statements are true about the binary log encryption feature?

A. It requires a keyring plugin.

B. When enabled it encrypts existing binary logs.

C. It can be set at run time.

D. It can be activated per session.

E. It encrypts any connecting slaves connection thread.

正确答案

A. It requires a keyring plugin.

C. It can be set at run time.

关键解析

1. 选项 A 的正确性

MySQL 的二进制日志（Binary Log）加密功能依赖密钥环插件或组件（如 keyring_file 或 component_keyring_file）管理加密密钥。密钥环负责存储主加密密钥（Master Key），用于加密二进制日志文件的文件密码（File Password）。例如，配置文件中需明确加载密钥环插件：

[mysqld]
early-plugin-load=keyring_file.so
keyring_file_data=/path/to/keyring

若未安装密钥环，加密功能无法启用。此依赖性是加密功能的基础。

2. 选项 C 的正确性

二进制日志加密可通过全局系统变量 binlog_encryption 动态启用或禁用，无需重启 MySQL 服务。例如：

SET GLOBAL binlog_encryption = ON;-- 动态开启加密
SET GLOBAL binlog_encryption = OFF; -- 动态关闭加密

此特性使得管理员可根据安全需求灵活调整加密状态，而无需停机。

错误选项排除原因

选项	排除原因
B	启用加密时仅对新生成的二进制日志生效，现有日志不会被自动加密。需手动清理旧日志或等待其过期。
D	`binlog_encryption` 是全局参数，不支持会话级配置。所有会话共享同一加密状态。
E	加密功能保护二进制日志文件本身，不涉及主从复制的连接线程。主从传输需通过 SSL/TLS 独立配置加密。

技术扩展

加密实现细节
- 密钥架构：采用双层加密（Two-Tier Encryption）。主密钥（Master Key）加密文件密码，文件密码加密实际日志数据。主密钥可定期轮换（ALTER INSTANCE ROTATE INNODB MASTER KEY），仅需重新加密文件密码，无需重写全部日志。
- 算法：默认使用 AES-CTR 模式加密临时缓存文件，确保数据在磁盘和内存中的安全性。
兼容性与限制
- 工具支持：加密的二进制日志无法直接通过 mysqlbinlog 解析，需通过 --read-from-remote-server 从服务器解密读取。
- 性能影响：加密会引入额外计算开销，建议结合硬件加速（如 AES-NI 指令集）优化性能。

总结

二进制日志加密通过密钥环插件实现密钥管理（选项 A），并支持运行时动态配置（选项 C）。其他选项因技术细节或功能范围不符被排除。实际部署时需结合密钥轮换策略和传输层加密（如 SSL/TLS）构建全链路安全防护。

题目 158

Examine this MySQL client command to connect to a remote database:

mysql -h remote.example.org -u root -p --protocol=TCP --ssl-mode=

Which two --ssl-mode values will ensure that an X.509-compliant certificate will be used to establish the SSL/TLS connection to MySQL?

A. DISABLED

B. REQUIRED

C. VERIFY_IDENTITY

D. PREFERED

E. VERIFY_CA

正确答案

C. VERIFY_IDENTITY

E. VERIFY_CA

关键解析

1. 选项 C（VERIFY_IDENTITY）的正确性

VERIFY_IDENTITY 是 MySQL 客户端 --ssl-mode 参数的最高安全级别，要求客户端不仅验证服务器证书的合法性（由受信任的 CA 签发），还需验证证书中的主题（Subject）是否与连接的主机名完全匹配。

X.509 证书要求：
- 服务器证书必须包含与连接主机名（如 remote.example.org）一致的 Common Name (CN) 或 Subject Alternative Name (SAN)。
- 客户端需配置 --ssl-ca 参数以信任签发服务器证书的 CA。
适用场景：
- 适用于严格防止中间人攻击的环境，如金融系统或敏感数据访问。

2. 选项 E（VERIFY_CA）的正确性

VERIFY_CA 要求客户端验证服务器证书的有效性（由受信任的 CA 签发），但不检查证书主题是否与主机名匹配。

X.509 证书要求：
- 服务器证书必须由客户端信任的 CA 签发。
- 客户端需通过 --ssl-ca 指定 CA 证书路径。
适用场景：
- 适用于内部网络或信任证书签发机构的环境，无需严格主机名匹配。

错误选项排除原因

选项	排除原因
A. DISABLED	完全禁用 SSL/TLS 加密，连接不验证证书，违反 X.509 合规性要求。
B. REQUIRED	强制使用加密，但仅要求服务器支持 SSL/TLS，不验证证书合法性，可能使用自签名证书或无效 CA 签发的证书。
D. PREFERRED	默认模式，仅在服务器支持时启用加密，不强制验证证书，可能回退到未加密连接。

技术扩展

证书验证层级：
- VERIFY_CA：仅验证证书链的有效性。
- VERIFY_IDENTITY：验证证书链 + 主机名匹配。
- X.509 标准：包含证书版本、序列号、颁发者、有效期、公钥等信息，确保身份可信。

配置示例：

客户端命令强制使用 X.509 验证：

mysql -h remote.example.org -u root -p --ssl-mode=VERIFY_CA \
--ssl-ca=/path/to/ca.pem

服务端需启用 SSL 并配置有效证书：

[mysqld]
ssl-ca = /path/to/ca.pem
ssl-cert = /path/to/server-cert.pem
ssl-key = /path/to/server-key.pem
require_secure_transport = ON# 强制所有连接加密

验证当前连接状态：执行 \s 命令查看 SSL 状态：

mysql> \s
SSL: Cipher in use is TLS_AES_256_GCM_SHA384# 表示加密已启用

总结

为确保 MySQL 客户端通过 X.509 证书建立 SSL/TLS 连接，必须选择 VERIFY_CA（验证证书合法性）或 VERIFY_IDENTITY（额外验证主机名）。其他模式因缺乏证书验证或加密强制要求，无法满足 X.509 标准。实际部署时，建议结合服务端 require_secure_transport 配置，强制所有连接加密。

题目 159

Examine this query and its output:

mysql> select * from sys.user_summary_by_statement_type where statement in ('select', 'insert', 'Quit');

+------+-----------+--------+---------------+-------------+--------------+----------+--------------+--------------+-----------+
| user | statement | total  | total_latency | max_latency | lock_latency | rows_sent| rows_examined| rows_affected| full_scans|
+------+-----------+--------+---------------+-------------+--------------+----------+--------------+--------------+-----------+
| app  | select    | 919866 | 2.41 h        | 330.01 ms   | 1.52 m       | 542614816| 542614816    | 0            | 919958    |
| app  | insert    | 923070 | 1.66 h        | 287.41 ms   | 1.65 m       | 0        | 0            | 923026       | 0         |
| app  | Quit      | 679892 | 9.54 s        | 170.97 ms   | 0 ps         | 0        | 0            | 0            | 0         |
| bob  | select    | 344964 | 53.61 m       | 328.42 ms   | 34.51 s      | 203509545| 203509542    | 0            | 344847    |
| bob  | insert    | 346159 | 37.94 m       | 235.77 ms   | 36.94 s      | 0        | 0            | 346175       | 0         |
| bob  | Quit      | 254971 | 3.65 s        | 69.91 ms    | 0 ps         | 0        | 0            | 0            | 0         |
| root | select    | 230621 | 38.88 m       | 21.47 s     | 23.81 s      | 135639074| 135644067    | 0            | 230595    |
| root | insert    | 231585 | 25.86 m       | 364.22 ms   | 31.45 s      | 0        | 0            | 4150423      | 0         |
| root | Quit      | 170363 | 2.24 s        | 130.14 ms   | 0 ps         | 0        | 0            | 0            | 0         |
+------+-----------+--------+---------------+-------------+--------------+----------+--------------+--------------+-----------+

9 rows in set (0.00 sec)

Which two statements are true?

A. User bob had a significantly higher ratio of SELECT + INSERT statements to QUIT than both app and root users.

B. User bob had the largest total time waiting for locks.

C. The app user had the highest total number of rows read from storage engines.

D. The root user had the largest number of modified rows for a SELECT statement.

E. The root user had the largest single wait time.

正确答案

C. The app user had the highest total number of rows read from storage engines.

E. The root user had the largest single wait time.

关键解析

1. 选项 C 的正确性

通过查询结果的 rows_examined（存储引擎读取的行数）字段可知：

app 用户：在 SELECT 操作中 rows_examined = 542,614,816，远高于其他用户（如 bob 的 203,509,542 和 root 的 135,644,067）。
关键点：rows_examined 表示从存储引擎读取的总行数，数值越大说明查询涉及的数据扫描量越大。app 用户的数值显著高于其他用户，符合选项描述。

2. 选项 E 的正确性

通过 max_latency（单次最长等待时间）字段对比：

root 用户：在 SELECT 操作中 max_latency = 21.47秒，远高于其他用户的最高值（如 app 的 330.01 毫秒和 bob 的 328.42 毫秒）。
关键点：max_latency 反映单次操作的极端性能问题，root 用户的高值可能由复杂查询或资源争用导致。

错误选项排除原因

选项	排除原因
A	所有用户的 `(SELECT+INSERT)/QUIT` 比值接近： - `app`: `(919,866+923,070)/679,892 ≈ 2.71` - `bob`: `(344,964+346,159)/254,971 ≈ 2.71` - `root`: `(230,621+231,585)/170,363 ≈ 2.71`，比值相同，无显著差异。
B	总锁等待时间（`lock_latency`）： - `app` 的 `1.52m + 1.65m = 3.17分钟`，远高于 `bob` 的 `34.51s + 36.94s ≈ 71秒` 和 `root` 的 `23.81s + 31.45s ≈ 55秒`。
D	`SELECT` 语句的 `rows_affected` 列在所有用户中均为 `0`，仅 `INSERT` 操作有 `rows_affected`。`root` 的 `INSERT` 操作 `rows_affected = 4,150,423`，但选项描述为 SELECT 语句，因此错误。

技术扩展

user_summary_by_statement_type 视图的作用
- 该视图按用户和语句类型（如 SELECT、INSERT）聚合性能数据，用于分析查询负载和性能瓶颈。
- 核心字段包括：
  - total_latency：总延迟，反映整体性能消耗。
  - rows_examined：存储引擎读取的行数，衡量查询效率（如索引是否有效）。
  - max_latency：单次操作的最大延迟，定位极端性能问题。
性能优化建议
- app 用户的高 rows_examined：
  - 检查查询是否缺乏有效索引，导致全表扫描。
  - 优化 SQL 写法，减少 WHERE 条件中的非索引字段过滤。
- root 用户的高 max_latency： - 分析慢查询日志（slow_query_log），定位具体 SQL。 - 检查锁争用情况（如 SHOW ENGINE INNODB STATUS）。
锁等待的监控与处理
- 使用 sys.innodb_lock_waits 视图查看当前锁等待事务。
- 通过 innodb_lock_wait_timeout 参数调整锁等待超时时间，避免长时间阻塞。

总结

通过分析 user_summary_by_statement_type 的查询结果，可快速定位用户的性能瓶颈：

C 正确：app 用户的 rows_examined 最高，表明其查询涉及大量数据扫描。
E 正确：root 用户的 max_latency 最大，需排查慢查询或锁争用问题。

其他选项因数据不符或逻辑错误被排除。实际运维中需结合此类视图优化索引、SQL 设计及锁策略。

题目 160

Which two statements are true about MySQL Installer?

A. It provides only GUI-driven, interactive installations.

B. It installs most Oracle MySQL products.

C. Manual download of separate product packages is required before installing them through MySQL Installer.

D. It provides a uniform installation wizard across multiple platforms.

E. It performs product upgrades.

正确答案

B. It installs most Oracle MySQL products.

E. It performs product upgrades.

关键解析

1. 选项 B 的正确性

MySQL Installer 支持安装 Oracle MySQL 官方提供的核心产品和工具，包括但不限于：

MySQL Server（数据库服务）
MySQL Workbench（图形化管理工具）
MySQL Router（路由组件）
MySQL Shell（增强命令行工具）
Connectors（如 Connector/ODBC、Connector/Python 等）。

这些组件覆盖了开发、管理和运维的主要需求，符合“安装大多数 Oracle MySQL 产品”的描述。

2. 选项 E 的正确性

MySQL Installer 具备自动检测并升级已安装产品的功能。例如：

通过安装向导的更新管理模块，可一键下载并安装最新版本或补丁。
支持从旧版本（如 5.7）升级到 8.0，同时兼容小版本之间的平滑升级（如 8.0.20 到 8.0.23）。

错误选项排除原因

选项	排除原因
A	MySQL Installer 虽然提供 GUI 向导简化安装流程，但同时也支持静默安装（通过命令行参数配置安装选项），并非“仅 GUI 驱动”。
C	所有组件均通过 MySQL Installer 在线下载，无需用户手动预先下载单独包。
D	MySQL Installer 仅支持 Windows 平台，Linux 等其他平台需通过二进制包或系统包管理器（如 APT/YUM）安装，不存在“跨平台统一向导”。

技术扩展

MySQL Installer 的核心功能
- 组件选择灵活性：允许用户自定义安装的组件组合（如仅安装 Server 或 Workbench）。
- 自动化配置：自动设置端口号、字符集（默认 UTF8MB4）、~root· 密码等参数，减少手动操作。
- 权限管理：安装后可直接在向导中配置用户权限和角色，支持安全连接（SSL/TLS）。
升级与兼容性注意事项
- 版本兼容性：升级前需备份数据并使用 mysql_upgrade 工具检查元数据兼容性。
- 密码策略：8.0 默认使用 caching_sha2_password 认证插件，旧版客户端需更新驱动以支持。

总结

MySQL Installer 在 8.0 版本中通过集成化安装和升级功能，显著简化了 Windows 平台上的 MySQL 部署流程，支持主流产品的一站式管理（选项 B）和版本更新（选项 E）。其他选项因技术限制或功能范围不符被排除。实际部署时，建议结合官方文档选择适配的安装策略。

题目 161

Which three actions are effective in capacity planning?

A. buying more RAM

B. monitoring OS resources for patterns

C. adding circular replication nodes for increased DML capability

D. buying more CPU

E. buying more disk

F. basing expected growth on an average of the last 3 years

G. consulting the application team about any future projects and use

H. upgrading to the latest application version

正确答案

B. monitoring OS resources for patterns

F. basing expected growth on an average of the last 3 years

G. consulting the application team about any future projects and use

解析与依据

1. 选项 B 的正确性

监控操作系统资源的使用模式是容量规划的基础。通过实时跟踪 CPU、内存、磁盘 I/O 等指标，可以发现系统的瓶颈并预测未来的资源需求。例如，通过工具（如 Percona Monitoring）分析慢查询日志或资源利用率，能够明确是否需要扩容或优化配置。

2. 选项 F 的正确性

基于历史数据（如过去三年的平均增长）进行趋势预测，是容量规划的常见方法。通过分析历史负载和资源消耗的规律，可以建立数学模型来预估未来的扩展需求。尽管需结合其他因素（如业务变化），但历史数据为初始规划提供了重要参考。

3. 选项 G 的正确性

与应用团队沟通未来的项目规划和业务需求，能更精准地预测资源需求。例如，新功能上线或用户量激增可能导致数据库负载突增，提前了解这些信息有助于制定针对性的扩容策略。

错误选项排除原因

选项	排除原因
A/D/E	购买硬件（RAM、CPU、磁盘）是扩容的实施步骤，但题目聚焦于容量规划的决策过程，需优先评估需求而非直接购买。
C	添加循环复制节点（Circular Replication）并非 MySQL 主流水平扩展方案，实际中更推荐主从复制或分片技术。
H	升级应用版本属于软件维护，与资源容量规划无直接关联。

技术扩展

容量规划的核心流程
- 评估现状：通过监控工具（如 MySQL Workbench）收集资源使用数据，识别瓶颈。
- 预测需求：结合历史数据（选项 F）和业务规划（选项 G）建模，预估未来负载。
- 制定方案：根据预测结果选择垂直扩展（如升级硬件）或水平扩展（如分片、主从复制）。
历史数据的局限性
- 仅依赖历史平均增长（选项F）可能忽略突发流量或业务转型的影响，因此需结合压力测试和弹性设计。
与应用团队协作的重要性
- 业务需求变化（如促销活动、新功能）直接影响数据库负载。定期沟通可避免因信息不对称导致的资源不足或浪费。

总结

有效的容量规划需综合资源监控（选项 B）、历史数据分析（选项 F）和业务需求预判（选项 G）。其他选项因技术局限或脱离规划阶段被排除。实际应用中，建议结合自动化工具（如 Prometheus）和动态扩容策略（如云数据库弹性伸缩）实现持续优化。

题目 162

Choose the best answer.

Four nodes are configured to use circular replication. Examine these configuration parameters for each each node:

slave_parallel_type=DATABASE ;
slave_parallel_workers=4
slave_preserve_commit_order=0

Which statement is true?

A. Each slave thread is responsible for updating a specific database.

B. Cross-database constraints can cause database inconsistency.

C. Setting slave_parallel_type=DATABASE won't work for circular replication; it should be set to LOGICAL_CLOCK.

D. Increasing slave_parallel_workers will improve high availability.

E. Setting slave_preserve_commit_order to ON will improve data consistency.

F. Setting transaction_allow_batching to ON will improve data consistency.

最佳答案

B. Cross-database constraints can cause database inconsistency.

关键解析、

题干描述了一个 4 节点的环形复制（circular replication）架构，并提供了以下配置参数：

使用数据库级别的并行复制（slave_parallel_type=DATABASE）。
- 表示每个数据库由一个单独的复制线程处理。
- 不同数据库之间的事务可以并行执行。
- 但跨数据库的事务或操作无法保证执行顺序，可能导致数据一致性问题。
启用了 4 个并行复制线程（slave_parallel_workers=4）。
不保证事务提交顺序（slave_preserve_commit_order=0）。
- 意味着复制线程不会按照原主库的提交顺序来应用事务。
- 这会增加数据不一致的风险，尤其是涉及多个数据库的操作。

在环形复制架构中，每个节点都可以作为主节点写入，并将更改传播到下一个节点。如果没有良好的事务顺序控制和一致性保障机制，很容易出现数据冲突或不一致。当配置参数 slave_parallel_type=DATABASE 且 slave_preserve_commit_order=0 时，跨数据库约束（如外键关联不同库的表）可能导致数据不一致。这是因为 MySQL 的并行复制按数据库划分事务执行，不同数据库的事务可能并行执行，导致从库的事务提交顺序与主库不一致。例如：

主库按顺序提交事务 A（操作库 1）和事务 B（操作库 2），但从库可能因并行执行导致 B 先于 A 提交，从而违反跨库外键约束。

此问题在环形复制中尤为突出，因为多个节点可能同时修改关联数据，加剧不一致风险。

其他选项排除原因

选项	排除原因
A	`slave_parallel_type=DATABASE` 根据事务操作的数据库动态分配线程，而非固定绑定线程与数据库。
C	`DATABASE` 模式在环形复制中可用，但需确保不同节点操作独立数据库且无跨库约束。
D	增加 `slave_parallel_workers` 仅提高并行度，与高可用性（HA）无关。HA 需通过冗余、故障切换等机制实现。
E	`slave_preserve_commit_order=ON` 确保提交顺序与主库一致，但仅在 `slave_parallel_type=LOGICAL_CLOCK` 时生效（`DATABASE` 模式下忽略此参数）。
F	`transaction_allow_batching` 是无效参数（可能混淆项），且与数据一致性无关。

技术扩展

环形复制的并行策略与风险
- DATABASE 模式的适用性：适合节点操作独立数据库的场景。若不同节点写入不同库，可减少冲突；但跨库事务会破坏隔离性。
- LOGICAL_CLOCK 的对比：基于事务组的并行策略（如主库组提交的事务组），并行度更高且支持跨库事务，但需配合 slave_preserve_commit_order=ON 保证顺序。
slave_preserve_commit_order 的底层机制
- 当启用该参数时，从库通过全局队列（GAQ）协调事务提交顺序。即使事务由不同线程并行执行，最终提交时需按主库顺序排队，避免乱序。
- 性能权衡：强制顺序提交可能增加从库延迟，需通过调整 slave_checkpoint_period 平衡性能与一致性。
环形复制的运维建议
- 跨库约束处理：若业务必须跨库，建议改用 LOGICAL_CLOCK 并行模式，并开启 slave_preserve_commit_order=ON。
- 监控工具：使用 SHOW SLAVE STATUS 或 Percona Monitoring 跟踪复制延迟和冲突。

总结

在给定的配置下，跨数据库约束是导致数据不一致的直接原因（选项 B）。

题目 163

Choose the best answer.

Examine this command:

shell> mysqldump --no-create-info --all-databases --result-file=dump.sql

Which statement is true?

A. It will not write CREATE TABLESPACE statements.

B. It will not write CREATE LOGFILE GROUP statements.

C. It will not write CREATE DATABASE statements.

D. It will not write CREATE TABLE statements.

最佳答案

D. It will not write CREATE TABLE statements.

关键解析

关键参数作用

--no-create-info：此选项的作用是禁止生成表结构相关的 SQL 语句（如 CREATE TABLE），仅导出数据。因此，生成的 dump.sql 文件中不会包含创建表的语句。
- 示例：若备份包含 user 表，导出文件中仅有 INSERT INTO user ... 语句，而无 CREATE TABLE user ... 语句。
--all-databases：此选项表示导出所有数据库，默认会包含以下内容：
- CREATE DATABASE 语句：用于重建数据库。
- 表数据（INSERT 语句）：即使使用 --no-create-info，数据仍会被导出。
- 存储过程、函数等（需配合 --routines 参数）。

选项分析

选项	正确性	原因
A. 不写入 `CREATE TABLESPACE` 语句	错误	`--no-create-info` 仅影响表结构（如 `CREATE TABLE`），而 `TABLESPACE` 属于存储引擎层（如 InnoDB）的配置，与表结构无关。
B. 不写入 `CREATE LOGFILE GROUP` 语句	错误	`LOGFILE GROUP` 是 NDB Cluster 存储引擎的特定功能，普通 MySQL 备份不涉及此语句。`--no-create-info` 对其无影响。
C. 不写入 `CREATE DATABASE` 语句	错误	`--all-databases` 默认会包含 `CREATE DATABASE` 语句，而 `--no-create-info` 仅抑制表结构生成，不影响数据库创建语句。
D. 不写入 `CREATE TABLE` 语句	正确	`--no-create-info` 的核心功能是禁止生成 `CREATE TABLE` 语句，符合题目描述。

技术扩展

mysqldump 常用参数对比

参数	作用	示例场景
`--no-create-info`	仅导出数据，不生成表结构	快速恢复数据到已有结构的表中
`--no-data`	仅导出表结构，不导出数据	仅需重建表结构时使用
`--compact`	精简输出（删除注释等）	减少备份文件体积
`--single-transaction`	通过事务保证一致性	InnoDB 表的一致性备份

备份策略建议
- 全量备份：使用 --all-databases + --routines + --events 导出完整数据库对象。
- 增量备份：结合二进制日志（mysqlbinlog）实现。
- 压缩备份：通过管道将 mysqldump 输出传递给 gzip，例如：
```
mysqldump --all-databases | gzip > backup.sql.gz  
```

总结

在命令 mysqldump --no-create-info --all-databases --result-file=dump.sql 中，选项 D 正确，因为 --no-create-info 明确禁止生成 CREATE TABLE 语句。其他选项因参数作用范围或功能无关性被排除。实际备份时，需根据需求选择参数组合以平衡完整性与效率。

题目 164

MySQL programs look for option files in standard locations.

Which method will show the option files and the order in which they are read?

A. shell> mysqladmin --debug

B. shell> mysql --print-defaults

C. shell> mysqld --help --verbose

D. mysql> SHOW GLOBAL VARIABLES;

最佳答案

C. shell> mysqld --help --verbose

关键解析

1. 选项 C 的正确性

执行 mysqld --help --verbose 命令会明确显示 MySQL 服务器启动时读取的选项文件路径及其顺序。该命令的输出中会包含以下关键信息：

默认选项文件的读取顺序：例如 /etc/my.cnf → /etc/mysql/my.cnf → /usr/local/mysql/etc/my.cnf → ~/.my.cnf 等。
读取的选项组：如 [mysqld]、[server] 等配置段的加载优先级。

此方法直接展示了MySQL服务端（mysqld）在启动时如何搜寻并加载配置文件，符合题目要求的“显示选项文件及其顺序”的核心需求。

其他选项排除原因

选项	排除原因
A	`mysqladmin --debug` 用于生成调试日志（如锁、内存状态），与配置文件读取顺序无关。
B	`mysql --print-defaults` 仅输出最终生效的配置参数（如用户、端口等），不会显示配置文件的具体加载路径和顺序。
D	`SHOW GLOBAL VARIABLES` 展示的是当前系统变量的值（如 `datadir`、`port`），与配置文件读取机制无关。

技术扩展

MySQL配置文件读取逻辑
- 标准配置文件路径：MySQL程序按以下顺序读取配置文件：
```
/etc/my.cnf → /etc/mysql/my.cnf → SYSCONFDIR/my.cnf → $MYSQL_HOME/my.cnf → ~/.my.cnf  
```
  其中 SYSCONFDIR 是编译时指定的路径（如 /usr/local/mysql/etc）
- 优先级规则：后读取的文件会覆盖前序文件的同名配置项。
其他相关命令
- my_print_defaults：可查看指定选项组的配置参数（如 [client]、[mysqld]），但需手动指定组名。
- mysql --verbose --help：客户端工具（如 mysql）的配置文件读取顺序与 mysqld 略有不同，需注意区分。

总结

在MySQL中，mysqld --help --verbose 是唯一直接显示选项文件加载顺序的命令，而其他选项仅涉及参数值或调试信息。实际运维中，此命令常用于排查配置冲突或验证配置优先级。

题目 165

Choose the best answer.

Examine this command, which executes successfully:

$ mysqlbackup --user=dba --password --port=3306 --with-timestamp \
--only-known-file-types --backup-dir=/export/backups backup

Which statement is true?

A. Only tables stored in their own tablespaces are backed up.

B. Only InnoDB data and log files are backed up.

C. Only non-encrypted files are backed up.

D. Only files for MySQL or its built-in storage engines are backed up.

E. The backup includes only data files and their metadata.

最佳答案

D. Only files for MySQL or its built-in storage engines are backed up.

关键解析

关键参数作用

--only-known-file-types：此参数的核心作用是仅备份 MySQL 或其内置存储引擎（如 InnoDB、MyISAM、CSV、ARCHIVE 等）关联的已知文件类型，过滤掉非 MySQL 引擎或未知文件。例如：
- 支持的文件类型：
  - InnoDB 表空间文件（.ibd、ibdata*）
  - MyISAM 数据文件（.MYD）、索引文件（.MYI）
  - CSV 表文件（.CSV、.CSM）
  - ARCHIVE 表文件（.ARZ、.ARM）
  - Redo 日志文件（ib_logfile*）。
- 过滤范围：
  - 用户自定义文件（如临时文件、第三方工具生成的文件）会被排除。
其他参数解析
- --with-timestamp：自动在备份目录中创建时间戳子目录，避免覆盖历史备份。
- --backup-dir：指定备份文件的存储路径。

选项分析

选项	正确性	原因
A. 仅备份独立表空间的表	错误	`--only-known-file-types` 不限制表空间的存储方式（如共享表空间或独立表空间），而是限制文件类型。
B. 仅备份 InnoDB 数据和日志文件	错误	MEB（MySQL Enterprise Backup）默认会备份所有 MySQL 引擎的文件（包括非 InnoDB，如 MyISAM），而非仅 InnoDB。
C. 仅备份非加密文件	错误	是否加密由备份工具的其他参数（如 `--encrypt`）决定，与 `--only-known-file-types` 无关。
D. 仅备份 MySQL 或其内置引擎的文件	正确	符合 `--only-known-file-types` 的设计目标，即过滤非 MySQL 引擎或未知文件。
E. 仅包含数据文件及其元数据	错误	物理备份包含数据文件、日志文件（如 Redo Log）及元数据（如 `.frm` 文件），选项描述不完整。

技术扩展

MySQL Enterprise Backup（MEB）特性
- 物理备份：直接复制数据库文件，速度快，适合大型数据库。
- 热备份与温备份：
  - InnoDB 支持在线热备份（不阻塞 DML 操作）；
  - 非 InnoDB 表（如 MyISAM）执行温备份（备份期间表不可修改）。
- 增量备份：通过 --incremental 参数减少备份数据量。
与逻辑备份的对比
- 优势：
  - 备份速度快（直接复制文件）；
  - 支持压缩、加密及云存储集成。
- 局限性：
  - 无法部分备份逻辑对象（如存储过程）。

总结

在命令 mysqlbackup --user=dba --password --port=3306 --with-timestamp --only-known-file-types --backup-dir=/export/backups backup 中，选项 D 正确。--only-known-file-types 确保仅备份 MySQL 或其内置存储引擎的文件，其他选项因参数作用范围或功能无关性被排除。实际运维中，建议结合业务需求选择备份策略，并定期验证备份文件可用性。

题目 166

Choose the best answer.

Which statement is true about the my.ini file on a Windows platform while MySQL server is running?

A. MySQL server does not use the my.ini option file for server configuration options.

B. The option file is read by the MySQL server service only at start up.

C. Editing the file will immediately change the running server configuration.

D. Using SET PERSIST will update the my.ini file.

最佳答案

B. The option file is read by the MySQL server service only at start up.

关键解析

关键结论

在 Windows 平台上，MySQL 服务启动时才会读取 my.ini 文件中的配置参数，运行时修改该文件不会立即生效，必须重启服务才能加载新配置。

选项分析

选项	正确性	原因
A. MySQL 服务器不使用 `my.ini` 文件配置参数	错误	`my.ini` 是 MySQL 在 Windows 上的核心配置文件，用于设置端口、字符集、存储引擎、内存参数等关键配置。
B. 服务器仅在启动时读取 `my.ini` 文件	正确	MySQL 服务启动时加载 `my.ini` 中的配置，运行期间修改文件内容不会直接影响当前服务状态。例如，修改 `innodb_buffer_pool_size` 后需重启服务才能生效。
C. 编辑文件会立即改变运行中的配置	错误	直接修改 `my.ini` 文件不会实时更新服务配置，必须重启服务或重新加载动态参数（需参数支持动态调整）。例如，`max_connections` 需重启服务。
D. `SET PERSIST` 会更新 `my.ini` 文件	错误	`SET PERSIST` 会将动态修改的配置保存到 `mysqld-auto.cnf`（位于数据目录），而非直接修改 `my.ini`。

技术扩展

配置文件加载机制
- 启动阶段：MySQL 服务启动时按以下顺序搜索并加载配置文件：
```
%PROGRAMDATA%\MySQL\<MySQL Server Version>\my.ini  
%WINDIR%\my.ini  
C:\my.ini  
```
  若未找到，则使用默认参数启动。
- 动态参数：部分参数（如 wait_timeout）支持通过 SET GLOBAL 实时调整，但不会写入 my.ini。
运维建议
- 修改配置流程：
  - 编辑 my.ini 文件（如调整 innodb_buffer_pool_size）。
  - 重启 MySQL 服务：
```
net stop mysql  
net start mysql  
```
- 验证配置生效：
```
SHOW VARIABLES LIKE 'innodb_buffer_pool_size';  
```

总结

选项 B 正确，因为 MySQL 服务仅在启动时读取 my.ini 文件，运行时修改需重启才能生效。其他选项因逻辑错误或与 MySQL 配置机制不符被排除。实际运维中，建议通过 SHOW VARIABLES 验证参数状态，并结合 SET PERSIST 管理动态配置。

题目 167

Examine the full path name of the backup image from MySQL Enterprise Backup with the --compress option: /backup/full/mybackup/myimage.img

Mysqlbackup.cnf contains this data:

[mysqlbackup]
Backup-dir=/backup/full/myrestore
Backup-image=/backup/full/mybackup/myimage.img uncompress

You must perform a database restore to a new machine.

Which command can provision the new database in datadir as /data/MEB?

A. mysqlbackup --defaults-file=mysqlbackup.cnf --datadir=/data/MEB restore-and-apply-log

B. mysqlbackup --defaults-file=mysqlbackup.cnf --datadir=/data/MEB image-to-dir-and-apply-log

C. mysqlbackup --defaults-file=mysqlbackup.cnf --datadir=/data/MEB apply-log-and-copy-back

D. mysqlbackup --defaults-file=mysqlbackup.cnf --datadir=/data/MEB copy-back-and-apply-log

E. mysqlbackup --defaults-file=mysqlbackup.cnf --datadir=/data/MEB image-to-dir

最佳答案

D. mysqlbackup --defaults-file=mysqlbackup.cnf --datadir=/data/MEB copy-back-and-apply-log

关键解析

核心逻辑分析

备份类型与恢复流程：题目中的备份镜像 /backup/full/mybackup/myimage.img 是使用 --compress 生成的压缩的单一文件备份。恢复此类备份需完成以下步骤：
- 解压备份镜像：配置文件 mysqlbackup.cnf 中已通过 uncompress 参数声明需要解压。
- 应用 Redo 日志：确保数据一致性（将备份期间未提交的事务回滚或已提交的事务应用）。
- 复制到目标目录：将解压后的数据文件复制到新机器的 datadir（即 /data/MEB）。
关键参数与命令功能
- copy-back-and-apply-log：该命令是 MEB 恢复压缩备份的标准操作，合并以下功能：
  - 自动解压备份镜像（依赖配置中的 uncompress 参数）。
  - 应用事务日志（apply-log）保证数据一致性。
  - 将数据文件复制到 datadir（copy-back）。
- --datadir=/data/MEB：明确指定恢复的目标路径。

选项排除原因

选项	排除原因
A	`restore-and-apply-log` 不是 MEB 的有效命令，恢复流程需结合解压和应用日志操作。
B	`image-to-dir-and-apply-log` 需先将镜像转为目录再操作，但配置文件已通过 `uncompress` 声明解压，直接使用 `copy-back-and-apply-log` 更高效。
C	`apply-log-and-copy-back` 命令顺序错误，MEB 标准命令为 `copy-back-and-apply-log`。
E	`image-to-dir` 仅将镜像转为目录，未完成应用日志和复制到 `datadir` 的步骤，恢复不完整。

技术验证与示例

恢复命令执行流程

mysqlbackup \  
  --defaults-file=mysqlbackup.cnf \  # 加载配置（含解压指令）  
  --datadir=/data/MEB \              # 目标数据目录  
  copy-back-and-apply-log            # 解压+应用日志+复制文件

输出结果：
- 自动解压镜像到临时目录（/backup/full/myrestore）。
- 应用 Redo 日志确保数据一致性。
- 将文件复制到 /data/MEB，完成恢复。

配置文件作用
- Backup-image：指定压缩的备份镜像路径。
- uncompress：声明恢复时需解压镜像。
- Backup-dir：作为解压临时目录，无需手动创建。

总结

在 MEB 中，copy-back-and-apply-log 是恢复压缩备份镜像的最优解，其集成解压、日志应用和数据复制功能，且与配置文件中的 uncompress 参数完美配合。其他选项因流程不完整或命令无效被排除。实际运维中需注意目标目录权限（如 chown -R mysql:mysql /data/MEB）。

题目 168

Choose the best answer.

MySQL Enterprise Monitor Query Analyzer is configured to monitor an instance.

Which statement is true?

A. The Query Response Time index (QRTi) is fixed to 100ms and cannot be customized.

B. Enabling the events_statements_history_long consumer allows tracking the longest running query.

C. An agent must be installed locally on the instance to use the Query Analyzer.

D. The Query Analyzer can monitor an unlimited number of normalized statements.

E. The slow query log must be enabled on the monitored server to collect information for the Query Analyzer.

最佳答案

B. Enabling the events_statements_history_long consumer allows tracking the longest running query.

关键解析

选项分析

选项	正确性	原因
A. QRTi 阈值固定为 100ms 且不可自定义	错误	QRTi 的默认最佳时间为 100ms，但用户可通过配置文件调整阈值范围（例如将最佳时间设置为 200ms），从而改变 QRTi 的计算逻辑。
B. 启用 `events_statements_history_long` 可追踪最长运行查询	正确	`events_statements_history_long` 是 Performance Schema 的表，用于记录大量历史查询的详细信息（如执行时间、资源消耗等）。启用该功能后，Query Analyzer 可基于此数据识别耗时最长的查询。
C. 必须在实例本地安装代理才能使用 Query Analyzer	错误	Query Analyzer 支持两种代理模式：本地安装的代理和云代理（Agent Proxy）。后者无需在目标实例本地安装代理即可通过远程连接收集数据。
D. Query Analyzer 可监控无限数量的标准化语句	错误	Query Analyzer 的监控能力受限于代理内存和服务管理器资源。高并发场景下，需通过采样或过滤策略限制监控的查询数量，否则可能导致内存溢出。
E. 必须启用慢查询日志才能收集信息	错误	Query Analyzer 的数据源是 Performance Schema（如 `events_statements_*` 表），而非慢查询日志。即使未启用慢查询日志，仍可通过 Performance Schema 获取查询性能数据。

技术扩展

QRTi 的灵活性：QRTi 的默认时间阈值（如最佳 100ms、可接受 400ms）可通过配置文件自定义。例如，将最佳响应时间调整为 200ms 后，QRTi 的分配值会重新计算，适应不同业务场景的 SLA 需求。
events_statements_history_long 的作用：该表记录 MySQL 服务器执行的所有 SQL 语句的详细信息，包括执行时间（TIMER_WAIT）、扫描行数（ROWS_EXAMINED）等。Query Analyzer 结合此数据与 QRTi 指标，可快速定位执行时间超过阈值的慢查询。
代理部署的灵活性：MySQL Enterprise Monitor 支持混合部署模式：
- 本地代理：适用于需要收集主机硬件信息的场景（如 CPU、内存使用率）。
- 云代理（Agent Proxy）：适用于云环境或无代理部署的场景，通过远程连接收集数据库性能数据。
性能监控的优化建议
- 高负载场景：启用 events_statements_history_long 时，需合理配置其存储容量（通过 performance_schema_events_statements_history_long_size 参数），避免内存占用过高。
- 查询过滤：使用 Query Analyzer 的过滤功能（如按用户、数据库、执行时间筛选），聚焦关键查询。

总结

选项 B 正确，因为 events_statements_history_long 是追踪长耗时查询的核心数据源。其他选项因逻辑错误或与 MySQL Enterprise Monitor 的实际机制不符被排除。实际运维中，建议结合 QRTi 分析与 Performance Schema 的详细数据，全面优化查询性能。

题目 169

Choose the best answer.

Users report errors when trying to connect from 192.0.2.5 and is connecting using the mysql_native password authentication plugin.

Examine these commands and output:

mysql> SHOW GLOBAL STATUS LIKE '%conn%';
+-----------------------------------+-------+
| Variable_name                     | Value |
+-----------------------------------+-------+
| Aborted_connects                  | 593   |
| Connection_errors_accept          | 0     |
| Connection_errors_internal        | 0     |
| Connection_errors_max_connections | 0     |
| Connection_errors_peer_address    | 0     |
| Connection_errors_select          | 0     |
| Connection_errors_tcpwrap         | 0     |
| Locked_connects                   | 0     |
| Connections                       | 1825  |
| Max_used_connections              | 100   |
| Threads_connected                 | 4     |
+-----------------------------------+-------+
23 rows in set (0.00 sec)

mysql> SELECT * FROM performance_schema.host_cache WHERE IP='192.0.2.5'\G
*************************** 1. row ***************************
IP: 192.0.2.5
HOST: client05.example.com
HOST_VALIDATED: YES
SUM_CONNECT_ERRORS: 0
COUNT_HOST_BLOCKED: 0
COUNT_NAMEINFO_TRANSIENT_ERRORS: 0
COUNT_NAMEINFO_PERMANENT_ERRORS: 0
COUNT_FORMAT_ERRORS: 0
COUNT_ADDRINFO_TRANSIENT_ERRORS: 0
COUNT_ADDRINFO_PERMANENT_ERRORS: 0
COUNT_FCNDS_ERRORS: 0
COUNT_HOST_ACL_ERRORS: 0
COUNT_NO_AUTH_PLUGIN_ERRORS: 0
COUNT_AUTH_PLUGIN_ERRORS: 367
COUNT_HANDSHAKE_ERRORS: 0
COUNT_PROXY_USER_ERRORS: 0
COUNT_SSL_ERRORS: 0
COUNT_AUTHENTICATION_ERRORS: 0
1 row in set (0.00 sec)

Which statement identifies the cause of the errors?

A. max_connections is too small.

B. Network connectivity issues occurring between client and the MySQL instance.

C. Connections are attempted without a valid user account or password.

D. User accounts are defined using the mysql_native_pasword plugin for password authentication.

E. thread_cache is too small.

F. skip_name_resolve is enabled.

正确答案

D. User accounts are defined using the mysql_native_password plugin for password authentication.

关键解析

关键指标分析

从提供的命令输出中，以下数据揭示了问题的核心原因：

performance_schema.host_cache 表信息：
- COUNT_AUTH_PLUGIN_ERRORS = 367：表示因身份验证插件不兼容或未加载导致的错误次数。
- HOST_VALIDATED = YES：说明客户端 IP 已通过反向 DNS 解析，排除了 DNS 解析问题（与 skip_name_resolve 无关）。
- 其他错误计数为 0（如 COUNT_SSL_ERRORS、COUNT_AUTHENTICATION_ERRORS），排除密码错误或 SSL 问题。
SHOW GLOBAL STATUS 信息：
- Aborted_connects = 593：大量连接尝试因身份验证失败被中断。
- Max_used_connections = 100：当前最大连接数未达上限，排除 max_connections 过小问题。

选项排除与验证

选项	排除原因	依据
A. `max_connections` 过小	错误	`Max_used_connections = 100` 未达到服务器连接上限，无 `Connection_errors_max_connections` 错误计数。
B. 网络连接问题	错误	`COUNT_ADDRINFO_*_ERRORS = 0`，且 `HOST_VALIDATED = YES`，表明网络层无异常。
C. 无效用户或密码	错误	`COUNT_AUTHENTICATION_ERRORS = 0`，说明密码本身正确，但插件配置不匹配导致验证失败。
D. 用户使用 `mysql_native_password` 插件	正确	MySQL 8.0+ 默认使用 `caching_sha2_password`，若用户账户仍配置为 `mysql_native_password` 且服务器未加载该插件，会触发 `COUNT_AUTH_PLUGIN_ERRORS` 计数。
E. `thread_cache` 过小	错误	无相关状态变量（如 `Threads_cached`）显示线程缓存问题。
F. `skip_name_resolve` 启用	错误	`HOST_VALIDATED = YES` 表明反向 DNS 解析已成功，`skip_name_resolve` 未启用。

技术扩展

MySQL 8.0+ 的插件兼容性问题
- 默认插件变更：MySQL 8.0 开始默认启用 caching_sha2_password，而 mysql_native_password 在 8.4 版本中已弃用且默认未加载。
- 错误触发条件：若用户账户通过 ALTER USER 或 CREATE USER 指定使用 mysql_native_password，但服务器未加载该插件，客户端连接时会直接报错 Plugin 'mysql_native_password' is not loaded。

解决方案

方法 1：更新用户认证插件为 caching_sha2_password ：

ALTER USER 'username'@'192.0.2.5' IDENTIFIED WITH caching_sha2_password BY 'new_password';

方法 2（不推荐）：在 MySQL 配置文件中强制启用 mysql_native_password ：
```
[mysqld]  
default_authentication_plugin=mysql_native_password  
```
并重启服务。

验证方法：

SELECT user, host, authentication_string, plugin 
FROM mysql.user 
WHERE host = '192.0.2.5';

总结

问题根源在于用户账户配置了已弃用的 mysql_native_password 插件，而 MySQL 服务器未加载该插件，导致客户端连接时触发身份验证插件错误（COUNT_AUTH_PLUGIN_ERRORS）。其他选项因状态变量或配置不匹配被排除。实际运维中，建议统一使用 caching_sha2_password 以兼容新版 MySQL 的安全特性。

题目 170

You want to check the values of the sort_buffer_size session variables of all existing connections.

Which performance_schema table can you query?

A. user_variables_by_thread

B. global_variables

C. variables_by_thread

D. session_variables

正确答案

C. variables_by_thread

关键解析

要查询所有现有连接的 sort_buffer_size 会话变量值，需使用 Performance Schema 中专门记录会话级系统变量的表：

variables_by_thread 表：
- 该表按线程 ID（THREAD_ID）存储每个活跃会话的会话级系统变量（如 sort_buffer_size）。
- 字段包括：THREAD_ID（会话对应的线程 ID）、VARIABLE_NAME（变量名）、VARIABLE_VALUE（变量值）。
- 例如，通过以下 SQL 可查询所有会话的 sort_buffer_size 值：
```
SELECT * FROM performance_schema.variables_by_thread  
WHERE VARIABLE_NAME = 'sort_buffer_size';  
```
其他选项排除原因：
- A. user_variables_by_thread：记录用户自定义变量（如 @var），而非系统变量。
- B. global_variables：仅存储全局系统变量值，无法区分不同会话的变量值。
- D. session_variables：仅记录当前会话的变量值（包含全局变量），而非所有活跃会话的变量值。

技术扩展

动态监控场景：通过 variables_by_thread 表，管理员可实时分析不同会话的资源配置（如 sort_buffer_size 是否合理），进而优化并发性能。
权限要求：查询 Performance Schema 表需具备 SELECT 权限。若需终止异常会话，可结合 THREAD_ID 与 performance_schema.threads 表关联，获取 PROCESSLIST_ID 后执行 KILL 操作。

总结

通过 variables_by_thread 表可高效获取所有活跃会话的 sort_buffer_size 及其他会话级系统变量值。其他选项因功能范围限制（仅全局或当前会话）被排除。

题目 171

Choose the best answer.

Which feature is provided by multi-source replication?

A. providing a common source for the same data to be replicated to other servers

B. allowing multiple servers to back up to one server

C. managing conflicts between two sets of the same data

D. providing multi-source replication where all servers act as the master

正确答案

B. allowing multiple servers to back up to one server

关键解析

多源复制（Multi-Source Replication）的核心功能是允许一个从库（Replica）同时从多个主库（Master）接收并复制数据。以下为关键分析：

选项 B 的正确性：
- 根据 MySQL 官方文档，多源复制的典型应用场景包括将多个主库的数据备份到一个从库。例如，通过配置多个独立通道，从库可以接收来自不同主库的数据副本，从而简化备份和数据分析流程。
- 多源复制用于数据聚合、备份和整合，例如将分散在多个主库的数据集中到一个从库进行统一管理。
其他选项排除原因：
- A. 为其他服务器提供统一数据源：多源复制的从库本身不充当数据源供其他服务器复制，而是作为数据接收端。此功能更适用于单源复制的主库角色。
- C. 管理数据冲突：多源复制不提供冲突检测或解决机制，用户需自行确保不同主库的数据无冲突（如通过分库分表策略）。
- D. 所有服务器均为主库：多源复制的拓扑结构是“多主一从”，而非所有服务器均为主库（即多主复制）。每个主库独立向从库发送数据，从库不承担主库角色。

技术扩展

多源复制的典型应用：
- 数据备份：将多个主库的备份集中到一个从库，减少硬件和维护成本。
- 数据聚合：合并来自不同业务系统的数据（如分库分表场景），用于生成统一报表或数据仓库分析。
- 高可用性：当某个主库故障时，从库仍可从其他主库接收数据，保障业务连续性。
实现限制：
- 冲突风险：若多个主库操作相同数据，需由应用层设计避免冲突（如分片键隔离）。
- 配置复杂度：需为每个主库单独配置复制通道，并确保主库的 server-id 唯一。

总结

多源复制的核心功能是允许一个从库从多个主库同步数据，适用于备份、数据聚合等场景。选项 B 正确，因其直接对应多源复制的核心设计目标。其他选项因功能定义不匹配被排除。实际部署时需结合业务需求设计数据隔离策略以避免冲突。

题目 172

Choose the best answer.

t is a non-empty InnoDB table.

Examine these statements, which are executed in one session:

BEGIN
SELECT * FROM t FOR UPDATE;

Which is true?

A. mysqlcheck --analyze --all-databases will execute normally on all tables and return a report.

B. If ANALYZE TABLE; is invoked from the same session, it hangs until the transaction is committed or rolled back.

C. If OPTIMIZE LOCAL TABLE t; is invoked from another session, it executes normally and returns the status.

D. If OPTIMIZE TABLE; is invoked, it will create a table lock on t and force a transaction rollback.

正确答案

B. If ANALYZE TABLE is invoked from the same session, it hangs until the transaction is committed or rolled back.

关键解析

SELECT ... FOR UPDATE 的锁机制
- SELECT ... FOR UPDATE 会对查询结果集的行加排他锁（X 锁），阻止其他事务修改或加锁这些行（但允许非锁定读，取决于隔离级别）。
- 在事务未提交（COMMIT/ROLLBACK）前，锁会持续持有。
ANALYZE TABLE 的锁需求
- ANALYZE TABLE 是用于更新表的统计信息（如索引基数），在 InnoDB 中需要获取表的只读锁（共享锁）。
- 若同一会话中已有未提交事务持有表的排他锁（X 锁），则后续操作需要等待锁释放。由于共享锁（S 锁）与排他锁（X 锁）互斥，ANALYZE TABLE 会被阻塞，直到事务提交或回滚。

选项验证

选项	正确性	原因
A. `mysqlcheck --analyze` 正常执行	错误	`mysqlcheck --analyze` 会调用 `ANALYZE TABLE`，需获取共享锁。若表 `t` 被当前事务的排他锁占用，该操作会被阻塞，无法立即完成。
B. 同一会话调用 `ANALYZE TABLE` 会挂起	正确	同一会话内，未提交事务持有排他锁，导致后续 `ANALYZE TABLE` 因锁冲突挂起，直至事务结束。
C. 其他会话 `OPTIMIZE TABLE` 正常执行	错误	`OPTIMIZE TABLE` 本质是重建表，需获取表的排他锁。因当前事务未释放锁，其他会话的 `OPTIMIZE` 会阻塞，无法立即返回状态。
D. `OPTIMIZE TABLE` 强制回滚事务	错误	`OPTIMIZE TABLE` 会等待锁释放，不会强制回滚事务。若锁等待超时（由 `innodb_lock_wait_timeout` 控制），可能触发错误而非回滚。

技术扩展

InnoDB 锁的兼容性
- 排他锁（X 锁）：禁止其他事务获取任何类型的锁（包括共享锁和排他锁）。
- 共享锁（S 锁）：允许其他事务获取共享锁，但禁止排他锁。
- 因此，在 SELECT ... FOR UPDATE 持有排他锁期间，任何需要共享锁的操作（如 ANALYZE TABLE）均会被阻塞。
事务与维护命令的交互
- 同一会话内：未提交事务持有的锁会直接影响后续命令的锁请求，导致阻塞。
- 跨会话：其他会话的锁请求会进入等待队列，若超时则返回错误（如 ERROR 1205: Lock wait timeout）。

总结

选项 B 正确，因为在同一会话中，未提交事务的排他锁会阻塞后续 ANALYZE TABLE 的共享锁请求，导致其挂起直至事务结束。其他选项因锁机制不兼容或操作特性被排除。实际运维中需注意事务及时提交/回滚，避免长时间锁冲突影响系统性能。

题目 173

Choose the best answer.

You have upgraded the MySQL binaries from 5.7.28 to 8.0.18 by using an in-place upgrade. Examine the message sequence generated during the first start of MySQL 8.0.18:

... [System] ... /usr/sbin/mysqld (mysqld 8.0.18-commercial) starting as process 2754
... [System] ... Starting upgrade of data directory.
... [ERROR] ... Table upgrade required. Please do "REPAIR TABLE 'columns_priv'" or dump/reload to fix it!
... [ERROR] ... Table upgrade required. Please do "REPAIR TABLE 'event'" or dump/reload to fix it!
... [ERROR] ... Table upgrade required. Please do "REPAIR TABLE 'proc'" or dump/reload to fix it!
... [ERROR] ... Table upgrade required. Please do "REPAIR TABLE 'proxies_priv'" or dump/reload to fix it!
... [ERROR] ... Table upgrade required. Please do "REPAIR TABLE 'tables_priv'" or dump/reload to fix it!
... [ERROR] ... Failed to open mysql.event Table.
... [ERROR] ... Failed to Populate DD tables.
... [ERROR] ... Aborting
... [System] ... /usr/sbin/mysqld: Shutdown complete (mysqld 8.0.18-commercial) MySQL Enterprise Server - Commercial

Which step or set of steps will resolve the errors?

A. Remove the redo logs. Replace the MySQL binaries with the 5.7.28 binaries. Prepare the tables for upgrade. Upgrade to 8.0.18 again.

B. Execute: mysqlcheck --check-upgrade mysql columns_priv event proc proxies_priv tables_priv.

C. Start mysqld again using the --upgrade=FORCE option.

D. Execute: mysqlcheck --repair mysql columns_priv event proc proxies_priv tables_priv.

E. Go to the <datadir>/mysql directory and execute: myisamchk --update-state columns_priv event proc proxies_priv tables_priv.

正确答案

C. Start mysqld again using the --upgrade=FORCE option.

关键解析

在从 MySQL 5.7.28 就地升级到 8.0.18 时，启动新版本服务后出现以下关键错误：

多个系统表（如 columns_priv、event、proc 等）需要升级（Table upgrade required）。
数据字典表（DD tables）初始化失败，导致服务中止（Failed to Populate DD tables）。

这些错误表明升级过程中系统表结构未成功更新，无法兼容新版本的元数据要求。以下是各选项的排除与验证逻辑：

选项逐项验证

选项	正确性	原因与引用
A. 回退到 5.7.28 重新升级	错误	回退旧版本并非必要。错误根源是系统表未升级，而非升级流程本身失败。
B. `mysqlcheck --check-upgrade`	错误	`--check-upgrade` 仅检查兼容性问题，不会修复表结构。
C. `--upgrade=FORCE`	正确	从 MySQL 8.0.16 开始，服务器自动处理升级任务。`--upgrade=FORCE` 强制升级所有系统表和用户表，修复元数据兼容性问题。
D. `mysqlcheck --repair`	错误	`--repair` 适用于修复数据文件损坏，而非系统表结构升级。
E. `myisamchk`	错误	MySQL 8.0 的系统表（如 `mysql` 库下的表）已默认使用 InnoDB 引擎，`myisamchk` 工具不适用。

技术扩展

--upgrade=FORCE 的作用
- 强制重建系统表：当系统表缺失或结构不兼容时，此选项会重新创建 mysql 库下的核心表（如 user、proc 等），并更新数据字典。
- 全面检查用户表：对所有用户表执行兼容性检查和修复，确保其符合 8.0 的元数据规范。
错误场景的根源
- 就地升级的限制：直接替换二进制文件可能导致旧版本系统表未被自动升级（尤其从 5.7 跳版本升级到 8.0）。
- 数据字典不兼容：MySQL 8.0 引入了新的数据字典（存储在 mysql.ibd 中），若升级时未正确初始化，会导致服务启动失败。
最佳实践建议
- 升级前检查：使用 mysql-shell 的 util.checkForServerUpgrade() 检查兼容性问题（如字符集、存储引擎、废弃参数等）。
- 备份与隔离操作：升级前备份数据目录（/var/lib/mysql）和配置文件（my.cnf），避免因升级失败导致数据丢失。

总结

选项 C 是唯一能解决系统表升级失败的方法。通过 --upgrade=FORCE 强制触发全面的元数据更新，确保数据字典与用户表结构符合 MySQL 8.0 的要求。其他选项因功能范围限制或技术不适用被排除。实际运维中，建议结合预检查工具和逻辑升级（如 mysqldump）降低风险。

题目 174

Choose the best answer.

Which statement is true about MySQL Enterprise Transparent Data Encryption (TDE)?

A. MySQL TDE uses an appropriate keyring plugin to store the keys in a centralized location.

B. TDE can encrypt InnoDB and MyISAM tables only when the tables are stored in the SYSTEM tablespace.

C. Lost tablespace encryption keys can be regenerated only if the master database key is known or present in the Key Vault specification.

D. Both MyISAM and InnoDB tables can be encrypted by setting the keyring_engine = All variable in the MySQL configuration file.

正确答案

A. MySQL TDE uses an appropriate keyring plugin to store the keys in a centralized location.

关键解析

选项 A
- 正确性：正确。
- 依据：MySQL 企业版 TDE 依赖 keyring 插件（如 keyring_file、keyring_encrypted_file 或第三方集成的 KMS）管理密钥。密钥（包括主密钥和表空间密钥）通过插件存储在集中位置（如文件或密钥保管库），确保密钥的安全性和可管理性。例如，企业版支持通过 keyring_okv 插件与外部 KMS 集成，实现密钥的集中存储和轮换。
选项 B
- 正确性：错误。
- 依据：
  - TDE 不支持加密 MyISAM 表，仅支持 InnoDB 表空间（包括独立表空间、通用表空间、系统表空间等）。
  - MyISAM 存储引擎不支持事务和 TDE 加密，且 MySQL 8.0 已默认禁用 MyISAM。
选项 C
- 正确性：错误。
- 依据：
  - TDE 使用双层密钥架构：主密钥加密表空间密钥，表空间密钥存储在表空间文件头中。
  - 若表空间密钥丢失（如文件头损坏），即使主密钥存在，也无法重新生成原表空间密钥，导致数据永久丢失。主密钥仅用于解密已有的表空间密钥，而非重新生成。
选项 D
- 正确性：错误。
- 依据：
  - MyISAM 不支持 TDE 加密，仅 InnoDB 表可通过 ENCRYPTION='Y' 启用加密。
  - MySQL 配置中无 keyring_engine=All 参数，正确配置需通过 early-plugin-load 加载 keyring 插件。

技术扩展

TDE 的密钥管理：
- 主密钥（Master Key）：由 keyring 插件管理，用于加密表空间密钥，需定期轮换以提高安全性。
- 表空间密钥（Tablespace Key）：随机生成并加密后存储在表空间头中，解密依赖主密钥。
企业版优势：
- 支持更多 keyring 插件（如 keyring_okv、keyring_hashicorp），可集成第三方 KMS 实现密钥的集中管理和合规审计。
- 支持加密范围更广（如 Redo/Undo Log、DoubleWrite 文件）。
数据恢复限制：
- 备份要求：使用 MySQL Enterprise Backup (MEB) 加密备份时需同时备份密钥，否则无法恢复数据。
- 密钥丢失风险：若主密钥丢失，所有依赖其加密的表空间密钥无法解密，导致数据永久不可用。

总结

选项 A 正确，因其准确描述了 MySQL 企业版 TDE 的密钥管理机制。其他选项因技术细节错误（如 MyISAM 支持、密钥恢复逻辑）被排除。实际部署 TDE 时需重点关注密钥管理和备份策略，确保符合合规要求。

题目 175

You are using the InnoDB engine and the innodb_file_per_table option is set. You delete a significant number of rows of a large table named FACTORY.INVENTORY.

Which command will reorganize the physical storage of table data and associated index data for the INVENTORY table, in order to reduce storage space and improve I/O efficiency?

A. CHECK TABLE FACTORY

B. ANALYZE TABLE FACTORY

C. OPTIMIZE TABLE FACTORY

D. mysqlcheck -u root -p FACTORY

E. mysqldump -u root -p FACTORY INVENTORY

正确答案

C. OPTIMIZE TABLE FACTORY

关键解析

在启用 innodb_file_per_table 的情况下，InnoDB 表（如 FACTORY.INVENTORY）的物理存储文件是独立的 .ibd 文件。删除大量数据后，虽然空间会被标记为可复用，但不会自动释放给操作系统，导致存储空间未被回收且可能产生碎片。此时需通过特定操作重组物理存储以释放空间并优化 I/O 效率。

选项逐项验证

选项	正确性	原因与引用
A. `CHECK TABLE`	错误	仅检查表的完整性（如索引损坏），不涉及空间回收或物理存储重组。
B. `ANALYZE TABLE`	错误	仅更新表的统计信息（如索引基数），不会修改物理存储结构或释放空间。
C. `OPTIMIZE TABLE`	正确	触发表重建：通过创建临时表并重新组织数据页和索引，释放未使用的空间，减少碎片。对于 InnoDB 表，其效果等效于 `ALTER TABLE ... FORCE`，并支持在线 DDL（减少锁表时间）。
D. `mysqlcheck`	错误	`mysqlcheck` 默认仅检查或修复表结构，需配合 `-o`（优化）或 `-r`（修复）参数。但即使使用 `mysqlcheck -o`，底层仍调用 `OPTIMIZE TABLE`，且该工具更适用于 MyISAM 引擎，对 InnoDB 支持有限。
E. `mysqldump`	错误	导出数据并重新导入的逻辑备份方式虽可回收空间，但需手动操作且非直接优化命令，效率低于 `OPTIMIZE TABLE`。

技术扩展

OPTIMIZE TABLE 的执行机制：
- 物理重建：生成临时表并逐行复制数据，丢弃已删除记录和碎片，生成紧凑的 .ibd 文件。
- 在线 DDL：在 MySQL 5.6+ 中，InnoDB 支持在线重建，仅短暂锁表（准备和提交阶段），对业务影响较小。
- 空间释放：启用 innodb_file_per_table 后，重建后的表空间大小会显著减小。
适用场景与限制：
- 大表删除后：适合删除大量数据后手动触发空间回收。
- 高并发环境：需评估锁表时间，避免高峰期操作。
- 替代方案：ALTER TABLE ... ENGINE=InnoDB 或导出/导入数据也能达到类似效果，但操作复杂度更高。
性能注意事项：
- 磁盘空间需求：重建表需要额外空间（约等于原表大小）。
- 日志与缓存：建议在低负载时段执行，并确保 innodb_buffer_pool_size 足够大以减少 I/O 压力。

总结

选项 C 正确，OPTIMIZE TABLE FACTORY 是唯一直接重组物理存储、释放空间并优化 I/O 效率的命令。其他选项因功能范围限制或操作方式低效被排除。实际使用中需结合业务场景权衡操作时机与资源消耗。

题目 176

Choose the best answer.

You must configure the MySQL command-line client to provide the highest level of trust and security when connecting to a remote MySQL Server.

Which value of --ssl-mode will do this?

A. VERIFY_CA

B. PREFERRED

C. VERIFY_IDENTITY

D. REQUIRED

正确答案

C. VERIFY_IDENTITY

关键解析

安全级别分析

根据官方文档对 --ssl-mode 的说明，各选项的安全严格性递增顺序为： DISABLED < PREFERRED < REQUIRED < VERIFY_CA < VERIFY_IDENTITY。要提供最高级别的信任和安全性，需满足以下条件：

强制加密连接（防止明文传输）；
验证服务器证书的合法性（防止伪造证书）；
验证服务器主机名与证书的匹配性（防止中间人攻击）。

选项对比

选项	加密强制	CA 验证	主机名验证	安全级别
`REQUIRED`	✅	❌	❌	低
`VERIFY_CA`	✅	✅	❌	高
`VERIFY_IDENTITY`	✅	✅	✅	最高

VERIFY_CA：
- 加密强制：必须建立加密连接（等同于 REQUIRED）。
- CA 验证：验证服务器证书是否由受信任的 CA 颁发。
- 局限性：未验证服务器主机名是否与证书匹配，可能被 DNS 劫持或中间人攻击。
VERIFY_IDENTITY：
- 在 VERIFY_CA 基础上：额外验证客户端连接的主机名与服务器证书中的 Subject Alternative Name (SAN) 或 Common Name (CN) 是否匹配。
- 安全增强：防止攻击者通过伪造证书或 IP 劫持伪装成目标服务器。例如，若服务器证书中指定域名为 db.example.com，客户端连接时若使用 192.168.1.1 或其他域名，连接将被拒绝。

错误选项排除

REQUIRED（选项 D）：仅强制加密，但不验证服务器证书的合法性。若服务器使用自签名证书或恶意证书，客户端仍会建立连接，存在安全风险。
PREFERRED（选项 B） 和 DISABLED（无关选项）：允许非加密回退或无加密，无法满足最高安全要求。

实际应用场景

企业级部署：使用 VERIFY_IDENTITY 可确保加密通信且服务器身份可信，适用于金融、医疗等对安全性要求严格的场景。
证书要求：需服务器证书包含正确的主机名信息（如 SAN 扩展），且客户端配置受信任的 CA 证书链。

总结

选项 C（VERIFY_IDENTITY）是唯一同时满足强制加密、CA 验证和主机名身份验证的配置，提供最高级别的安全性和信任。其他选项因缺少关键验证步骤被排除。实际部署时，需确保服务器证书合规，并配置客户端信任正确的 CA。

题目 177

You want to dump all databases with names that start with "db".

Which command will achieve this?

A. mysqlpump > all_db_backup.sql

B. mysqlpump --include-databases=db% --result-file=all_db_backup.sql

C. mysqlpump --include-databases=db --result-file=all_db_backup.sql

D. mysqlpump -- include-tables-db.% --result-file=all_db_backup.sql

正确答案

B. mysqlpump --include-databases=db% --result-file=all_db_backup.sql

关键解析

用户需要备份所有以 db 开头的数据库，需满足以下条件：

匹配数据库名称模式：使用通配符 % 表示任意字符序列（如 db1、db_backup 等）。
指定输出文件：通过 --result-file 参数明确备份文件的路径和名称。

选项逐项验证

选项	正确性	原因与依据
A. `mysqlpump > all_db_backup.sql`	错误	未指定任何过滤条件，默认备份所有数据库（包括系统库如 `mysql`、`sys` 等），与题目要求不符。
B. `mysqlpump --include-databases=db% --result-file=all_db_backup.sql`	正确	`--include-databases=db%`：通配符 `%` 匹配所有以 `db` 开头的数据库名称（如 `db1`、`db_log`）。 `--result-file`：指定输出文件路径，避免因操作系统编码问题导致备份文件损坏（如 Windows 下重定向符号 `>` 可能生成 UTF-16 文件）。
C. `mysqlpump --include-databases=db --result-file=all_db_backup.sql`	错误	`db%` 中的 `%` 缺失，仅匹配名为 `db` 的单个数据库，无法覆盖所有以 `db` 开头的数据库。
D. `mysqlpump -- include-tables-db.% --result-file=all_db_backup.sql`	错误	参数 `--include-tables-db.%` 语法错误，正确参数应为 `--include-databases=db%`。

技术扩展

通配符的使用：
- %：匹配任意长度字符序列（如 db% 匹配 db、db_2024）。
- _：匹配单个字符（如 db_ 匹配 db1，但不匹配 db12）。
- 示例：若需备份以 db 开头且第三个字符为数字的数据库（如 db2_backup），可结合 LIKE 表达式：--include-databases=db_%。
备份安全性：
- 避免默认重定向问题：在 Windows 中使用 > 可能生成 UTF-16 文件，导致恢复失败。--result-file 直接生成 ASCII 格式文件，兼容性更佳。
- 并行备份优化：可通过 --default-parallelism=N 指定并行线程数，提升大库备份效率。
其他过滤选项：
- 排除特定数据库：若需排除某些以 db 开头的库（如 db_temp），可结合 --exclude-databases=db_temp。
- 用户账号过滤：使用 --include-users 或 --exclude-users 控制备份的用户范围。

总结

选项 B 正确，其通过通配符 % 匹配所有以 db 开头的数据库，并利用 --result-file 确保输出文件格式安全。其他选项因语法错误、通配符缺失或功能不符被排除。实际备份时，建议结合业务需求调整通配符和并行参数以优化性能。

题目 178

You have an installation of MySQL 8 on Oracle Linux.

Consider the outputs:

mysql> SHOW GLOBAL VARIABLES
    -> WHERE Variable_name = 'tmpdir'
    -> OR Variable_name = 'tmp_table_size';
+-------------------+-----------+
| Variable_name     | Value     |
+-------------------+-----------+
| tmp_table_size    | 16777216  |
| tmpdir            | /tmp      |
+-------------------+-----------+
2 rows in set (0.01 sec)

shell> cd /var/lib/mysql
shell> ls -l | grep temp
drwxr-x---. 2 mysql mysql 4096 Dec 11 14:05 #innodb_temp

Which statement is true about disk temporary tables for this installation?

A. Only internal temporary tables from the optimizer will be created in tmpdir.

B. Temporary tables are created in tmpdir only after they reach tmp_table_size.

C. Temporary tables are created in tmpdir only if configured to use MyISAM.

D. Temporary tables will use the InnoDB temporary tablespace located in datadir.

E. Temporary tables will use the InnoDB temporary tablespace located in /tmp.

正确答案

D. Temporary tables will use the InnoDB temporary tablespace located in datadir.

关键解析

在 MySQL 8 中，InnoDB 引擎的临时表默认通过**独立的临时表空间（#innodb_temp）**管理，其路径位于数据目录（datadir）下。而 tmpdir 参数主要用于存储优化器生成的排序文件或非 InnoDB 引擎（如显式使用 MEMORY/MyISAM）的临时表。根据题目提供的上下文，需验证以下关键点：

tmpdir 和 tmp_table_size 的作用范围：
- tmp_table_size（16MB）控制内存临时表的最大大小（如 MEMORY 引擎表），若数据量超过此值则转存到 tmpdir。
- InnoDB 内部临时表直接使用 #innodb_temp 表空间，不受 tmp_table_size 限制。
临时表空间的实际存储位置：
- 数据目录 /var/lib/mysql 中存在 #innodb_temp 目录（题目中 ls -l | grep temp 的输出来源），说明 InnoDB 临时表空间默认位于 datadir 下，而非 tmpdir（/tmp）。
- MySQL 8 的临时表空间由参数 innodb_temp_tablespaces_dir 控制，默认值为 datadir/#innodb_temp，题目未显式修改此配置。

选项逐项验证

选项	正确性	原因与引用
A. 仅优化器的内部临时表使用 `tmpdir`	错误	优化器生成的内部临时表（如复杂查询中间结果）可能使用 `tmpdir` 存储中间文件，但 InnoDB 内部临时表始终优先使用 `#innodb_temp` 表空间，与 `tmpdir` 无关。
B. 临时表仅在超过 `tmp_table_size` 后使用 `tmpdir`	错误	`tmp_table_size` 仅影响内存引擎（如 MEMORY）的临时表。InnoDB 内部临时表直接使用表空间，无需依赖此参数。
C. 临时表仅在配置为 MyISAM 时使用 `tmpdir`	错误	MyISAM 临时表需显式创建且可能使用 `tmpdir`，但 MySQL 8 默认使用 InnoDB，题目未提及显式配置 MyISAM。
D. 临时表使用位于 `datadir` 的 InnoDB 临时表空间	正确	数据目录 `/var/lib/mysql` 中存在 `#innodb_temp`，验证了 InnoDB 临时表空间的实际位置，且 `datadir` 默认指向此路径。
E. 临时表使用位于 `/tmp` 的 InnoDB 临时表空间	错误	`/tmp` 是 `tmpdir` 的值，用于非 InnoDB 临时文件。InnoDB 临时表空间默认在 `datadir` 下，与 `/tmp` 无关。

技术扩展

InnoDB 临时表空间的特性：
- 独立存储：InnoDB 临时表数据存储在 #innodb_temp 目录中，不依赖 tmpdir。
- 自动清理：连接断开或实例重启时，临时表空间会被自动回收。
参数优先级与配置：
- 若显式设置 innodb_temp_tablespaces_dir，可自定义临时表空间路径，但题目未配置，因此默认使用 datadir。
- tmpdir 的用途包括排序文件（如 ORDER BY、GROUP BY）和用户显式创建的 MEMORY 引擎临时表。

总结

选项 D 正确，其基于 MySQL 8 默认的 InnoDB 临时表空间机制，结合题目中 datadir 下存在的 #innodb_temp 目录验证了存储位置。其他选项因混淆 tmpdir 的作用范围或未正确理解 InnoDB 临时表管理逻辑被排除。实际应用中，建议通过监控 Created_tmp_disk_tables 和 Created_tmp_tables 状态优化临时表性能。

题目 179

What is the correct syntax for using transparent data encryption with an existing InnoDB table?

A. ALTER TABLE t1 SET TDE = 'ON';

B. ALTER TABLE t1 ADD ENCRYPTED_TABLESPACE = 'Y';

C. ALTER TABLE t1 ENCRYPTION='Y';

D. ALTER TABLE t1 WITH ENCRYPTION USING MASTER KEY;

正确答案

C. ALTER TABLE t1 ENCRYPTION='Y';

关键解析

在 MySQL 中启用 InnoDB 透明数据加密（TDE）的语法需满足以下条件：

语法规范性：需使用 ENCRYPTION 选项直接指定加密状态，而非其他非标准参数（如 TDE 或 ENCRYPTED_TABLESPACE）。
操作对象：针对已存在的表，需通过 ALTER TABLE 语句修改表属性。

选项逐项验证

选项	正确性	原因与依据
A. `ALTER TABLE t1 SET TDE = 'ON';`	错误	MySQL 不支持 `SET TDE` 语法。加密选项应通过 `ENCRYPTION` 参数控制。
B. `ALTER TABLE t1 ADD ENCRYPTED_TABLESPACE = 'Y';`	错误	`ENCRYPTED_TABLESPACE` 并非 MySQL 官方支持的语法。正确方式是通过 `ENCRYPTION='Y'` 启用加密。
C. `ALTER TABLE t1 ENCRYPTION='Y';`	正确	根据文档，`ENCRYPTION='Y'` 是启用文件表空间加密的标准语法，适用于已存在的 InnoDB 表。
D. `ALTER TABLE t1 WITH ENCRYPTION USING MASTER KEY;`	错误	`WITH ENCRYPTION USING MASTER KEY` 是 SQL Server 的语法，与 MySQL 无关。MySQL 中主密钥（Master Key）的轮换需通过 `ALTER INSTANCE ROTATE INNODB MASTER KEY` 执行，而非在表级别操作。

技术扩展

加密前提条件：
- 必须启用 innodb_file_per_table 以支持文件表空间加密。
- 需提前安装并配置密钥环插件（如 keyring_file 或 keyring_okv）。
加密与性能：
- 加密操作仅影响表空间数据文件（.ibd），不会修改表结构或索引。
- 加密后的表空间在读写时需解密/加密，可能轻微增加 CPU 负载，但可通过硬件加速优化。
加密流程：
- 启用加密：ALTER TABLE t1 ENCRYPTION='Y';
- 禁用加密：ALTER TABLE t1 ENCRYPTION='N';
- 密钥轮换：通过 ALTER INSTANCE ROTATE INNODB MASTER KEY; 更新主密钥（需 SUPER 权限）。

总结

选项 C 正确，其语法符合 MySQL 官方文档对 InnoDB 透明数据加密的实现规范。其他选项因语法错误或混淆其他数据库系统的实现方式被排除。实际部署时需确保密钥环插件已加载，并监控加密对性能的影响。

题目 180

Choose the best answer.

You have configured GTID-based asynchronous replication with one master and one slave. A user accidentally updated some data on the slave. To fix this, you stopped replication and successfully reverted the accidental changes.

Examine the current GTID information:

Master uuid:                              aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa
Master gtid_executed:                     aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-10300
Master gtid_purged:                       aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-3820
Slave uuid:                               bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb
Slave gtid_executed:                      aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-10167,
                                         bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb:1-9
Slave gtid_purged:                        aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-2312

You must fix GTID sets on the slave to avoid replicating unwanted transactions in case of failover.

Which set of actions would allow the slave to continue replicating without erroneous transactions?

A. RESET MASTER; SET GLOBAL gtid_purged=aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa:1-2312; SET GLOBAL gtid_executed=aaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaa:1-10167;

B. RESET MASTER; SET GLOBAL gtid_purged=aaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaa:1-10167;

C. RESET SLAVE;SET GLOBAL gtid_purged=aaaaa-aaa-aaaa-aaaa-aaaaaaaa:1-3820; SET GLOBAL gtid_executed=aaaaaa-aaaa-aaa-aaaa-aaaaaaaaaaa:1-10300;

D. SET GLOBAL gtid_purged=aaaaaa-aaa-aaa-aaaa-aaaaaaaa:1-2312, bbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbb:1-9; SET GLOBAL gtid_executed=aaaaaaa-aaaa-aaaa-aaaa-aaaaaa:1-10167;

E. RESET SLAVE; SET GLOBAL gtid_purged=aaaaaaa-aaa-aaaa-aaa-aaaaaaaa:1-10167;

正确答案

B. RESET MASTER; SET GLOBAL gtid_purged=aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-10167;

关键解析

核心问题分析

从库因误操作执行了本地事务（bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb:1-9），导致其 gtid_executed 包含主库事务 1-10167 和本地事务。这会破坏 GTID 连续性，若从库被提升为主库，这些本地事务会被传播，导致数据不一致。需通过以下步骤修复：

关键修复逻辑

清除本地 GTID：
- RESET MASTER：清除从库的二进制日志和 GTID 执行历史（gtid_executed 和 gtid_purged），移除本地事务 bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb:1-9 的干扰。
- 作用：重置后的 gtid_executed 和 gtid_purged 为空，为后续设置提供干净的基础。
设置 gtid_purged：
- SET GLOBAL gtid_purged='aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-10167'：
  - 主库的 gtid_executed 是 1-10300，但 gtid_purged 为 1-3820（已清除的 binlog 范围）。
  - 从库需将 gtid_purged 设置为覆盖主库已清除的 1-3820 且包含已同步的 1-10167，确保从库声明这些事务已处理，无需重新请求。
  - 此设置使从库从主库的 10168 开始同步，避免重复应用 1-10167。

错误选项排除

选项	错误原因
A	`SET GLOBAL gtid_executed` 是无效操作（`gtid_executed` 是只读变量，无法手动修改）。
C	`SET GLOBAL gtid_executed` 同样无效，且 `gtid_purged=1-3820` 未覆盖从库已同步的 `1-10167`，导致后续复制请求已清除的 binlog（`1-3820`），引发错误。
D	包含从库本地事务的 GTID（`bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb:1-9`），未清除本地事务的干扰，故障转移时仍会传播错误事务。
E	`RESET SLAVE` 仅清除复制通道信息，不重置 GTID 状态，无法解决本地事务问题。

技术验证

执行选项 B 后，从库的 GTID 状态将变为：

gtid_executed：aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-10167（覆盖主库已同步的事务）
gtid_purged：aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-10167（声明这些事务无需重新请求）

此时重启复制，从库会从主库的 10168 开始同步，确保数据一致性且跳过本地误操作事务。

注意事项

GTID 连续性：若主库的 gtid_purged 包含 1-3820，从库必须声明已处理此范围，否则会因请求已清除的 Binlog 导致复制中断（错误 1236）。
备份恢复场景：若从库基于备份重建，需使用 mysqldump --set-gtid-purged=ON 保留 GTID 元数据，避免 GTID 断裂。

总结

选项 B 正确，其通过 RESET MASTER 清除本地事务，并设置 gtid_purged 覆盖主库已清除和已同步的 GTID 范围，确保从库安全恢复复制。其他选项因语法错误、未清除本地事务或忽略主库 Binlog 清除范围被排除。

题目 181

What does the binlog dump thread do?

A. It monitors and schedules the rotation/deletion of the binary logs.

B. It connects to the master and asks it to send updates recorded in its binary logs.

C. It acquires a lock on the binary log for reading each event to be sent to the slave.

D. It reads the relay log and executes the events contained in them.

正确答案

C. It acquires a lock on the binary log for reading each event to be sent to the slave.

关键解析

在 MySQL 主从复制中，binlog dump thread 是主库（Master）上的一个关键线程，其核心职责是将主库的二进制日志（Binlog）内容发送给从库（Slave）。

选项逐项验证

选项	正确性	原因与依据
A. 监控并调度二进制日志的轮换/删除	错误	二进制日志的轮换和删除由 `expire_logs_days` 或 `max_binlog_size` 参数控制，与 `binlog dump thread`无关。
B. 连接到主库并请求发送二进制日志的更新	错误	这是从库的 I/O 线程的行为（从库主动连接主库请求数据），而非主库的 `binlog dump thread`。
C. 获取二进制日志锁以读取需发送的事件	正确	`binlog dump thread`在读取 Binlog 事件时会加锁，确保事务顺序性和数据一致性。
D. 读取并执行中继日志中的事件	错误	这是从库的 SQL 线程的职责（负责解析并执行 Relay Log 中的事件）。

技术扩展

线程行为细节：
- binlog dump thread 由主库为每个连接的从库创建，每个从库对应一个独立的线程。其工作流程为：
  - 从库连接主库后，主库创建该线程。
  - 线程读取 Binlog 事件，先加锁确保原子性，读取完成后释放锁。
  - 将事件通过网络发送至从库的 I/O 线程，从库接收后写入 Relay Log。
锁的作用：
- 加锁的目的是防止主库在发送过程中修改 Binlog 文件，保证事务事件的顺序性和完整性。
线程状态监控：
- 可通过 SHOW PROCESSLIST 查看线程状态，常见状态包括：
  - Master has sent all binlog to slave; waiting for binlog to be updated（空闲等待新事件）
  - Sending binlog event to slave（正在发送事件）。

总结

选项 C 正确，其准确描述了 binlog dump thread在读取 Binlog 事件时通过加锁确保数据一致性的核心机制。其他选项混淆了主从复制中不同线程的职责（如从库的 I/O 线程或 SQL 线程），或涉及与日志管理无关的操作。实际应用中，建议通过 SHOW PROCESSLIST 监控线程状态，优化主从同步性能。

题目 182

Choose the best answer.

You have just installed MySQL on Oracle Linux and adjusted your /etc/my.cnf parameters to suit your installation.

Examine the output:

\# systemctl start mysqld
Job for mysqld.service failed because the control process exited with error code. See "systemctl status mysqld.service" and "journalctl -xe" for details.

\# systemctl status mysqld.service
mysqld.service - MySQL Server
Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Thu 2019-12-12 07:54:53 ACDT; 33s ago
Docs: man:mysqld(8)
https://dev.mysql.com/a/doc/refman/en/using-systend.html
Process: 2732 Execstart=/usr/ sbin/mysqld $MYSQLD_OPTS (code=exited, status=1/ FAILURE)
Process: 2705 ExecStartPre=/usr/bin/mysqld_pre_systemd (code=exited, status=0/ SUCCESS)
Main PID: 2732 (code=exited, status=1/FAILURE)
Status: "Server startup in progress "

Dec 12 07:54:49 oel7 systemd[1]: Starting MySQL Server...
Dec 12 07:54:53 oel7 systemd[1] : mysqld.service: main process exited, code=exited, status=1/ FAILURE
Dec 12 07 :54:53 oel7 systemd[1] : Failed to start MySQL Server
Dec 12 07 :54:53 oel7 systemd[1] :Unit mysqld.service entered failed state.
Dec 12 07:54:53 oel7 systemd[1]: mysqld.service failed.

What statement is true about the start attempt?

A. systemd attempted to start mysqld, found another systemd mysqld process running, and shut it down.

B. MySQL server continued to start up even though another process existed.

C. systemd waited for 30 seconds before timing out and start up failed.

D. systemd found the mysqld service disabled and failed to start it.

E. MySQL server was not started due to a problem while executing process 2732.

正确答案

E. MySQL server was not started due to a problem while executing process 2732.

关键解析

从日志信息可明确看出：

关键报错点：Process: 2732 ExecStart=/usr/sbin/mysqld $MYSQLD_OPTS (code=exited, status=1/FAILURE)，表明执行 mysqld 主进程时发生错误（状态码为 1），导致服务启动失败。
服务状态：Active: failed (Result: exit-code)，进一步验证进程 2732 执行失败是根本原因。

选项逐项验证

选项	正确性	原因与依据
A. systemd 尝试启动 mysqld 时发现其他进程运行并终止	错误	日志未显示进程冲突或强制终止记录，仅主进程自身执行失败。
B. MySQL 服务在其他进程存在时仍继续启动	错误	日志明确显示服务因进程退出而失败，未提及其他进程干扰。
C. systemd 等待30秒后超时失败	错误	日志未显示超时提示（如 `Timeout` 或 `Start request repeated too quickly`），错误直接由进程执行失败触发。
D. systemd 发现服务被禁用导致启动失败	错误	服务状态显示 `enabled`（`Loaded` 行），说明服务已启用。
E. MySQL 因进程2732执行问题未启动	正确	日志直接关联进程2732的失败状态码（`status=1`）与服务启动失败。

技术扩展

常见进程执行失败原因：
1. 依赖库缺失：例如 libssl 或 libcrypto 未安装。
2. 配置文件错误：my.cnf 中存在语法错误或无效参数。
3. 权限问题：数据目录或日志文件权限不足。
4. 端口冲突：3306端口被其他进程占用。
排查步骤（结合日志与配置）：
1. 查看错误日志：sudo tail -n 100 /var/log/mysqld.log，定位具体错误（如权限、依赖或配置）。
2. 验证配置文件：sudo mysqld --validate-config，检查 my.cnf 语法。
3. 检查依赖库：ldd /usr/sbin/mysqld，确认所有动态库存在。

总结

选项 E 正确，其准确描述了日志中主进程执行失败导致服务启动终止的直接原因。其他选项因与日志内容矛盾或缺乏依据被排除。实际场景中需结合错误日志进一步排查具体问题（如库缺失、配置错误等）。

题目 183

Choose the best answer.

You wish to protect your MySQL database against SQL injection attacks.

Which method would fail to do this?

A. using stored procedures for any database access

B. avoiding concatenation of SQL statements and user-supplied values in an application

C. using PREPARED STATEMENTS

D. installing and configuring the Connection Control plugin

正确答案

D. installing and configuring the Connection Control plugin

关键解析

SQL注入的防护需从代码逻辑和数据库配置两方面入手。题目要求选出无法防御SQL注入的选项，需结合各方法的技术原理与防护能力进行判断：

选项	有效性分析	依据
A. 使用存储过程	部分有效但可能失效	存储过程（Stored Procedures）本身是预编译的，理论上可减少注入风险。但若存储过程中动态拼接SQL语句或未参数化处理输入，仍可能被注入。例如：`EXECUTE IMMEDIATE 'SELECT * FROM users WHERE id=`
B. 避免拼接SQL与用户输入	有效	直接拼接用户输入和 SQL 语句是注入攻击的根源。通过参数化查询或预处理语句替代拼接，可彻底隔离代码与数据，防止注入。例如：`SELECT * FROM users WHERE id = ?`（参数绑定值而非拼接字符串）。
C. 使用预处理语句	最有效	预处理语句（Prepared Statements）通过预编译 SQL 模板并绑定参数，确保用户输入仅作为数据而非代码执行，是业界公认的黄金标准。例如：Java 的 `PreparedStatement` 或 PHP 的 `PDO` 实现。
D. 配置Connection Control插件	无效	Connection Control 插件的功能是限制客户端连接频率（如防止暴力破解登录），与 SQL 注入防护无关。其作用范围在连接层而非查询逻辑层，无法阻止已建立连接的恶意 SQL 注入攻击。

技术扩展

Connection Control 插件的局限性：该插件通过 max_connections_per_hour 等参数控制连接行为，例如阻止频繁尝试登录的 IP。然而，一旦攻击者成功建立合法连接并发送恶意 SQL 请求，此插件无法检测或拦截注入攻击。
存储过程的风险场景：若开发者误用动态 SQL（如通过字符串拼接生成存储过程内的查询），攻击者仍可注入恶意代码。例如：
```
CREATE PROCEDURE GetUser (IN user_id VARCHAR(255))
BEGIN
    SET @sql = CONCAT('SELECT * FROM users WHERE id = ', user_id);
    PREPARE stmt FROM @sql;
    EXECUTE stmt;
END
```
此处直接拼接 user_id 会导致注入漏洞。

总结

选项 D 正确，因其与 SQL 注入防护无直接关联。其他选项（A/B/C）均涉及代码层或查询逻辑层的安全机制，而 D 仅针对连接安全，无法阻止注入攻击。实际开发中需综合使用预处理语句、输入验证和权限控制等多层防护策略。

题目 184

Choose the best answer.

You plan to upgrade your MySQL 5.7 instance to version 8.You have installed the 8 build of MySQL Shell. Examine this command executed from the operating system shell prompt:

mysqlsh --uri root@localhost:3306 -- util check-for-server-upgrade

Which statement is true?

A. It documents any problems with your 5.7 tables to make them ready to upgrade to 8.

B. It fails because the operation name must be in camelCase.

C. It fixes any problems with your 5.7 tables to make them ready to upgrade to 8.

D. It is mandatory to clear the history of prior results before executing this process a second time or later.

E. It fails because checkForServerUpgrade must be executed only within an active shell session as a method of the util object.

F. It is mandatory to run this command so that MySQL 8.0 software's auto-upgrade process has the details it needs to operate properly.

正确答案

A. It documents any problems with your 5.7 tables to make them ready to upgrade to 8.

关键解析

命令语法分析
- 执行的命令为：
```
mysqlsh --uri root@localhost:3306 -- util check-for-server-upgrade
```
- mysqlsh：MySQL Shell 命令行工具。
- --uri root@localhost:3306：指定连接到本地 3306 端口的 MySQL 实例，用户为 root。
- -- util check-for-server-upgrade：调用 util 模块的升级检查工具，使用 kebab-case 格式的操作名 check-for-server-upgrade。
文档中的关键规则
- 根据文档，升级检查工具 util.checkForServerUpgrade() 用于检测升级兼容性问题，而非修复问题。
- 命令行中可使用 kebab-case（如 check-for-server-upgrade）或 camelCase（如 checkForServerUpgrade），两者均有效。
- 检查工具生成问题报告，但不影响后续升级流程，且非强制运行。

选项分析

选项	描述	正确性	解析
A. 记录 5.7 表的问题以准备升级	正确。该命令检测表结构、配置等兼容性问题，并生成报告。	✅	文档明确说明工具会检查数据库对象（如表、列）的兼容性，并提示需手动修复的问题。
B. 因操作名必须为 camelCase 而失败	错误。命令行支持 kebab-case 和 camelCase 两种格式。	❌	文档示例中存在 `check-for-server-upgrade` 的 kebab-case 用法，表明该格式合法。
C. 修复表的问题以准备升级	错误。工具仅检测问题，不执行修复操作。	❌	文档强调“检查工具不自动修复问题，需手动处理”。
D. 必须清除历史结果才能再次执行	错误。重复执行不依赖历史结果，无需清除。	❌	文档未提及需清除历史结果，检查过程独立。
E. 必须在 Shell 会话内执行	错误。命令行和交互式会话均可执行。	❌	文档提供了命令行执行示例（如 `mysqlsh -- util check-for-server-upgrade`），表明支持外部执行。
F. 必须运行此命令以支持自动升级	错误。检查非强制，仅为推荐步骤。	❌	文档说明“升级可在不清除警告的情况下进行”，且自动升级流程不依赖此命令。

结论

正确选项：A ，该命令通过 MySQL Shell 的升级检查工具，扫描 MySQL 5.7 实例中与 8.0 不兼容的表结构、配置项等问题，并生成报告，帮助用户在升级前定位需手动修复的问题。

题目 185

Choose the best answer.

Your MySQL instance is capturing a huge amount of financial transactions every day in the finance database. Company policy is to create a backup every day. The main tables being updated are prefixed with transactions-. These tables are archived into tables that are prefixed with archives- each month.

mysqlbackup --optimistic-busy-tables="^finance\. transactions-.*" backup

Which optimization process best describes what happens with the redo logs?

A. The redo logs are backed up first, then the transaction and archive tables.

B. The redo logs are backed up only if there are changes showing for the transactions tables.

C. The redo logs are not backed up at all.

D. The transaction tables are backed up first, then the archive tables and redo logs.

E. The archive tables are backed up first, then the transaction tables and redo logs.

正确答案

E. The archive tables are backed up first, then the transaction tables and redo logs.

关键解析

乐观备份的两阶段机制
- 乐观阶段：备份不活跃表（如 archives-* 表），此时不备份 Redo 日志。
- 普通阶段：备份忙碌表（如 transactions-* 表），此时备份 Redo 日志。
题目中通过 --optimistic-busy-tables="^finance\. transactions-.*" 明确将 transactions-* 表标记为“忙碌表”，其他表（如 archives-*）默认视为不活跃表。
备份顺序与 Redo 日志处理
- 乐观阶段：优先备份不活跃表（archives-*），不涉及 Redo 日志。
- 普通阶段：备份忙碌表（transactions-*），并在此阶段最后备份 Redo 日志（因 Redo 日志的完整性需覆盖整个普通阶段的操作）。
因此，完整的备份顺序为：
archives-\*（乐观阶段） → transactions-\*（普通阶段） → Redo 日志（普通阶段）。

选项验证

选项	正确性	原因与依据
A	错误	Redo 日志的备份发生在普通阶段，而非优先备份。
B	错误	Redo 日志的备份与事务表是否有变更无关，只要进入普通阶段即备份。
C	错误	Redo 日志是普通阶段的必要备份内容。
D	错误	归档表（`archives-*`）已乐观阶段先备份。
E	正确	归档表在乐观阶段优先备份，事务表和 Redo 日志在普通阶段后续处理。

技术扩展

--optimistic-busy-tables 的作用：
- 通过正则匹配标记“忙碌表”，其余表默认在乐观阶段备份。该参数优化了备份流程，减少 Redo 日志量。
Redo 日志的备份逻辑：
- Redo 日志仅在普通阶段备份，以覆盖该阶段的所有事务（包括事务表的操作），确保恢复一致性。

总结

选项 E 正确，符合乐观备份的分阶段逻辑：

不活跃表（archives-\*）在乐观阶段优先备份（不涉及 Redo 日志）。
忙碌表（transactions-\*）和 Redo 日志在普通阶段后续处理。

因此，备份顺序为：归档表 → 事务表 → Redo 日志。

题目 186

Choose the best answer.

You must replay the binary logs on your MySQL server.

Which command do you use?

A. cat binlog.000003 binlog.000004 binlog.000005 | mysql -h 127.0.0.1

B. mysqlpump -h 127.0.0.1 binlog.000003 binlog.000004 binlog.000005

C. mysql -h 127.0.0.1 --local-infile binlog.000003 binlog.000004 binlog.000005

D. mysqlbinlog binlog.000003 binlog.000004 binlog.000005 | mysql -h 127.0.0.1

E. mysqlbinlog -h 127.0.0.1 binlog.000003 binlog.000004 binlog.000005

正确答案

D. mysqlbinlog binlog.000003 binlog.000004 binlog.000005 | mysql -h 127.0.0.1

关键解析

mysqlbinlog 工具的核心作用
- MySQL 的 mysqlbinlog 是专门用于解析二进制日志（Binlog）文件的工具。它可以将二进制格式的日志转换为可执行的 SQL 语句，并通过管道（|）传递给 mysql 客户端执行，从而实现数据恢复或日志回放。这一流程是 MySQL 官方推荐的标准方法。
选项分析
- 选项 A：cat 命令直接合并二进制文件并传递给 mysql 会失败，因为 Binlog 是二进制格式，未经解析无法直接执行。
- 选项 B：mysqlpump 是 MySQL 的备份工具，与 Binlog 回放无关，未在搜索结果中提及相关功能。
- 选项 C：--local-infile 参数用于加载本地文件，与 Binlog 无关，语法也不符合要求。
- 选项 D：正确组合了 mysqlbinlog 解析日志并通过管道传递给 mysql 执行的步骤。
- 选项 E：mysqlbinlog 本身不直接连接 MySQL 服务器，缺少管道传递到 mysql 的步骤，无法执行 SQL。
技术细节验证
- 回放 Binlog 的标准命令格式为：
```
mysqlbinlog [binlog文件列表] | mysql -h [主机地址]  
```
  这与选项 D 完全一致。
- 直接使用 mysqlbinlog 解析后的输出需要通过 mysql 客户端执行才能生效。

总结

选项 D 是唯一符合 MySQL 官方文档和实际操作的正确答案。

题目 187

Choose the best answer.

Examine this statement, which executes successfully:

CREATE TABLE world.city (
  ID int NOT NULL AUTO_INCREMENT,
  Name char(35) NOT NULL DEFAULT '',
  CountryCode char(3) NOT NULL DEFAULT '',
  District char(20) NOT NULL DEFAULT '',
  Population int NOT NULL DEFAULT '0',
  PRIMARY KEY (ID),
  KEY CountryCode (CountryCode)
) ENGINE=InnoDB;

You want to improve the performance of this query:

SELECT Name
FROM world.city
WHERE Population BETWEEN 1000000 AND 2000000;

Which change enables the query to succeed while accessing fewer rows?

A. ALTER TABLE world.city ADD INDEX (Name) ;

B. ALTER TABLE world.city ADD SPATIAL INDEX (Name) ;

C. ALTER TABLE world.city ADD FULLTEXT INDEX (Name) ;

D. ALTER TABLE world.city ADD FULLTEXT INDEX (Population) ;

E. ALTER TABLE world.city ADD SPATIAL INDEX (Population) ;

F. ALTER TABLE world.city ADD INDEX (Population) ;

正确答案

F. ALTER TABLE world.city ADD INDEX (Population) ;

关键解析

查询条件与索引类型匹配
- 原查询的过滤条件是 Population BETWEEN 1000000 AND 2000000，属于数值范围查询。此时，普通索引（B-Tree 索引） 是最优选择，因为 B-Tree 索引支持范围查询和排序操作，可以快速定位到符合条件的数据行。
- 选项 F 在 Population 列上创建普通索引，直接针对查询条件优化，使 MySQL 能通过索引快速过滤出目标行，减少全表扫描的开销。
- 其他选项（如全文索引、空间索引）均不适用于数值范围查询场景。
索引覆盖与性能优化
- 原查询仅需返回 Name 字段，但过滤条件基于 Population。若在 Population 上建立索引，虽然需要回表获取 Name，但索引能显著减少需要访问的数据行数（仅扫描 Population 在 100 万到 200 万之间的行），从而提升性能。
- 若在 Name 上建立索引（选项 A、B、C），由于查询条件与 Name 无关，索引完全无法生效，仍需要全表扫描。
排除无效索引类型
- 全文索引（FULLTEXT）：适用于文本字段的模糊搜索（如关键词匹配），无法优化数值范围查询。选项 C、D 错误。
- 空间索引（SPATIAL）：仅适用于地理空间数据类型（如 POINT、POLYGON），与数值字段无关。选项 B、E 错误。

选项验证

选项	正确性	原因与依据
A	错误	在 `Name` 列上添加普通索引无法优化基于 `Population` 的查询条件。
B	错误	空间索引仅适用于地理空间数据，`Name` 是字符串字段，不适用。
C	错误	全文索引用于文本内容搜索，无法优化数值范围查询。
D	错误	`Population` 是数值字段，全文索引不适用且无法优化范围查询。
E	错误	空间索引与数值字段无关，无法优化查询。
F	正确	普通索引支持数值范围查询，显著减少访问行数。

技术扩展

复合索引的进一步优化：
- 若查询需要更高性能，可创建 (Population, Name) 的复合索引，直接通过索引覆盖（Covering Index）避免回表操作。但本题选项中未提供此选项，因此 F 是最优解。
索引选择性：
- Population 的范围条件具有较高的选择性（即符合条件的行占总行数的比例较低），因此索引效果显著。

总结

选项 F 正确，通过在 Population 列上创建普通索引，MySQL 可以直接利用索引快速定位到目标数据行，减少需要扫描的行数，从而提升查询性能。其他索引类型因不匹配查询场景或数据类型而无效。

题目 188

Choose the best answer.

Examine this parameter setting:

audit_log=FORCE_LOG_PERMANENT

What effect does this have on auditing?

A. It prevents the audit plugin from being removed from the running server.

B. It prevents the audit log from being removed or rotated.

C. It causes the audit log to be created if it does not exist.

D. It will force the load of the audit plugin even in case of errors at server start.

正确答案

A. It prevents the audit plugin from being removed from the running server.

关键解析

参数 audit_log=FORCE_LOG_PERMANENT 的核心作用
- audit_log 参数中的 FORCE_PLUS_PERMANENT 或类似选项（如题目中的 FORCE_LOG_PERMANENT）的主要功能是强制启用审计插件，并将其标记为“永久”，从而 防止插件在服务器运行时被卸载或删除。这一设置还会在插件初始化失败时导致服务器启动失败，确保审计功能的强制性和稳定性。
选项验证
- 选项 A：正确。通过 FORCE_LOG_PERMANENT 参数，审计插件会被锁定为永久状态，无法通过 UNINSTALL PLUGIN 命令移除，确保审计功能持续生效。
- 选项 B：错误。日志轮换（如文件删除或轮转）由 audit_log_rotate_on_size 和 audit_log_rotations 等参数控制，与 FORCE_LOG_PERMANENT 无关。
- 选项 C：错误。日志文件的创建是审计插件的默认行为，不依赖此参数。
- 选项 D：错误。若插件初始化失败（如配置错误或文件缺失），服务器会因 FORCE_LOG_PERMANENT 的设置而拒绝启动，而非强制加载插件。
技术扩展
- 审计插件持久化：FORCE_LOG_PERMANENT 属于 MySQL 企业版审计功能的强制策略，通常需要在配置文件（如 my.cnf）中设置，确保审计功能在服务器重启后仍保持激活。
- 与日志轮换的关系：此参数仅控制插件的运行状态，日志文件的轮换需通过 audit_log_file_rotate_size 和 audit_log_rotations 单独配置。

总结

选项 A 正确，audit_log=FORCE_LOG_PERMANENT 的核心作用是锁定审计插件，防止其在运行时被删除或卸载，从而确保审计日志的持续记录。其他选项均与参数的实际功能无关或存在逻辑错误。

题目 189

Choose the best answer.

Examine these commands and output:

mysql> SHOW FULL PROCESSLIST;
+----+-----------------+...+-------------------------------------+-----------------------------------+
| Id | User            |...| State                               | Info                              |
+----+-----------------+...+-------------------------------------+-----------------------------------+
| 6  | event_scheduler |...| Waiting on empty queue              | NULL                              |
| 20 | root            |...|    							     | NULL               				 |
| 21 | root            |...| 								     | NULL                              |
| 22 | root            |...| Waiting for table metadata lock     | optimize table test.demo_test     |
| 24 | root            |...| Waiting for table metadata lock     | select * from test.demo_test      |
| 25 | root            |...| starting                            | SHOW FULL PROCESSLIST             |
+----+-----------------+...+-------------------------------------+-----------------------------------+

mysql> SELECT object_type, object_schema, object_name, lock_type, lock_status, owner_thread_id, owner_event_id 
-> FROM performance_schema.metadata_locks WHERE object_schema != 'performance_schema';
+--------------+---------------+-------------+----------------------+--------------+-----------------+---------------+
| OBJECT_TYPE  | OBJECT_SCHEMA | OBJECT_NAME | LOCK_TYPE            | LOCK_STATUS  | OWNER_THREAD_ID | OWNER_EVENT_ID|
+--------------+---------------+-------------+----------------------+--------------+-----------------+---------------+
| TABLE        | test          | demo_test   | SHARED_READ          | GRANTED      | 60              | 7             |
| TABLE        | test          | demo_test   | SHARED_WRITE         | GRANTED      | 60              | 9             |
| SCHEMA       | test          | NULL        | INTENTION_EXCLUSIVE  | GRANTED      | 62              | 6             |
| TABLE        | test          | demo_test   | SHARED_NO_READ_WRITE | PENDING      | 62              | 6             |
+--------------+---------------+-------------+----------------------+--------------+-----------------+---------------+

mysql> SELECT thread_id, processlist_id, processlist_user, parent_thread_id 
-> FROM performance_schema.threads WHERE processlist_user='root';
+-----------+---------------+----------------+------------------+
| THREAD_ID | PROCESSLIST_ID| PROCESSLIST_USER| PARENT_THREAD_ID|
+-----------+---------------+----------------+------------------+
| 60        | 20            | root           | NULL             |
| 61        | 21            | root           | NULL             |
| 62        | 22            | root           | 1                |
| 64        | 24            | root           | 1                |
| 65        | 25            | root           | NULL             |
+-----------+---------------+----------------+------------------+

Which connection ID is holding the metadata lock?

A. 21

B. 25

C. 6

D. 22

E. 20

F. 24

正确答案

E. 20

关键解析

锁定持有者的识别依据
- metadata_locks 表中的 LOCK_STATUS=GRANTED 表示当前已授予的元数据锁。题目中，OWNER_THREAD_ID=60 的线程持有 SHARED_READ 和 SHARED_WRITE 锁（对应 test.demo_test 表），而 OWNER_THREAD_ID=62 的线程持有 INTENTION_EXCLUSIVE 锁（对应 test 数据库）。
- threads 表映射关系：THREAD_ID=60 对应 PROCESSLIST_ID=20（即连接 ID 20）。
阻塞链分析
- 连接 ID 22（线程 62） 的 OPTIMIZE TABLE 需要获取 SHARED_NO_READ_WRITE 锁，但该锁处于 PENDING 状态，说明被其他锁阻塞。
- 连接 ID 20（线程 60） 已持有 SHARED_READ 和 SHARED_WRITE 锁，这些锁会阻止 OPTIMIZE TABLE 和 SELECT 操作获取更高优先级的锁（如排他锁）。
关键排除法
- 选项 D（22） 是等待锁的线程，非持有者。
- 选项 E（20） 是唯一持有 GRANTED 锁且未被阻塞的连接。

选项验证

选项	正确性	原因与依据
A (21)	错误	线程 61 在 `threads` 表中无关联的元数据锁。
B (25)	错误	线程 65 仅用于执行 `SHOW PROCESSLIST`，未持有锁。
C (6)	错误	`event_scheduler` 线程（ID 6）无关联的元数据锁。
D (22)	错误	线程 62 的锁为 `PENDING` 状态，是被阻塞方。
E (20)	正确	线程 60（连接 ID 20）持有 `GRANTED` 锁，是阻塞源。
F (24)	错误	线程 64（连接 ID 24）处于等待状态，非持有者。

技术扩展

元数据锁的优先级规则：
- SHARED_READ 和 SHARED_WRITE 锁允许并发读/写，但会阻塞需要排他锁的操作（如 OPTIMIZE TABLE）。
- INTENTION_EXCLUSIVE 锁表示线程计划对数据库对象进行排他操作，但尚未实际获取表级锁。

总结

连接 ID 20 是唯一持有已授予元数据锁（SHARED_READ 和 SHARED_WRITE）的线程，导致其他操作（如 OPTIMIZE TABLE 和 SELECT）被阻塞。选项 E 正确。

题目 190

Choose the best answer.

An attempt to recover an InnoDB Cluster fails.

Examine this set of messages and responses:

host3: 3377 ssl JS > dba.rebootClusterFromCompleteOutage()
Reconfiguring the default cluster from complete outage. . .
The instance ' host1:3377' was part of the cluster configuration.
Would you like to rejoin it to the cluster? [y/N] : y
The instance ' host2:3377' was part of the cluster configuration.
Would you like to rejoin it to the cluster? [y/N] : y
Dba.rebootClusterFromCompleteOutage: The active session instance isn't the most updated in comparison with the ONLINE instances of the Cluster's metadata.
Please use the most up to date instance: ' host1:3377'. (RuntimeError)

Which statement is true?

A. The cluster is running and there is at least one ONLINE instance.

B. The instance deployed on host3 must be synchronized from a donor deployed on host1 by using the command cluster.addInstance('host1:3377').

C. It is possible to determine the most up-to-date instance by comparing different global transaction identifier (GTID) sets with GTID_SUBSET(set1, set2).

D. The active session instanceis invalid and must be re-created by using the command shell.connect('host3:3377').

E. The instance deployed on host3 must be rebuilt with a backup from the primary instance.

正确答案

C. It is possible to determine the most up-to-date instance by comparing different global transaction identifier (GTID) sets with GTID_SUBSET (set1, set2).

关键解析

题目描述了一个 MySQL InnoDB Cluster 的恢复失败场景，并提供了错误信息。关键点在于：

用户尝试使用 dba.rebootClusterFromCompleteOutage() 恢复集群。
系统提示当前活动会话的实例（host3:3377）不是最新的，需要使用 host1:3377 作为最新实例。
需要判断哪个选项最准确地描述了问题的解决方法。

错误信息关键点：

The active session instance isn't the most updated in comparison with the ONLINE instances of the Cluster's metadata.
- 表示当前连接的实例（host3:3377）的数据不是最新的，必须使用 host1:3377 作为最新实例。
- ONLINE instances 指的是元数据中记录的、被认为可用的实例，但这些实例可能并未实际运行。
Please use the most up to date instance: 'host1:3377'.
- 明确指出 host1:3377 是最新实例，需切换到该实例进行恢复。

正确选项解析：C. It is possible to determine the most up-to-date instance by comparing different global transaction identifier (GTID) sets with GTID_SUBSET(set1, set2).

GTID（Global Transaction Identifier） 是 MySQL 复制的核心机制，用于唯一标识事务。
在 InnoDB Cluster 中，GTID 用于确保所有实例的数据一致性。
通过比较不同实例的 GTID 集合（gtid_executed），可以确定哪个实例拥有最新的事务。
GTID_SUBSET(set1, set2) 是 MySQL 提供的函数，用于验证一个 GTID 集合是否是另一个的子集，从而判断数据的完整性。
因此，选项 C 描述了一种可行的技术手段，用于确定哪个实例是最新的，符合题目中“必须使用 host1:3377 作为最新实例”的要求。

其他选项分析

A. The cluster is running and there is at least one ONLINE instance.

❌ 错误。题目明确指出是“从完全宕机中恢复”（rebootClusterFromCompleteOutage），说明集群已完全不可用，没有 ONLINE 实例。
“ONLINE instances” 是指元数据中记录的实例状态，而非实际运行状态。

B. The instance deployed on host3 must be synchronized from a donor deployed on host1 by using the command cluster.addInstance('host1:3377').

❌ 错误。cluster.addInstance() 用于将实例加入集群，不是用于恢复。
在恢复场景中，应使用 dba.rebootClusterFromCompleteOutage()，而非 addInstance()。

D. The active session instance is invalid and must be re-created by using the command shell.connect('host3:3377').

❌ 错误。错误信息并未指出 host3:3377 的实例无效，只是说明它不是最新的。
重新连接不会解决问题，问题在于实例的数据不是最新的。

E. The instance deployed on host3 must be rebuilt with a backup from the primary instance.

❌ 错误。题目中没有提到需要使用备份，且 dba.rebootClusterFromCompleteOutage() 的作用是通过现有实例的数据进行恢复，而非从备份恢复。
如果 host1:3377 是最新实例，则无需备份。

总结

GTID 是 InnoDB Cluster 中判断数据一致性和最新性的关键机制。
GTID_SUBSET() 可用于验证两个 GTID 集合之间的关系，从而确定哪个实例的数据更完整。
选项 C 正确描述了这一过程，是解决问题的合理方法。

MySQL 8.0 OCP 1z0-908 Exam Questions

# MySQL 8.0 OCP 1z0-908 Exam Questions

# 题目 1

# 题目 2

# 题目 3

# 题目 4

# 题目 5

# 题目 6

# 题目 7

# 题目 8

# 题目 9

# 题目 10

# 题目 11

# 题目 12

# 题目 13

# 题目 14

# 题目 15

# 题目 16

# 题目 17

# 题目 18

# 题目 19

# 题目 20

# 题目 21

# 题目 22

# 题目 23

# 题目 24

# 题目 25

# 题目 26

# 题目 27

# 题目 28

# 题目 29

# 题目 30

# 题目 31

# 题目 32

# 题目 33

# 题目 34

# 题目 35

# 题目 36

# 题目 37

# 题目 38

# 题目 39

# 题目 40

# 题目 41

# 题目 42

# 题目 43

# 题目 44

# 题目 45

# 题目 46

# 题目 47

# 题目 48

# 题目 49

# 题目 50

# 题目 51

# 题目 52

# 题目 53

# 题目 54

# 题目 55

# 题目 56

# 题目 57

# 题目 58

# 题目 59

# 题目 60

# 题目 61

# 题目 62

# 题目 63

# 题目 64

# 题目 65

# 题目 66

# 题目 67

# 题目 68

# 题目 69

# 题目 70

# 题目 71

# 题目 72

# 题目 73

# 题目 74

# 题目 75

# 题目 76

# 题目 77

# 题目 78

MySQL 8.0 OCP 1z0-908 Exam Questions

题目 1

题目 2

题目 3

题目 4

题目 5

题目 6

题目 7

题目 8

题目 9

题目 10

题目 11

题目 12

题目 13

题目 14

题目 15

题目 16

题目 17

题目 18

题目 19

题目 20

题目 21

题目 22

题目 23

题目 24

题目 25

题目 26

题目 27

题目 28

题目 29

题目 30

题目 31

题目 32

题目 33

题目 34

题目 35

题目 36

题目 37

题目 38

题目 39

题目 40

题目 41

题目 42

题目 43

题目 44

题目 45

题目 46

题目 47

题目 48

题目 49

题目 50

题目 51

题目 52

题目 53

题目 54

题目 55

题目 56

题目 57

题目 58

题目 59

题目 60

题目 61

题目 62

题目 63

题目 64

题目 65

题目 66

题目 67

题目 68

题目 69

题目 70

题目 71

题目 72

题目 73

题目 74

题目 75

题目 76

题目 77

题目 78

题目 79