（精解版）MySQL8.0 OCP (1Z0-908) 练习题

版权、使用条款与免责声明

本材料中的所有解析内容均为 [sekkoo/https://www.cnblogs.com/sekkoo] 的原创劳动成果。我投入了大量时间和精力来深入分析和解释，旨在帮助学习者更好地理解知识。

为了保护这份劳动成果，并确保其用于正确目的，特此声明以下使用条款：

1. 仅限个人学习使用
本解析内容仅供您个人非商业性学习和研究使用。严禁将本材料用于任何形式的商业目的，包括但不限于出售、出租、广告或作为付费服务的组成部分。

2. 严禁滥用与作弊
本人坚决反对将本材料用于任何形式的作弊行为。我的解析旨在帮助您理解，而不是提供捷径。 任何将本材料用于违反考试规则的行为，都将受到最强烈的谴责。

3. 转载与分享规范
未经本人的明确书面授权，严禁对本解析内容进行任何形式的转载、分发、复制或上传至公共平台。如果您希望分享，请直接分享本内容的原始链接，以尊重版权。

4. 内容来源与免责说明
本材料中的所有题目内容是基于网络社区的公开讨论和匿名贡献进行整理和重构的，不代表任何官方考试内容。所有详细解析均为本材料整理者的独立分析和观点，不代表 Oracle 公司的官方立场。本材料的提供者与 Oracle 公司无任何关联，其内容亦未获得任何授权。

5. 维权与追责
对于任何侵犯本声明的行为，包括但不限于非法复制、商业盗用，我将保留追究法律责任的权利。

通过使用本材料，您即表示同意并遵守以上所有条款。感谢您的理解与支持，希望这些解析能真正帮助您通过考试。

非常感谢评论区@92大佬的细致逐题订正！

如发现内容错误，恳请不吝赐教，以便修正完善。

修正记录：

2025/6/18

修正 Q187 答案为 C，增加 Q187 知识拓展

2025/6/19 非常感谢评论区@92大佬的指正，更改了如下内容：

修改 Q12 答案为 A，更新相关解释
Q19 答案存在其他可能性，请查看评论区
以下为题目解释与扩展方面的修改，不影响答案正确性
Q2 修改扩展知识中的描述为 “从库需要执行主库上的所有已执行的 GTID 事务，才能保持数据一致。”
Q9 增加扩展补充 connection_control_min_connection_delay，connection_control_max_connection_delay
Q11 修正题目中的拼写错误 STAAR改为STAR，选项D翻译修改为【平均读等待时间约为写等待时间的3倍】
Q18 修正了对uncompres的解释，增加了官方文档链接

2025/6/20 非常感谢评论区@92大佬的指正，更改了如下内容：

修改 Q85 答案为 B,C,E，更新相关解释
以下为题目解释与扩展方面的修改，不影响答案正确性
Q27 优化关于选项A的解释
Q33 优化选项E的解释
Q34、Q36 优化选项解释，增加相关知识点解析
Q37 增加选项B的解释
Q55 修改选项B的解释
Q56 修复题干的错误，优化解释
Q95 优化选项B的解释，增加相关知识扩展

2025/6/23 非常感谢评论区@92大佬的指正，更改了如下内容：

Q102 选项内容出现错误，且与Q116题目相同，已删除，以Q116为准。
Q128 修正答案为BE，更新解析
Q183 修正答案为AD,更新解析
Q186 修正答案为A，更新解析
Q202 修正答案为AE，更新解析
Q203 修正答案为AE，更新解析，补充扩展知识
以下为题目解释与扩展方面的修改，不影响答案正确性
Q124 修正 F G的答案对错搞反的错误
Q163 修正解析中关于Set innodb_autoinc_lock_mode to 1.的错误，不是交错模式，是连续模式。

2025/6/26 非常感谢评论区@92大佬的指正，更改了如下内容：

Q57 修正答案为BC。
Q16：修正答案为BD；
Q184 修正答案为A。
Q210 修正答案为AC

2025/06/27 感谢Alex Xiong大佬的指正，更改了如下内容：

Q17 修正对qrti的解释，增加官方文档知识拓展

2025/6/30 非常感谢评论区@92大佬的指正，更改了如下内容：

Q82 修正答案为DF。

2025/07/03 感谢ss大佬的指正，更改了如下内容：

Q12 删除了错误解释

2025/07/05 修改了如下内容：

修正了Q16解析错误
修正了Q164题目错误

2025/07/07 感谢Geng的指正：
1.修正Q173 答案为A
2.修正Q182 答案为E
2025/07/22 ：
1.修正 Q106 答案为D
2.增加 Q140 知识拓展
3.修正 Q142 答案为DE
4.修正 Q201 答案为BF

Q1

英文题目：
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

中文翻译

请查看以下成功执行的命令：

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

以下哪个说法是正确的？
A）备份通过使用已有连接访问MySQL服务器文件。
B）备份期间数据库服务器处于只读状态。
C）备份是InnoDB表的离线备份。
D）备份过程中若执行DDL操作，备份可能会受到影响。

解析

该命令执行的是热备份（online backup），并且包括日志应用。MySQL热备份允许数据库在备份过程中继续运行，但如果有DDL（数据定义语言）操作（如创建或修改表），这些操作可能会影响备份的一致性或完整性，因此备份会受到影响。选项D正确。

选项A错误，因为备份工具通常会建立自己的连接。
选项B错误，服务器不会被置为只读。
选项C错误，备份是在线的，不是离线备份。

从命令行区分 MySQL 备份是热备份还是冷备份

热备份（Hot Backup）

备份时数据库处于运行状态，无需停止服务。
使用 MySQL Enterprise Backup（mysqlbackup）工具时，常用命令如 backup、backup-and-apply-log 等都是热备份操作。
命令不会包含停止 MySQL 服务的步骤。

例如：

mysqlbackup --user=dba --password --backup-dir=/path/to/backup backup-and-apply-log

这是在线备份，数据库仍可访问。

冷备份（Cold Backup）

备份时需要先关闭数据库服务，确保数据文件不被修改。
通常用文件系统级的拷贝命令（如 cp, tar 等）来复制 MySQL 数据文件目录。

命令行中会有先停止 MySQL 服务的步骤，例如：

systemctl stop mysqld
cp -r /var/lib/mysql /backup/mysql_backup
systemctl start mysqld

也就是说，冷备份本质是停机备份，命令行中会明显看到数据库停止的操作。

总结判断方法

如果备份命令是基于 MySQL 服务器仍在运行且无停止服务操作，且用专门备份工具（mysqlbackup 等），则是热备份。
如果备份命令前后出现了停止和启动数据库服务的操作，或者只是简单复制数据文件目录，则是冷备份。

Q2

英文题目：
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_executed: 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 does not have the required transaction with bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb GTIDs in its binary logs.
B) Replication will fail because the master has already purged transactions with cccccccc-cccc-cccc-cccc-cccccccccc GTIDs.
C) Replication will fail because of inconsistent numbers in cccccccc-cccc-cccc-cccc-cccccccccccc GTIDs.
D) Replication will fail because the slave has purged more aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa transactions than the master.
F) Replication will work.

答案： A

中文翻译

你重新配置并启动了一个已经停止复制几天的从服务器。配置文件和 CHANGE MASTER 命令都是正确的。请查看主库和从库的 GTID 信息：

主库：  
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  

从库：  
Gtids_executed: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-160,  
cccccccc-cccc-cccc-cccc-cccccccccccc:1234-1237  

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

以下哪个说法正确？
A）复制会失败，因为主库的二进制日志中没有包含所需的 bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb GTID 事务。
B）复制会失败，因为主库已经清除了 cccccccc-cccc-cccc-cccc-cccccccccc GTID 事务。
C）复制会失败，因为 cccccccc-cccc-cccc-cccc-cccccccccccc GTID 数字不一致。
D）复制会失败，因为从库清除了比主库更多的 aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa 事务。
F）复制会成功。

解析

主库的 bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb GTID 范围是 1-50 已执行，但已经清除了 1-10 的事务。
从库没有 bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb GTID 的记录。
从库的 aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa GTID 范围小于主库的，且主库已经清除了 1-100，从库只执行到 1-70 或 1-160（两组信息）。
cccccccc-cccc-cccc-cccc-cccccccccccc GTID 在主从库范围一致。

关键点是从库执行的 GTID 范围里没有 bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb 的事务，而主库有，并且主库已经清除了一部分事务，可能导致从库需要的事务主库没有了，因此复制会失败。

复制失败的根本原因：主库日志缺失导致从库无法获取所需事务

复制时，从库需要执行主库上的所有尚未执行的 GTID 事务，才能保持数据一致。
这些事务是通过主库的二进制日志（binlog）传输给从库的。
如果主库已经清理（purge）了某些 GTID 事务的二进制日志，而从库还未执行这些事务，复制就会失败。

为什么从库不能简单复制 10-50？

从库需要完整的 GTID 事务序列，即从 1 开始连续执行到 50。
复制是基于事务的连续性和顺序执行的，缺失任何中间事务都会导致数据不一致。
主库已经删除了 1-10 的日志，从库无法获取这部分事务，也就无法执行 1-50 的连续事务序列。
因此，从库无法从主库拉取 1-10 的事务，导致复制卡住或失败。

根据题目解析和 GTID 规则，复制会失败的原因是主库的二进制日志中不包含从库需要的 bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb GTID 事务。

1. GTID（全局事务标识符）概念

GTID 是 MySQL 5.6+ 引入的一种全局唯一标识事务的机制。
每个事务在主库上执行时，都会被赋予一个唯一的 GTID，格式为 server_uuid:transaction_id。
GTID 使得主从复制可以更准确地跟踪哪些事务已经执行，哪些还未执行，简化复制管理。

2. GTID 集合（Sets）

gtids_executed：表示该服务器已经执行过的所有 GTID 事务集合。
gtids_purged：表示该服务器已经清理（purge）掉的 GTID 事务集合，通常是主库已经从二进制日志中删除的事务。

在复制过程中，从库会根据这两个集合判断是否还可以从主库获取所需事务。

3. 主从复制中的 GTID 关系

从库需要执行主库上的所有已执行的 GTID 事务，才能保持数据一致。
复制过程中，从库会从主库的二进制日志中拉取并执行未执行过的事务。
如果主库已经清除了（purge）某些 GTID 事务的二进制日志，而从库还未执行这些事务，则复制会失败，因为从库无法获取缺失的事务。

Q3

英文题目：
Which two authentication plugins require the plain text client plugin for authentication to work?
A) Windows Native authentication
B) PAM authentication
C) LDAP SASL authentication
D) LDAP authentication
E) SHA256 authentication
F) MySQL Native Password

答案： B, D

中文翻译

以下哪两个认证插件需要明文客户端插件才能完成认证？
A）Windows本地认证
B）PAM认证
C）LDAP SASL认证
D）LDAP认证
E）SHA256认证
F）MySQL本地密码认证

解析

PAM认证和LDAP认证需要客户端以明文形式发送密码以完成认证，因此需要明文客户端插件支持。Windows本地认证、LDAP SASL认证、SHA256认证和MySQL本地密码认证不需要。选B和D。

MySQL 认证插件及明文客户端插件需求

MySQL 支持多种认证插件，不同插件的认证机制和密码传输方式不同。理解这些认证插件的工作原理，有助于合理配置安全策略和客户端支持。

1. 认证插件概述

MySQL 认证流程涉及服务器端认证插件和客户端认证插件两部分，客户端插件负责将密码或认证信息发送给服务器，服务器插件负责验证身份。客户端密码传输方式主要有：

明文密码传输：客户端将密码以明文形式发送给服务器，需要客户端支持明文密码插件。
加密或散列传输：客户端发送加密或散列后的密码，提升安全性。
外部认证：认证过程交由操作系统或外部系统完成，客户端不直接发送密码。

2. 各认证插件详细介绍及明文客户端插件需求

认证插件	认证机制简述	是否需要明文客户端插件	说明
A）Windows本地认证	依赖 Windows 操作系统的认证 (SSPI)	否	认证由操作系统完成，客户端不传输明文密码。
B）PAM认证	使用操作系统的 PAM 模块进行认证	是	客户端需发送明文密码，PAM模块验证密码。
C）LDAP SASL认证	通过 SASL 协议与 LDAP 服务器交互认证	否	SASL 支持多种机制，通常非明文密码传输。
D）LDAP认证	传统 LDAP 绑定认证，需要明文密码	是	客户端发送明文密码给 LDAP 服务器验证。
E）SHA256认证	使用 SHA256 加密散列传输密码	否	客户端发送 SHA256 散列值，无明文传输。
F）MySQL本地密码认证	传统 mysql_native_password 认证，挑战-响应机制	否	客户端发送加密密码，非明文密码传输。

3. 明文客户端插件的作用

明文客户端插件允许客户端将密码以明文形式发送给服务器认证插件。
适用于服务器端认证插件无法通过加密机制完成认证的情况。
明文密码传输安全性较低，通常建议加密传输通道（如 SSL/TLS）配合使用。

4. 认证插件工作流程示例

4.1 PAM 认证（需要明文客户端插件）

客户端输入密码，发送明文密码到服务器。
服务器通过 PAM 插件调用操作系统 PAM 模块验证密码。
验证成功后允许登录。

4.2 LDAP 认证（需要明文客户端插件）

客户端发送明文密码。
服务器通过 LDAP 插件将密码发送给 LDAP 服务器进行绑定认证。
LDAP 服务器验证密码后返回结果。

4.3 Windows 本地认证（不需要明文客户端插件）

认证由 Windows 操作系统的安全上下文完成（如 SSPI）。
客户端与服务器使用操作系统安全协议完成身份验证，无需明文密码传输。

5. 配置建议

对于需要明文密码传输的认证插件（如 PAM、LDAP），应确保使用 SSL/TLS 保护传输安全。
优先选择加密认证插件（如 SHA256、mysql_native_password）提升安全性。
外部认证插件（Windows本地认证、PAM）适合与操作系统集成的场景。

Q4

英文题目：
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) error log
B) slow query log
C) general query log
D) binary log
E) audit log

答案： D

中文翻译

你想只记录对数据库对象和数据的更改。默认情况下，哪个日志能做到这一点？
A）错误日志
B）慢查询日志
C）普通查询日志
D）二进制日志
E）审计日志

解析

二进制日志（binary log） 默认记录所有导致数据库对象和数据变化的事件，适合用于复制和恢复。
错误日志（error log） 记录服务器错误和启动、关闭信息，不记录数据变更。
慢查询日志（slow query log） 记录执行时间超过阈值的查询，不限于数据变更。
普通查询日志（general query log） 记录所有客户端发送到服务器的查询，包括读取和写入操作。
审计日志（audit log） 主要用于安全审计，记录用户操作和访问行为，不专注于数据变更。

因此，选项 D（二进制日志）是默认只记录数据库对象和数据更改的日志。

Q5

Question (English)

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      |
+----------------+-----------+

Shell> cd /var/lib/mysql
Shell> ls -1 | 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) Temporary tables are created in tmpdir only if configured to use MyISAM.
B) Temporary tables are created in tmpdir only after they reach tmp_table_size.
C) Temporary tables will use the InnoDB temporary tablespace located in datadir.
D) Only internal temporary tables from the optimizer will be created in tmpdir.
E) Temporary tables will use the InnoDB temporary tablespace located in /tmp.

Answer: C

中文翻译

你在 Oracle Linux 上安装了 MySQL 8，查看以下变量和目录：

Mysql> SHOW GLOBAL VARIABLES 
WHERE Variable_name='tmpdir' 
OR Variable_name='tmp_table_size';

+----------------+-----------+
| Variable_name  | Value     |
+----------------+-----------+
| tmp_table_size | 16777216  |
| tmpdir         | /tmp      |
+----------------+-----------+

Shell> cd /var/lib/mysql
Shell> ls -1 | grep temp
drwxr-x---. 2 mysql mysql 4096 Dec 11 14:05 #innodb_temp

关于磁盘临时表，哪个说法正确？

A）只要配置为 MyISAM，临时表才会创建在 tmpdir 中。
B）临时表只有在达到 tmp_table_size 后才会创建在 tmpdir 中。
C）临时表将使用位于数据目录的 InnoDB 临时表空间。
D）只有优化器内部临时表会创建在 tmpdir 中。
E）临时表将使用位于 /tmp 的 InnoDB 临时表空间。

解析

1. 命令及输出含义

ls -1 | grep temp：列出当前目录下所有包含 "temp" 字符串的文件或文件夹名称。
输出示例：
```
drwxr-x---. 2 mysql mysql 4096 Dec 11 14:05 #innodb_temp
```
该目录是 MySQL 用于存放 InnoDB 临时表空间文件的隐藏目录。

2. MySQL 8 磁盘临时表存储机制

InnoDB 临时表空间
MySQL 8 默认使用 InnoDB 临时表空间（通常位于数据目录下的 #innodb_temp 目录）来存储磁盘临时表。
tmpdir 变量
指定 MySQL 服务的临时文件目录（如排序文件、临时文件），不是磁盘临时表的存储位置。
存储引擎变化
之前版本中磁盘临时表常用 MyISAM 存储引擎，MySQL 8 以后默认改用 InnoDB。

3. 临时表类型

类型	说明
内部临时表（Internal）	由 MySQL 优化器自动创建，用于复杂查询的中间结果。
用户临时表（User-created）	由用户通过 `CREATE TEMPORARY TABLE` 显式创建。

4. 临时表存储位置及引擎

内存临时表
默认使用 MEMORY 存储引擎，受 tmp_table_size 和 max_heap_table_size 限制。
磁盘临时表
当临时表大小超过内存限制，自动转换为磁盘临时表，使用 InnoDB 存储引擎，存储在数据目录的 InnoDB 临时表空间。

5. 选项分析

选项	说明	正确性
A)	只要配置为 MyISAM，临时表才会创建在 tmpdir 中。	错误
B)	临时表只有在达到 tmp_table_size 后才会创建在 tmpdir 中。	错误
C)	临时表将使用位于数据目录的 InnoDB 临时表空间。	正确
D)	只有优化器内部临时表会创建在 tmpdir 中。	错误
E)	临时表将使用位于 /tmp 的 InnoDB 临时表空间。	错误

A 选项错误：MySQL 8 磁盘临时表默认使用 InnoDB，不是 MyISAM，且不在 tmpdir。
B 选项错误：超过 tmp_table_size 后临时表转为磁盘临时表，但不一定存放在 tmpdir。
C 选项正确：磁盘临时表使用数据目录下的 InnoDB 临时表空间（#innodb_temp）。
D 选项错误：用户和内部临时表均使用 InnoDB 临时表空间，不仅仅是优化器内部临时表。
E 选项错误：InnoDB 临时表空间不在 /tmp，而是在数据目录。

6. 相关变量说明

tmp_table_size 和 max_heap_table_size：限制内存临时表最大大小，超过后自动转换为磁盘临时表。
tmpdir：指定 MySQL 服务的临时文件目录，不是临时表存储目录。
#innodb_temp：存放磁盘临时表物理文件的 InnoDB 临时表空间目录。

总结

MySQL 8 磁盘临时表默认使用 InnoDB 存储引擎，存放在数据目录的 InnoDB 临时表空间（如 #innodb_temp）中。
临时表不会直接创建在 tmpdir 目录。
临时表超过内存限制后自动转换为磁盘临时表。
tmpdir 主要用于排序及其他临时文件，不是临时表的存储位置。

Q6

Question (English)

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.

Answer: B, E

中文翻译

以下哪两个措施可以保护 MySQL 服务器免受网络攻击？

A）使用 MySQL Router 代理连接。
B）将 MySQL 实例置于防火墙后面。
C）使用网络文件系统（NFS）存储数据。
D）更改监听端口为 3307。
E）仅允许应用服务器连接。

解析

1. MySQL 服务器面临的网络攻击风险

未授权访问：攻击者试图通过网络连接登录数据库。
中间人攻击（MITM）：截获数据库通信数据。
拒绝服务攻击（DoS/DDoS）：大量请求使数据库服务瘫痪。
暴力破解密码：尝试大量密码组合登录数据库。
数据窃取和篡改：通过网络窃取或修改敏感数据。

2. 选项分析

选项	描述	是否有效防护措施	说明
A)	使用 MySQL Router 代理连接。	否	MySQL Router是MySQL官方提供的中间件，用于实现连接路由、负载均衡和高可用，但它本身并不直接增强网络安全防护。它并不会阻止恶意访问或过滤不安全的连接。它更多是连接管理和性能优化的工具，而非防御网络攻击的安全措施。
B)	将 MySQL 实例置于防火墙后面。	是	防火墙限制访问端口的 IP，阻止未授权访问，是基础且关键措施。
C)	使用网络文件系统（NFS）存储数据。	否	NFS 是存储方案，与网络攻击防护无关，且可能带来额外安全风险。
D)	更改监听端口为 3307。	否	端口更改只是安全模糊，不能有效防止攻击。
E)	仅允许应用服务器连接。	是	限制允许连接的客户端 IP，是严格访问控制，有效防止非法访问。

3. 推荐的防护措施

3.1 使用防火墙保护数据库服务器（选项 B）

配置防火墙只允许可信 IP 或子网访问 MySQL 默认端口（3306）。
阻止所有其他未经授权的网络访问请求。
可结合操作系统防火墙（iptables、firewalld）或硬件防火墙使用。

3.2 限制连接来源（选项 E）

只允许应用服务器或特定主机连接数据库。
在 MySQL 用户权限中绑定特定 IP 或主机名。
减少暴露面，防止外部攻击尝试连接。

4. 其他安全建议

启用 SSL/TLS 加密，防止中间人攻击。
使用强密码和账户管理，限制权限。
审计和日志监控，及时发现异常。
定期更新和补丁修复漏洞。
禁用远程 root 登录，避免超级用户被攻击。

5. 不推荐措施

仅更改监听端口（选项 D）：安全通过模糊，效果有限。
使用 NFS 存储（选项 C）：与网络安全无关，可能引入文件系统安全隐患。

总结

推荐措施	说明
使用防火墙（B）	阻止未授权网络访问，基础安全措施。
限制连接来源（E）	仅允许可信主机访问，减少攻击面。

结合使用，能显著提升 MySQL 服务器的网络安全防护能力。

Q7

Question (English)

Examine the command, which executes successfully:

mysqld --initialize-insecure

Which statement is true?

A) The installation creates a temporary test environment with data in the /tmp directory.
B) The installation is created without enforcing or generating SSL certificates.
C) The root password is created in the error log in plain text.
D) The root password is not created allowing easy access from the same host.

Answer: D

中文翻译

请查看成功执行的命令：

mysqld --initialize-insecure

以下哪个说法正确？

A）安装创建了一个位于 /tmp 目录的临时测试环境。
B）安装时不强制生成或使用 SSL 证书。
C）root 密码以明文形式写入错误日志。
D）未创建 root 密码，允许同一主机轻松访问。

解析

--initialize-insecure 选项用于初始化 MySQL 数据目录时，不为 root 用户设置密码。
结果是 root 账户无密码，允许本地主机无密码访问数据库。
选项 D 正确。

选项分析

选项	说明	正确性
A)	安装创建临时测试环境，数据在 /tmp 目录。	错误
B)	安装时不强制生成或使用 SSL 证书。	部分正确，但非重点。
C)	root 密码以明文写入错误日志。	错误，密码未生成。
D)	未创建 root 密码，允许同一主机无密码访问。	正确

MySQL 初始化命令详解

1. `mysqld --initialize`

初始化 MySQL 数据目录。
创建系统表和必要文件。
自动为 root 用户生成随机密码，密码以明文写入错误日志。
更安全，适合生产环境。

示例：

mysqld --initialize

2. `mysqld --initialize-insecure`

初始化 MySQL 数据目录。
创建系统表和必要文件。
不为 root 用户创建密码，允许无密码访问（通常仅限本地主机）。
存在安全风险，适合开发或测试环境。
初始化后应尽快设置 root 密码。

示例：

mysqld --initialize-insecure

其他相关知识点

数据目录位置
默认数据目录由配置文件（如 my.cnf）指定，通常不在 /tmp。
可通过 --datadir 参数指定数据目录。
SSL 证书
初始化过程不涉及 SSL 证书的生成或强制使用。
SSL 配置需单独完成，如通过配置文件或手动生成证书。

安全建议

生产环境推荐使用 --initialize，确保 root 密码安全。
开发环境可用 --initialize-insecure，但应尽快设置密码。
初始化完成后务必检查并修改 root 密码。

参考命令示例

# 初始化（无密码）
mysqld --initialize-insecure

# 初始化（有随机密码）
mysqld --initialize

# 查看错误日志（默认位置可能为 /var/log/mysqld.log 或 /var/log/mysql/error.log）
cat /var/log/mysqld.log

# 启动 MySQL 服务
systemctl start mysqld

# 登录 MySQL（无密码）
mysql -u root

# 登录 MySQL（有密码）
mysql -u root -p

Q8

Question (English)

Examine this command:

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 TABLE statements.
D) It will not write CREATE DATABASE statements.

Answer: C

中文翻译

请查看以下命令：

mysqldump --no-create-info --all-databases --result-file=dump.sql

以下哪个说法正确？

A）不会写入 CREATE TABLESPACE 语句。
B）不会写入 CREATE LOGFILE GROUP 语句。
C）不会写入 CREATE TABLE 语句。
D）不会写入 CREATE DATABASE 语句。

解析

--no-create-info 参数告诉 mysqldump 不导出表结构（即不导出 CREATE TABLE 语句），只导出数据的 INSERT 语句。
选项 C 正确。
选项 A、B、D 不是 --no-create-info 的作用。

1. mysqldump 工具简介

mysqldump 是 MySQL 官方的逻辑备份工具，可以导出数据库结构和数据。
导出结果通常是 SQL 脚本文件，包含创建数据库、表、索引及插入数据的语句。

2. 关键参数说明

参数	含义	适用场景
`--no-create-info`	不导出表结构的 `CREATE TABLE` 语句，只导出数据的 `INSERT` 语句。	仅需备份数据，表结构已知时使用。
`--no-create-db`	不导出 `CREATE DATABASE` 语句。	已有数据库环境时避免重复创建数据库。
`--all-databases`	导出所有数据库。	全库备份。
`--result-file=filename`	将导出内容写入指定文件。	方便备份文件管理。

3. mysqldump 导出内容详解

默认行为：
- 导出数据库创建语句 (CREATE DATABASE)
- 导出表结构 (CREATE TABLE)
- 导出数据 (INSERT)
- 不导出表空间 (CREATE TABLESPACE) 和日志文件组 (CREATE LOGFILE GROUP)，除非特殊配置。
使用 --no-create-info：
- 不导出 CREATE TABLE 语句。
- 仍导出 CREATE DATABASE 语句（除非加 --no-create-db）。
- 仅导出数据行的插入语句。

4. 其他相关知识点

表空间和日志文件组语句
CREATE TABLESPACE 和 CREATE LOGFILE GROUP 是 InnoDB 存储引擎相关的高级结构定义。
这些语句通常不会由 mysqldump 导出，需使用物理备份工具如 MySQL Enterprise Backup。
备份策略
- 逻辑备份（mysqldump）：方便迁移和查看，适合小型或中型数据库，速度较慢。
- 物理备份（物理文件复制或专用备份工具）：速度快，适合大型数据库，可能需停机或热备。
恢复注意事项
- 仅导入数据时，确保目标库结构完全匹配。
- 包含数据库和表结构时，导入 SQL 脚本可自动创建。

5. 小结

参数	导出内容	适用场景
默认	数据库、表结构、数据	完整备份
`--no-create-info`	仅导出数据插入语句，不导出表结构	仅备份数据，结构已存在时使用
`--no-create-db`	不导出数据库创建语句	已有数据库环境时使用
`--all-databases`	导出所有数据库	全库备份

Q9

Question (English)

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) The minimum connection value is changed to 2000.
B) Only the minimum connection value is increased to 3000.
C) The minimum value increases to 3000 and the maximum value increases to 4000.
D) An error is returned.

Answer: D

中文翻译

mysqld 实例启用了连接控制插件，配置如下：

Connection_control_min_connection_delay=1000  
Connection_control_max_connection_delay=2000

需要将最小和最大连接延迟分别增加到 3000 和 5000。执行命令：

Mysql> SET GLOBAL connection_control_min_connection_delay=3000;

结果是什么？

A）最小连接延迟变为 2000。
B）只有最小连接延迟变为 3000。
C）最小连接延迟变为 3000，最大连接延迟变为 4000。
D）返回错误。

解析

连接控制插件用于限制客户端连接延迟，防止连接风暴。
参数依赖关系：connection_control_min_connection_delay 必须小于或等于 connection_control_max_connection_delay。
当尝试单独设置最小连接延迟为 3000 时，如果最大延迟仍为 2000，违反了参数依赖关系。
这种情况下，MySQL 会返回错误，拒绝修改。
因此，选项 D 正确。

MySQL 连接控制插件相关知识点

知识点	说明
连接控制插件参数	用于限制客户端连接延迟，防止连接风暴。
参数依赖关系	`min_connection_delay` 必须 ≤ `max_connection_delay`。
动态修改参数行为	修改最小连接延迟时，如果超过最大连接延迟，设置失败并返回错误。
SET GLOBAL 命令	用于动态设置全局系统变量，部分插件参数支持动态修改。

总结

操作	结果
单独设置 `min_connection_delay` > 现有最大延迟	返回错误，修改失败
同时调整 `max_connection_delay` 和 `min_connection_delay`	设置成功

CONNECTION_CONTROL 插件相关系统变量与工作机制

https://dev.mysql.com/doc/refman/8.0/en/connection-control-plugin-installation.html

MySQL 的 CONNECTION_CONTROL 插件通过以下系统变量允许管理员配置登录失败后的连接行为，旨在防止暴力破解等安全风险：

connection_control_failed_connections_threshold
- 作用：允许账户在无延迟的情况下连续失败的最大连接尝试次数。
- 若设置为 0，则关闭失败连接计数，不进行延迟处理。
connection_control_min_connection_delay
- 作用：设置触发延迟后，实际等待时间的最小毫秒值。
connection_control_max_connection_delay
- 作用：设置触发延迟后，实际等待时间的最大毫秒值。

工作原理分段说明

只要 connection_control_failed_connections_threshold 非零（即启用），系统会对每一账户连续失败的登录次数进行计数。
在失败次数未达到该阈值之前，不会有延迟。
达到阈值后，服务器对后续连接（连续失败）请求施加递增延迟——每失败一次，延迟增加 1000 毫秒（如，第一次触发为 1000ms，第二次 2000ms，第三次 3000ms...）。
实际客户端感受到的延迟，会根据 connection_control_min_connection_delay 和 connection_control_max_connection_delay 限定在合理范围内（即不会低于 minimum，也不会高于 maximum）。
一旦账户登录成功，不仅首次成功登录也需要经过延迟，之后再尝试将重新计数，延迟归零。

Q10

Question (English)

You must export data from a set of tables in the world_x database. Examine this set of tables: (country, countryinfo, location).

Which two options will export data into one or more files?

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';

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;

mysqlexport world_x country countryinfo location > mydump.sql

mysql --batch world_x.country world_x.countryinfo world_x.location > mydump.sql

mysqldump world_x country countryinfo location > mydump.sql

Answer: B, E

中文翻译

你必须导出 world_x 数据库中一组表的数据，包括 country、countryinfo 和 location。

以下哪两个选项可以将数据导出到一个或多个文件？

A）

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';

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）

mysqlexport world_x country countryinfo location > mydump.sql

D）

mysql --batch world_x.country world_x.countryinfo world_x.location > mydump.sql

E）

mysqldump world_x country countryinfo location > mydump.sql

解析

选项	内容	结果说明
A	`CLONE LOCAL DATA DIRECTORY` 命令	错误，`CLONE` 命令用于复制实例或数据目录，不是导出数据的标准命令。
B	`SELECT ... INTO OUTFILE` 导出单表数据	正确，将单表数据导出为服务器文件，单表导出。
C	`mysqlexport` 命令	错误，`mysqlexport` 不是标准 MySQL 命令或工具。
D	`mysql --batch` 直接指定多个表参数	错误，`mysql` 客户端不支持直接指定多个表作为参数导出数据。
E	`mysqldump` 导出多个表结构和数据	正确，`mysqldump` 支持导出指定数据库的多个表数据和结构。

MySQL 导出相关知识点

知识点	说明
`SELECT ... INTO OUTFILE`	SQL 语句，导出单表数据到服务器上的文件，文件格式通常为文本。需有写权限。
`mysqldump`	MySQL 官方逻辑备份工具，支持导出数据库、表结构及数据，支持指定多个表导出。
`CLONE LOCAL DATA DIRECTORY`	MySQL 8.0+ 的复制数据目录命令，不用于导出逻辑数据。
`mysql` 客户端	主要用于执行查询和交互，不支持直接导出多个表数据到文件。
导出文件权限与路径	`INTO OUTFILE` 导出文件路径必须是 MySQL 服务器的文件系统路径，且 MySQL 进程需有写权限。

小结

选项 B 使用 SELECT ... INTO OUTFILE 导出单表数据到文本文件。
选项 E 使用 mysqldump 导出多个表的结构和数据到 SQL 文件。
其他选项均不符合标准导出操作。

Q11

Question (English)

Examine this command and output:

Mysql> SELECT * 
FROM performance_schema.table_io_waits_summary_by_table 
WHERE COUNT_STAR > 0 \G

Output snippet:

OBJECT_TYPE: TABLE
OBJECT_SCHEMA: test
OBJECT_NAME: demo_test
COUNT_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 are true?

A) The longest I/O wait was for writes.
B) I/O distribution is approximately 50/50 read/write.
C) 22,902,028 rows were deleted.
D) Average read times are approximately three times faster than writes.
E) The I/O average time is 532,728.

Answer: C, D

中文翻译

请查看以下命令和输出，判断以下哪两项正确：

A）最长的 I/O 等待是写操作。
B）I/O 读写比例约为 50/50。
C）删除了 22902028 行。
D）平均读取时间大约比写入快三倍。
E）I/O 平均时间是 532,728。

解析

字段名	说明	示例值
COUNT_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
AVG_TIMER_READ	读操作平均等待时间	532728
COUNT_WRITE	写操作次数	22902028
SUM_TIMER_WRITE	写操作总等待时间	38410287610743
AVG_TIMER_WRITE	写操作平均等待时间	1677006
COUNT_DELETE	删除操作次数	22902028

选项分析

A) 最长 I/O 等待是写操作
- MAX_TIMER_WRITE = 17,205,682,920
- MAX_TIMER_READ = 558,852,005,358
- 读操作最长等待时间远大于写操作，故 A 错误。
B) I/O 读写比例约为 50/50
- COUNT_READ = 38,665,056
- COUNT_WRITE = 22,902,028
- 读操作明显多于写操作，比例约为 63% 读，37% 写，故 B 错误。
C) 删除操作次数为 22,902,028 行
- COUNT_DELETE = 22,902,028，与写操作次数相同，表明删除操作数量，C 正确（但有少许不确定）。
D) 平均读取时间大约比写入快三倍
- AVG_TIMER_READ = 532,728
- AVG_TIMER_WRITE = 1,677,006
- 计算比值约为 3.15，D 正确。
E) I/O 平均时间是 532,728
- AVG_TIMER_WAIT = 958,095（整体平均）
- 532,728 是读等待平均时间，不是整体平均时间，E 错误。

知识点	说明
performance_schema	MySQL 内置性能监控，统计表级别的 I/O 等待次数、等待时间等信息。
COUNT_*	对应操作的次数，如读、写、删除操作次数。
SUM_TIMER_*	对应操作的总等待时间，单位纳秒。
AVG_TIMER_*	平均等待时间 = 总等待时间 / 操作次数。
MAX_TIMER_*	单次最长等待时间。
I/O 性能分析	通过比较读写等待时间和次数，分析数据库负载和性能瓶颈。

table_io_waits_summary_by_table 表

https://dev.mysql.com/doc/refman/8.0/en/performance-schema-table-wait-summary-tables.html#performance-schema-table-io-waits-summary-by-table-table

1. 表的作用与来源

table_io_waits_summary_by_table 是 Performance Schema 中用于汇总表级别 I/O 等待事件的统计表。

这些等待事件来源于 MySQL 内部的 wait/io/table/sql/handler 监控器，这个监控器追踪与表相关的 I/O 操作等待情况。
该表将所有 I/O 操作（包括读、写和其他细分操作）按表进行聚合统计，方便用户了解每个表的 I/O 负载和性能瓶颈。

2. 分组字段（聚合维度）

该表的统计是基于以下三个字段进行分组的：

OBJECT_TYPE：对象类型，通常是 'TABLE'，表示表对象。
OBJECT_SCHEMA：数据库（模式）名称，表示该表所属的数据库。
OBJECT_NAME：表名，表示具体的表。
这三个字段结合唯一标识了一个具体的表。

3. 统计字段分类与含义

表中包含大量计数和时间统计字段，按操作类型和统计粒度分组，主要包括以下几类：

3.1 总体 I/O 操作统计

COUNT_STAR：总的 I/O 操作次数，等于所有读写操作次数之和。
SUM_TIMER_WAIT：所有 I/O 操作等待时间总和，单位为皮秒（ps）。
MIN_TIMER_WAIT：所有 I/O 操作等待的最短时间。
AVG_TIMER_WAIT：所有 I/O 操作平均等待时间。
MAX_TIMER_WAIT：所有 I/O 操作等待的最长时间。
这些字段汇总了该表的整体 I/O 等待情况。

3.2 读操作统计

COUNT_READ：所有读操作次数总和。
SUM_TIMER_READ、MIN_TIMER_READ、AVG_TIMER_READ、MAX_TIMER_READ：对应读操作等待时间的总和、最小、平均和最大值。
这些统计是所有“取数据”操作（fetch）次数和时间的汇总。

3.3 写操作统计

COUNT_WRITE：所有写操作次数总和。
SUM_TIMER_WRITE、MIN_TIMER_WRITE、AVG_TIMER_WRITE、MAX_TIMER_WRITE：对应写操作等待时间的总和、最小、平均和最大值。
写操作包括插入（insert）、更新（update）和删除（delete），这些字段的值是对应三个操作的统计值的加总。

3.4 具体细分操作统计

取数据（Fetch）
- COUNT_FETCH：取数据操作的次数。
- 相关时间统计同上。
插入（Insert）
- COUNT_INSERT：插入操作次数。
- 相关时间统计。
更新（Update）
- COUNT_UPDATE：更新操作次数。
- 相关时间统计。
删除（Delete）
- COUNT_DELETE：删除操作次数。
- 相关时间统计。
  这些细分字段帮助用户深入分析不同类型的 I/O 操作在表上的等待和性能表现。

4. 索引结构

表对 (OBJECT_TYPE, OBJECT_SCHEMA, OBJECT_NAME) 三列建立了唯一索引。
该索引保证每个表的统计信息唯一，方便快速查询对应表的 I/O 等待统计。

5. 表的维护与清理

允许使用 TRUNCATE TABLE 命令清空该表。
但该命令并非删除所有行，而是将所有统计字段（计数和时间）重置为零，保持行结构不变。
同时，执行此命令也会清空 table_io_waits_summary_by_index_usage 表中的统计数据，保证两表统计同步重置。

6. 使用价值

该表用于性能监控和诊断，帮助数据库管理员和开发者了解每个表的 I/O 负载情况。
通过统计等待时间和次数，可以识别出 I/O 瓶颈的表，针对性地优化索引、查询或存储引擎配置。
细分的插入、更新、删除和取数据操作统计，能帮助定位具体哪类操作导致性能问题。

小结

table_io_waits_summary_by_table 是 MySQL Performance Schema 中极其重要的表级 I/O 性能统计表，提供了细粒度的读写等待统计，可用于深入分析数据库表的性能瓶颈，支持数据库运维和优化工作。

总结

选项 C 和 D 是正确的。
选项 A、B、E 是错误的。

Q12

Question (English)

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 MySQL Server, then run:

mysqlbackup --datadir=/var/lib/mysql --backup-dir=/dbbackup --include-tables='Company\.Customers' copy-back

Start the mysqld process.

B) Stop MySQL Server and restart with:

mysqld --basedir=/usr/local/mysql --datadir=/var/lib/mysql

Run mysqldump on the table and restore the dump.

C) Stop MySQL Server and restart with:

mysqld --basedir=/usr/local/mysql --datadir=/dbbackup

Run mysqldump on the table and restore the dump.

D) Stop MySQL Server, copy Customers.ibd from the dbbackup directory, and start mysqld.

Answer: A

中文翻译

开发人员不小心删除了 Company 数据库中的 InnoDB 表 Customers。dbbackup 目录中有两天前的物理数据目录备份。

以下哪组步骤可以恢复仅丢失的表？

A）停止 MySQL 服务器，执行：

mysqlbackup --datadir=/var/lib/mysql --backup-dir=/dbbackup --include-tables='Company\.Customers' copy-back

然后启动 mysqld。

B）停止 MySQL 服务器，用以下命令重启：

mysqld --basedir=/usr/local/mysql --datadir=/var/lib/mysql

对该表运行 mysqldump 并恢复。

C）停止 MySQL 服务器，用以下命令重启：

mysqld --basedir=/usr/local/mysql --datadir=/dbbackup

对该表运行 mysqldump 并恢复到正常数据目录。

D）停止 MySQL 服务器，复制 dbbackup 目录中的 Customers.ibd 文件，启动 mysqld。

解析

选项	说明	适用性与风险
A	使用 `mysqlbackup` 工具按表恢复备份数据目录中的指定表。	利用 mysqlbackup 工具，仅恢复备份目录中的指定表（只恢复 Customers 表），且自动处理 InnoDB 所需的元数据和文件，非常适合针对单表恢复。
B	启动正常数据目录的 MySQL 实例，导出该表再恢复。	表已丢失，正常目录无该表，无法导出。
C	启动备份目录的 MySQL 实例，导出该表再导入正常实例。	可行，但需要重启两次 MySQL，步骤略繁琐。
D	直接复制 `.ibd` 文件恢复。	风险大，缺少元数据同步，易导致数据不一致，不推荐。

A）和C）都能实现恢复，但A更高效、标准化。

因此，正确答案是：A

MySQL 备份恢复相关知识点

物理备份
- 直接复制数据目录文件（如 .ibd、.frm）。恢复灵活性低，风险较高。
逻辑备份
- 使用 mysqldump 导出 SQL 语句，恢复时执行导入，适合单表恢复。
企业备份工具（MySQL Enterprise Backup）
- 支持增量备份、按表恢复等高级功能，适合生产环境。
InnoDB 表恢复
- 仅复制 .ibd 文件无法保证表完整性，需同步元数据和数据字典。
- 推荐通过备份实例启动导出，再导入正常实例。

备份方法	热/温/冷备份	支持存储引擎	逻辑/物理	是否一致	获取途径
MySQL Enterprise Backup	热（InnoDB）/温（其他）	全部	物理备份	是	商业版（需付费购买）
mysqldump 或 mysqlpump	热（InnoDB）/温（其他）	全部	逻辑备份	是	免费获取
快照（Snapshots）	热备份	全部	物理备份	是	需快照卷/文件系统支持
复制（Replication）	热备份	全部	逻辑或物理	是	免费获取
SQL语句（SQL Statements）	温备份	全部	逻辑备份	否	免费获取
操作系统复制命令	冷或温备份	全部	物理备份	是	免费获取

恢复操作建议

停止 MySQL 服务器。
使用备份目录启动一个 MySQL 实例（mysqld --datadir=/dbbackup）。
通过 mysqldump 导出 Customers 表数据。
在正常数据库实例中导入该数据。

Q13

Question (English)

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 update the database tables.
B) It can be piped into the MySQL Server via the command-line client.
C) You must use --stop-position=1797 to avoid the DELETE statement that caused the initial problem.
D) No changes required. It automatically updates the MySQL Server with the data.

Answer: B

中文翻译

你的 MySQL 数据库中数据被意外删除。
你确定需要重放二进制日志文件中位置1797之后的所有条目。请查看以下命令片段：

mysqlbinlog binlog.000008 --start-position=1798

哪个操作将完成该命令？

A）必须添加 --write-to-remote-server 参数以更新数据库表。
B）可以通过命令行客户端将输出管道传递到 MySQL 服务器。
C）必须使用 --stop-position=1797 避免导致问题的 DELETE 语句。
D）不需要更改，命令会自动更新 MySQL 服务器数据。

解析

A) 参数 --write-to-remote-server 并不存在于 mysqlbinlog 命令，排除。
B) mysqlbinlog 只是将二进制日志转换成可执行的 SQL 语句文本，需通过管道传给 mysql 客户端执行：
```
mysqlbinlog binlog.000008 --start-position=1798 | mysql -u user -p
```
这是恢复数据的常用方式，正确。
C) --stop-position=1797 表示只执行到位置1797，题目要求执行1797之后的日志，故与需求相反，错误。
D) mysqlbinlog 不会自动执行 SQL，只输出文本，需配合客户端执行，错误。

MySQL 二进制日志与恢复操作知识点

知识点	说明
二进制日志	记录所有修改数据的操作（INSERT、UPDATE、DELETE等），用于复制和数据恢复。
`mysqlbinlog` 工具	将二进制日志转换成 SQL 文本，支持按位置和时间过滤，但不自动执行。
恢复流程	1. 确定恢复区间；2. 导出日志 SQL；3. 通过管道或文件导入执行；4. 验证恢复结果。
常用参数	`--start-position`、`--stop-position`、`--start-datetime`、`--stop-datetime`。
恢复误删数据关键点	选择正确起点，排除误删操作（编辑日志 SQL），避免重复误删。

恢复示例命令

# 直接回放日志中1798之后的内容
mysqlbinlog binlog.000008 --start-position=1798 | mysql -u root -p

# 或先导出为文件，人工编辑后执行
mysqlbinlog binlog.000008 --start-position=1798 > recovery.sql
mysql -u root -p < recovery.sql

总结

mysqlbinlog 不自动执行日志，需结合 mysql 客户端执行。
通过管道方式是恢复误删数据的常用且简便方法。
注意选择正确日志起点，避免误删操作重新执行。
误删恢复通常结合备份和日志回放完成。

Q14

Question (English)

Table t is an InnoDB table. Examine these statements and outputs:

SELECT count(1) FROM t;
+----------+
| count(1) |
+----------+
|       72 |
+----------+

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 rows 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.

Answer: C, D

中文翻译

表 t 是 InnoDB 表。请查看以下语句和输出：

表中共有 72 行。
有两个索引：
- 主键索引 PRIMARY，列 a，唯一，基数 72，可见。
- 辅助索引 b_idx，列 b，非唯一，基数 1，不可见。

以下哪两个说法正确？

A）ANALYZE TABLE t 会“唯一地”更新 PRIMARY 索引的统计信息。
B）表 t 有两个可用索引可用于查询。
C）执行 SELECT b FROM t 会进行表扫描。
D）索引 b_idx 的唯一值数量较低。
E）执行 SELECT a FROM t 会进行表扫描。

解析

A)
- ANALYZE TABLE 会更新所有可见索引的统计信息。
- b_idx 是不可见索引（Visible=NO），不会更新统计信息。
- 但说“唯一地”只更新 PRIMARY 索引不准确，故选项错误。
B)
- b_idx 不可见，查询优化器不会使用。
- 只有 PRIMARY 索引可用，故选项错误。
C)
- 查询 SELECT b FROM t，索引 b_idx 不可见且基数为1，优化器不会用索引。
- 只能进行全表扫描，选项正确。
D)
- b_idx 基数为1，说明索引列 b 唯一值极少，索引选择性差。
- 选项正确。
E)
- a 是主键索引列且唯一，索引可用。
- 查询 SELECT a FROM t 可以用索引，不需全表扫描，选项错误。

知识点	说明
主键索引 PRIMARY	InnoDB 聚簇索引，数据存储按主键排序，基数高代表唯一性强，优化器优先使用。
辅助索引 Secondary	存储索引列和主键列组合，用于加速非主键列查询。
索引可见性	MySQL 8.0 支持索引可见性，不可见索引不参与查询优化，也不更新统计信息。
基数 Cardinality	估计索引列唯一值数量，基数高索引选择性好，基数低索引选择性差，可能不被使用。
查询优化	优化器基于索引可见性和基数选择最优执行计划，低基数或不可见索引一般不被使用。

ANALYZE TABLE 语句

1. 语法概述

ANALYZE [NO_WRITE_TO_BINLOG | LOCAL]
    TABLE tbl_name [, tbl_name] ...

ANALYZE [NO_WRITE_TO_BINLOG | LOCAL]
    TABLE tbl_name
    UPDATE HISTOGRAM ON col_name [, col_name] ...
        [WITH N BUCKETS]

ANALYZE [NO_WRITE_TO_BINLOG | LOCAL] 
    TABLE tbl_name
    UPDATE HISTOGRAM ON col_name [USING DATA 'json_data']

ANALYZE [NO_WRITE_TO_BINLOG | LOCAL]
    TABLE tbl_name
    DROP HISTOGRAM ON col_name [, col_name] ...

ANALYZE TABLE 用于生成表统计信息。
不带 HISTOGRAM 子句时，进行键分布分析（key distribution analysis）。
带 UPDATE HISTOGRAM 子句时，为指定列生成直方图统计，并存储在数据字典中。
带 DROP HISTOGRAM 子句时，删除指定列的直方图统计。
NO_WRITE_TO_BINLOG 或 LOCAL 用于控制是否写入二进制日志。

2. 权限要求

需要对表具有 SELECT 和 INSERT 权限。

3. 支持的存储引擎和限制

支持 InnoDB、NDB 和 MyISAM 表。
不支持视图（views）。
如果启用了 innodb_read_only，可能无法更新数据字典中的统计信息，导致 ANALYZE TABLE 失败。
支持分区表，可使用 ALTER TABLE ... ANALYZE PARTITION 分析指定分区。
执行时，InnoDB 和 MyISAM 表会加读锁。
默认会将 ANALYZE TABLE 语句写入二进制日志以支持复制，使用 NO_WRITE_TO_BINLOG 或 LOCAL 可禁止写入。

4. 输出结果

执行 ANALYZE TABLE 会返回结果集，包含以下字段：

列名	含义
Table	表名
Op	操作类型，如 analyze 或 histogram
Msg_type	信息类型，如 status、error、note 等
Msg_text	信息内容

5. 键分布分析（Key Distribution Analysis）

不带 HISTOGRAM 子句时执行键分布分析，更新表的键分布统计。
如果表自上次分析后未发生变化，则不会重复分析。
键分布用于优化器决定表连接顺序及索引使用。
可通过 SHOW INDEX 或 INFORMATION_SCHEMA.STATISTICS 查看键分布基数。
InnoDB 通过随机采样索引树估算基数，速度快但非完全准确。
启用 innodb_stats_persistent 可使统计更准确和稳定，但需在数据变更后手动运行 ANALYZE TABLE。
可以调整采样页数的系统变量为 innodb_stats_persistent_sample_pages 或 innodb_stats_transient_sample_pages。
如果连接优化不理想，可尝试运行 ANALYZE TABLE 或使用 FORCE INDEX。

6. 直方图统计分析（Histogram Statistics Analysis）

UPDATE HISTOGRAM 子句用于生成指定列的直方图统计，存储于数据字典。
只允许指定一个表名。
可通过 WITH N BUCKETS 指定桶的数量（1~1024），默认100桶。
支持删除指定列的直方图统计（DROP HISTOGRAM）。
也支持用 JSON 数据显式设置某一列的直方图（MySQL 8.0.31+）。
直方图统计不支持加密表和临时表。
支持除空间类型（geometry）和 JSON 外的所有数据类型的列，包括存储和虚拟生成列。
不支持为单列唯一索引覆盖的列生成直方图。
对无效列或不支持的列会跳过并输出诊断信息。

7. 直方图与 DDL 语句的关系

DROP TABLE 会删除对应表的所有直方图。
DROP DATABASE 删除该数据库所有表的直方图。
RENAME TABLE 会重命名直方图关联的表名。
ALTER TABLE 删除或修改列时，会删除对应列的直方图。
ALTER TABLE ... CONVERT TO CHARACTER SET 会删除字符列的直方图，非字符列不受影响。

8. 直方图生成的内存与采样

系统变量 histogram_generation_max_mem_size 控制生成直方图时可用的最大内存。
超过内存限制时，MySQL 使用系统采样（SYSTEM sampling），即页面级采样，均匀分布于整个表。
采样率（sampling-rate）可通过 INFORMATION_SCHEMA.COLUMN_STATISTICS 表中的 HISTOGRAM 字段查看，范围 0~1，1 表示全表扫描。
InnoDB 从 8.0.19 起提供专门的采样实现，避免全表扫描提升性能。
可通过启用 innodb_monitor_enable='sampled%' 并查询 INNODB_METRICS 表监控采样计数。
采样率可通过采样计数计算，约等于采样页面读取数除以（读取数+跳过数）。

9. 其他注意事项

生成直方图会使用 Performance Schema 的 memory/sql/histograms 监控内存使用。
ANALYZE TABLE 会清除 INFORMATION_SCHEMA.INNODB_TABLESTATS 中的统计数据，将 STATS_INITIALIZED 置为未初始化状态，下一次访问表时重新收集统计。

小结

ANALYZE TABLE 语句是 MySQL 优化器统计信息维护的核心命令，支持键分布和直方图两种统计方式，帮助优化器做出更准确的执行计划。合理使用该命令可以显著提升查询性能和执行效率。

总结

选项	结论
A	错误：更新所有可见索引统计信息
B	错误：不可见索引不可用
C	正确：查询列 b 需全表扫描
D	正确：索引 b_idx 唯一值少
E	错误：查询列 a 可用主键索引

Q15

Question (English)

You are using the InnoDB engine and the innodb_file_per_table option is set. You delete a significant number of rows from 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.INVENTORY
B) ANALYZE TABLE FACTORY.INVENTORY
C) OPTIMIZE TABLE FACTORY.INVENTORY
D) mysqlcheck -u root -p FACTORY.INVENTORY
E) mysqldump -u root -p FACTORY INVENTORY

Answer: C

中文翻译

你使用 InnoDB 引擎且启用了 innodb_file_per_table 选项，删除了 FACTORY.INVENTORY 表中大量行。
以下哪个命令会重新整理该表的数据和索引的物理存储，从而减少存储空间并提升 I/O 效率？

A）CHECK TABLE FACTORY.INVENTORY
B）ANALYZE TABLE FACTORY.INVENTORY
C）OPTIMIZE TABLE FACTORY.INVENTORY
D）mysqlcheck -u root -p FACTORY.INVENTORY
E）mysqldump -u root -p FACTORY INVENTORY

解析

背景说明

删除大量数据后，InnoDB 表空间（.ibd 文件）不会自动缩小，导致磁盘空间浪费。
需要执行操作整理表空间，回收未使用空间，提高 I/O 性能。

各选项分析

选项	作用说明	是否能回收空间
A	检查表的完整性和一致性，不整理空间。	否
B	更新表和索引的统计信息，辅助优化器选择查询计划，不回收空间。	否
C	重建表和索引，整理碎片，回收空间。对启用 `innodb_file_per_table` 的表，能缩小 .ibd 文件。	是，推荐用于回收空间
D	`mysqlcheck` 默认执行检查，除非带 `--optimize` 参数，否则不回收空间。	否（默认检查）
E	`mysqldump` 导出并重新导入表，间接整理空间，但步骤复杂，不是直接命令。	是（间接且繁琐）

1. 语法概述

OPTIMIZE [NO_WRITE_TO_BINLOG | LOCAL]
    TABLE tbl_name [, tbl_name] ...

OPTIMIZE TABLE 用于重组表数据和索引的物理存储，减少存储空间并提高 I/O 访问效率。
具体操作取决于表所使用的存储引擎。

2. 适用场景

对启用了 innodb_file_per_table 选项的 InnoDB 表，执行大量插入、更新或删除后，使用 OPTIMIZE TABLE 可重组表和索引，回收磁盘空间。
对包含全文索引（FULLTEXT）的 InnoDB 表，需先设置 innodb_optimize_fulltext_only=1，再执行多次 OPTIMIZE TABLE 以更新全文索引。
对 MyISAM 或 ARCHIVE 表，删除大量数据或对可变长度行（VARCHAR、BLOB、TEXT 等）做大量修改后，使用该语句可回收空间并碎片整理，提升查询性能。

3. 权限要求

需要对表具有 SELECT 和 INSERT 权限。

4. 支持的存储引擎

支持 InnoDB、MyISAM 和 ARCHIVE 表。
支持内存型 NDB 表的动态列，不支持固定宽度列和磁盘数据表。
对 NDB Cluster 表，支持通过 --ndb-optimization-delay 调节优化操作的批处理间隔。
默认不支持其他存储引擎，启动 mysqld 时加 --skip-new 选项可将 OPTIMIZE TABLE 映射为 ALTER TABLE。
不支持视图。

5. 分区表支持

支持分区表。
可结合 ALTER TABLE ... ANALYZE PARTITION 对分区执行维护。

6. 二进制日志

默认将 OPTIMIZE TABLE 语句写入二进制日志，支持复制。
使用 NO_WRITE_TO_BINLOG 或 LOCAL 可禁止写入。

7. 输出结果

OPTIMIZE TABLE 返回结果集，包含以下字段：

列名	含义
Table	表名
Op	操作，固定为 optimize
Msg_type	信息类型，如 status、note
Msg_text	信息内容

8. InnoDB 细节

对 InnoDB 表，OPTIMIZE TABLE 实际映射为 ALTER TABLE ... FORCE，重建表以更新索引统计和释放聚簇索引中未用空间。
使用在线 DDL，减少并发 DML 操作的停顿。
重建过程分为准备阶段（更新元数据，创建中间表）和提交阶段（提交元数据变更），期间短暂加排他锁。
在启用 old_alter_table 变量或使用 --skip-new 启动时，改用表复制方法重建。
不支持包含全文索引的 InnoDB 表使用在线 DDL，改用表复制方法。
InnoDB 采用页分配方式存储，不像 MyISAM 那样容易产生碎片。
适当的碎片存在是正常的（如页填充率默认约 93%），删除操作可能导致页利用率下降，更新操作通常在同页内重写数据。
高并发环境下，由于 MVCC 机制，索引可能保留多个版本，造成间隙。

9. MyISAM 细节

对 MyISAM 表，OPTIMIZE TABLE 会：
- 修复删除或分裂的行。
- 如果索引页无序则排序索引页。
- 如果统计信息过时且未通过排序修复，则更新统计信息。

10. 其他注意事项

对常规和分区的 InnoDB 表，OPTIMIZE TABLE 是在线操作。
对其他情况，执行期间会锁表。
不对 R-tree 索引（如空间索引 POINT 列）进行排序（存在缺陷 Bug #23578）。

小结

OPTIMIZE TABLE 是用于表物理存储重组和碎片整理的命令，尤其适用于大量数据变更后的 InnoDB 和 MyISAM 表，能有效回收空间、优化性能。InnoDB 通过在线 DDL 支持操作，减少停机时间，是维护表性能的重要工具。

注意事项
- 执行时会对表加锁，需考虑维护时间窗口。
- 未开启 innodb_file_per_table 时，空间回收有限。

总结

场景	推荐操作
删除大量数据后回收空间	`OPTIMIZE TABLE`
更新统计信息辅助查询优化	`ANALYZE TABLE`
检查表完整性	`CHECK TABLE`
备份、恢复表	`mysqldump` 导出和导入

执行 OPTIMIZE TABLE FACTORY.INVENTORY 是清理删除后空间碎片、缩减文件大小的标准方法。

Q16

Question (English)

The data in this instance is transient; no backup or replication is required. It is currently underperforming.

Database size including indexes: 19G
Total system memory: 32G
MySQL status and global variables:

Variable	Value
Com_rollback	85408355
Com_commit	1234342
Innodb_buffer_pool_pages_free	163840

MySQL config [mysqld]:

buffer_pool_size=20G
innodb_flush_log_at_trx_commit=2
disable-log-bin

OS metrics indicate disk is a bottleneck.
Other variables are defaults.

Which two changes will provide the most benefit?

A) max_connections=10000
B) innodb_log_file_size=1G
C) sync_binlog=0
D) innodb_doublewrite=0
E) buffer_pool_size=24G
F) innodb_flush_log_at_trx_commit=1

Answer: B,D

中文翻译

该实例中的数据是临时的，不需要备份或复制。当前性能不足。

数据库大小含索引共19G
系统总内存32G
监控数据：

变量名	值
Com_rollback	85408355
Com_commit	1234342
Innodb_buffer_pool_pages_free	163840

配置：

buffer_pool_size=20G
innodb_flush_log_at_trx_commit=2
disable-log-bin

操作系统指标显示磁盘为性能瓶颈。
其他参数为默认。

解析

选项	说明	推荐与否
A	将最大连接数设为10000，远超默认151，增加内存压力，无连接数瓶颈，不推荐。	不推荐
B	增大日志文件能减少checkpoint频率，减少磁盘写入压力，尤其在磁盘瓶颈时非常有效	推荐
C	关闭二进制日志同步无效，因 binlog 已禁用。	无效
D	关闭 InnoDB 双写缓冲，减少一次磁盘写入，降低IO压力。数据临时且无备份需求，安全性要求低，推荐。	推荐
E	buffer pool还有大量空闲（Innodb_buffer_pool_pages_free很高），继续增大无明显收益。	不推荐
F	设置为1会每次事务提交同步日志，安全但性能低，当前配置为2，改为1会降低性能。	不推荐

背景说明

数据库大小：19G，属于中等规模。
系统内存：32G，当前缓冲池20G，仍有内存余量。
磁盘瓶颈：IO成为性能限制，需减少磁盘读写。
事务情况：大量回滚（Com_rollback >> Com_commit），写入压力低。
配置分析：关闭二进制日志，牺牲持久性换性能，缓冲池未满。

其他参数说明

max_connections：提升连接数无助于当前瓶颈，反而增加资源竞争。
innodb_log_file_size：增大日志文件有利于写负载高场景，此处写入少，作用有限。
sync_binlog：二进制日志已禁用，参数无效。
innodb_flush_log_at_trx_commit：设置为1最安全但性能最低，当前配置为2已折中。

Q17

Question (English)

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

A) Look for queries with big prolonged spikes in row activity/access graph in the time series graph.
B) Sort the "Exec" column and check for SQL queries with high Query Response Time index (QRTi) values.
C) Look for queries with low total latency times in the Latency section in the time series graph.
D) Sort the "Exec" column and check for SQL queries with low Query Response Time index (QRTi) values.

Answer: D

中文翻译

你遇到 MySQL 实例性能问题，这些服务器通过 MySQL Enterprise Monitor 监控。使用 Query Analyzer 时，你从哪里开始查找问题查询？

A）在时间序列图中查找行活动/访问图中有大且持续峰值的查询。
B）按“Exec”列排序，检查查询响应时间指数（QRTi）高的 SQL 查询。
C）在时间序列图的延迟部分查找总延迟时间低的查询。
D）按“Exec”列排序，检查查询响应时间指数（QRTi）低的 SQL 查询。

选项解析

A)
行活动峰值可能指示资源消耗，但不一定是性能瓶颈根因，且高行活动不总等于慢查询。
不是首选排查点。
B)
高 QRTi 表示单次响应较快，整体影响有限。
需要结合执行次数分析。
C)
查找延迟低的查询不合逻辑，性能问题通常由高延迟查询引起。
排除。
D)
按执行次数排序，关注执行次数高且 QRTi 低的查询。
这些查询单次响应慢且频繁执行，累积可能影响整体性能。
这是排查问题查询的合理起点。

MySQL Enterprise Monitor 与 Query Analyzer

https://dev.mysql.com/doc/mysql-monitor/8.0/en/mem-features-qrti.html

Exec（执行次数）：查询执行的总次数，高执行次数的查询对性能影响大。
Query Response Time index (QRTi)：QRTi代表“查询响应时间指数”。它是每个查询的“服务质量”度量，并使用Apdex公式进行计算：详见Apdex维基百科。，值低表示慢查询，值高表示响应快。
Latency（延迟）：查询等待或处理时间，高延迟通常是性能瓶颈表现。
Row Activity / Access Graph：展示查询对数据行的访问量，帮助判断资源消耗。

QRTi如何定义

三个测量条件分别为“最佳”、“可接受”和“不可接受”，定义如下：

类型	默认时间值	分配值	描述	颜色
最佳	100ms	1.00 (100%)	最佳时间范围	绿色
可接受	4 * 最佳 -- 100ms 到 400ms	0.50 (50%)	可接受时间范围	黄色
不可接受	超过可接受 -- 大于 400ms	0.00 (0%)	不可接受的时间范围	红色

示例计算

接下来，我们计算一个平均值来确定最终的QRTi值。例如，如果一个查询共有100次执行，其中60次完成时间低于100ms（最佳时间范围），30次在100ms至400ms之间（可接受时间范围），剩下的10次超过400ms（不可接受时间），那么QRTi得分为：

((60 + (30 / 2) + (10 * 0)) / 100) = 0.75

读取QRTi值

在查询分析器页面列出的查询还有一个彩色圆饼图，用来表示用于QRTi计算的值分析；其中绿色代表最佳百分比，黄色代表可接受百分比，红色代表不可接受百分比。您可以将鼠标悬停在该饼图上以查看每个类别中的查询执行总数以及各类型的查询执行所占的百分比。

因此，在进行查询优化时，您应首先关注饼图中100%是红色的查询，这意味着它们的实际QRTi值为0。这表示该查询的所有执行时间都超过了可接受的时间范围（默认情况下为400ms）。然后您可以点击查询以获取更多信息，例如最大和平均查询时间、平均检查的行数、平均锁等待时间、查看示例查询、查阅EXPLAIN计划示例、查看是否进行了全表扫描、检查索引使用情况等。

然后您可以从QRTi值为0的查询开始，一直优化到QRTi值为1的查询（1表示查询的所有实例在最佳时间范围内执行）。一旦您不再有QRTi值小于1的查询，就可以进入查询分析报告管理员配置，调整QRTi阈值（目标时间）到更低的值，例如50ms，然后重新开始该过程。

诊断性能问题思路

先按执行次数排序，找到执行频繁的查询。
在这些高频查询中，结合 QRTi 指标筛选，关注响应时间慢但执行极高的查询。
通过时间序列图辅助判断查询行为和资源消耗趋势。
避免只关注响应慢但执行次数少的查询，优先优化对系统影响最大的查询。

总结

正确的排查起点是：
按“Exec”列排序，检查执行次数多且 QRTi 低的 SQL 查询（选项 D）。

Q18

Question (English)

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:

[mysqlbackup]  
backup-dir=/backup/full/myrestore  
backup-image=/backup/full/mybackup/myimage.img uncompress

You must perform a database restore to a new machine. The data directory is /data/MEB.
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

Answer: D

中文翻译

检查使用 --compress 选项的 MySQL Enterprise Backup 备份镜像完整路径：
/backup/full/mybackup/myimage.img

mysqlbackup.cnf 内容：

[mysqlbackup]  
backup-dir=/backup/full/myrestore  
backup-image=/backup/full/mybackup/myimage.img uncompress

你必须将数据库恢复到一台新机器，数据目录为 /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

选项解析

A) restore-and-apply-log
用于非镜像备份，不适合镜像备份。
不符合题意。
B) image-to-dir-and-apply-log
仅解压并应用日志，不复制数据到目标数据目录。
需额外步骤复制数据，不符合“一步完成恢复”。
C) apply-log-and-copy-back
先应用日志再复制备份数据，恢复步骤顺序错误。
不符合正确流程。
D) copy-back-and-apply-log
先复制备份数据到数据目录，再应用日志,一步回复命令。
恢复步骤顺序正确，适合镜像备份恢复。
符合题目要求，正确答案。
E) image-to-dir
仅解压镜像，不应用日志，不复制数据。
恢复不完整。

MySQL Enterprise Backup（MEB）镜像备份恢复流程

https://dev.mysql.com/doc/mysql-enterprise-backup/8.4/en/backup-commands-restore.html#option_meb_copy-back-and-apply-log

备份类型
- 镜像备份将数据打包成单个文件，便于存储和传输。
- 启用压缩时，备份镜像为压缩格式，恢复时需解压。
关键配置
- backup-image 指定备份镜像路径。
- backup-dir 指定解压目录或恢复目录。
- uncompress 当与 “提取”操作一起使用时，该选项会对从压缩的单文件备份中提取出来的文件进行解压缩（如果你使用了 --src-entry 选项，则不需要加 --uncompress，工具会自动解压）。（--uncompress 官方文档 When used with the extract operation, uncompresses files that are extracted from a compressed single-file backup (the option is not required when the --src-entry option is used)）.
恢复关键步骤
- 解压镜像 (image-to-dir)：解压备份镜像得到文件结构。
- 应用日志 (apply-log)：应用事务日志，恢复数据一致性。
- 复制数据 (copy-back)：将备份数据复制回 MySQL 数据目录。
- 正确顺序：先复制数据，再应用日志。
常用命令说明
- image-to-dir：image-to-backup-dir 是 extract 命令的一个别名，用于将备份镜像文件提取到一个原始的备份目录中。
  
  注意事项
  - 状态： 仅创建原始备份目录，并不能通过copy-back命令直接恢复。
  - 后续步骤： 要使备份目录成为可恢复的准备（prepared）备份，必须进行日志应用操作（apply-log operation）。该操作可通过单独的apply-log命令完成，或者作为copy-back-and-apply-log命令的一部分来执行。
  使用场景
  
  image-to-backup-dir 常用于从单个备份镜像初始化文件目录，之后可以进一步准备和恢复数据库使用。
  - image-to-dir-and-apply-log：解压并应用日志。
  - copy-back-and-apply-log：复制数据并应用日志（完整恢复）。
  copy-back-and-apply-log 是一个单步骤的操作，用于恢复数据库备份文件到服务器的数据目录，同时执行日志应用操作以确保数据最新。相比于多步骤的恢复方法（如解压、应用日志和恢复），此命令简化了流程，加快了恢复速度，并节省磁盘空间。
  - 备份恢复需求： 指定备份镜像位置（--backup-image），以及用于存储临时文件的目录位置（--backup-dir）。
  - 操作： 恢复备份镜像到服务器的数据目录，并应用日志。
  2. 恢复单文件增量备份
  - 增量备份基础： 假设完整备份已恢复。
  - 操作需求： 指定增量备份镜像位置（--backup-image），和用于存储临时文件的目录（--backup-dir）。
  3. 高级：恢复增量备份目录
  - 增量备份基础： 假设完整备份已恢复。
  - 选项： 使用--backup-dir或--incremental-backup-dir指定增量备份目录。
  4. 恢复特定表
  - 请参阅表级恢复（TLR）的一般要求。
  5. 恢复使用技术表空间支持的备份
  - 操作： 若备份创建时使用--use-tts=with-minimum-locking选项，用--backup-dir指定用于提取临时表的目录。
  另外注意：
  - 不支持恢复自动跳过未使用页的备份（--skip-unused-pages）。
  - 文件backup_variables.txt在恢复结束后更新或创建于数据目录。该文件包含恢复内容的元数据，并且不能被删除或修改。
- apply-log-and-copy-back：顺序错误。
- restore-and-apply-log：非镜像备份使用。
恢复注意事项
- 确保 MySQL 服务停止。
- 指定正确数据目录。
- 恢复完成后检查权限及配置，启动验证。

总结

恢复压缩镜像备份到新机器的正确命令是：

mysqlbackup --defaults-file=mysqlbackup.cnf --datadir=/data/MEB copy-back-and-apply-log

此命令先将数据复制到 /data/MEB，再应用日志，完成数据恢复。

Q19

Question (English)

All MySQL server instances belonging to an InnoDB cluster have SSL configured and enabled. You must configure the InnoDB cluster to use SSL for group communication.
Which two statements are true?

A) Configuring SSL group communication also configures SSL distributed recovery.
B) SSL group communication requires the use of an additional set of parameters group_replication_recovery_*.
C) If only some InnoDB cluster members are enabled for SSL group communication, and --ssl-mode=PREFERRED, communication will fail back to unencrypted connection.
D) An existing InnoDB cluster must be dissolved and created from scratch to enable SSL for group communication.
E) SSL group communication can be enabled for an existing cluster, one instance at a time, by setting group_replication_ssl_mode.
F) SSL group communication must be enabled at cluster creation time by specifying createCluster {membersSslMode:'REQUIRED'}.

Answer: b, F

中文翻译

所有属于 InnoDB 集群的 MySQL 服务器实例都已配置并启用 SSL。你必须配置 InnoDB 集群使用 SSL 进行组通信。
以下哪两个说法正确？

A）配置 SSL 组通信也配置了 SSL 分布式恢复。
B）SSL 组通信需要使用额外的一组参数 group_replication_recovery_*。
C）如果只有部分 InnoDB 集群成员启用了 SSL 组通信，且设置 --ssl-mode=PREFERRED，通信会回退为未加密连接。
D）必须解散现有 InnoDB 集群并重新创建，才能启用 SSL 组通信。
E）可以通过设置 group_replication_ssl_mode 逐个实例为现有集群启用 SSL 组通信。
F）必须在创建集群时通过指定 createCluster {membersSslMode:'REQUIRED'} 启用 SSL 组通信。

选项解析

A) 配置 SSL 组通信不自动配置 SSL 分布式恢复。
组通信和分布式恢复是不同阶段，SSL 配置可以分别设置。
该选项不完全正确。
B) 开启 SSL 组通信时，必须配置或验证用于分布式恢复的 group_replication_recovery_* 参数，保障恢复过程的 SSL 连接安全。
该选项正确。
C) --ssl-mode=PREFERRED 表示客户端可退回未加密连接。但组复制通信要求所有成员配置一致，否则通信失败，不是简单回退成功。
该选项错误。
D) 组通信 SSL 必须在集群创建时设置，不能动态对现有集群逐个节点启用。
要启用此功能，解散并重新创建集群是正确的，但是理论上也可通过滚动重启+参数调整实现，但官方文档建议重建集群以确保一致性。。
该选项错误。
E) SSL 组通信是集群级别配置，不能逐个实例启用。逐个设置会导致配置不一致，通信失败。
该选项错误。
F) SSL 组通信需要在创建集群时设置，正确

Q20

Question (English)

Which two are true about differences between logical and physical upgrades of MySQL databases?

A) Post-upgrade table storage requirements after physical upgrades are usually smaller than that after logical upgrades.
B) Physical upgrades leave data in place, whereas logical upgrades require data to be restored from mysqldump-type backups taken before the upgrades.
C) Physical upgrades are much faster because they do not require restarting the mysqld process.
D) Physical upgrades are performed for current instances on bare metal deployments, whereas logical upgrades are used for virtual machines or containerized instances.
E) Logical upgrades are much faster because they do not require starting the mysqld process.
F) Post-upgrade table storage requirements after logical upgrades are usually smaller than that after physical upgrades.

Answer: B, F

中文翻译

关于 MySQL 数据库逻辑升级和物理升级的区别，以下哪两项是正确的？

A）物理升级后表的存储需求通常比逻辑升级后更小。
B）物理升级保留数据原地不动，而逻辑升级需要从升级前使用 mysqldump 类型备份恢复数据。
C）物理升级更快，因为不需要重启 mysqld 进程。
D）物理升级用于裸金属部署的当前实例，而逻辑升级用于虚拟机或容器化实例。
E）逻辑升级更快，因为不需要启动 mysqld 进程。
F）逻辑升级后表的存储需求通常比物理升级后更小。

选项解析

A) 物理升级直接升级二进制文件和数据文件，数据文件本身不变，存储需求一般不会减少。逻辑升级涉及导出导入，重建表和索引，通常能更好整理压缩数据，存储需求反而可能更小。
该选项通常不正确。
B) 物理升级是直接升级二进制文件和数据文件，数据文件原地不动。逻辑升级是通过 mysqldump 等方式导出再导入数据。
该选项正确。
C) 物理升级一般需要停止 mysqld，升级后再启动，不能热升级。
该选项错误。
D) 物理或逻辑升级的选择与部署平台（裸金属、虚拟机、容器）无直接关系，主要看兼容性和升级需求。
该选项错误。
E) 逻辑升级涉及导出导入数据，通常耗时且需要启动 mysqld。
该选项错误。
F) 逻辑升级中数据和索引重建，通常能清理碎片、优化存储，使存储需求更小。
该选项正确。

升级流程简述

物理升级：停止服务 → 升级二进制文件 → 使用现有数据目录启动 mysqld。
逻辑升级：启动服务导出数据 → 停止服务 → 初始化新数据目录 → 启动 mysqld → 导入数据。

总结

正确选项为：

B) 物理升级数据原地不动，逻辑升级需从备份恢复数据。
F) 逻辑升级后表的存储需求通常比物理升级更小。

Q21

Question (English)

You encountered an insufficient privilege error in the middle of a long transaction.
The database administrator 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) Change the default database and re-execute the failed statement in your transaction.
C) Re-execute the failed statement in your transaction.
D) Close the connection, reconnect, and start the transaction again.

Answer: C

中文翻译

在一个长事务中遇到权限不足错误。
数据库管理员获知后，立即授予了所需权限：

GRANT UPDATE ON world.city TO 'user1';

你如何以最小的中断继续你的事务？

A）回滚事务并在同一会话中重新开始事务。
B）更改默认数据库并重新执行事务中失败的语句。
C）重新执行事务中失败的语句。
D）关闭连接，重新连接，并重新开始事务。

解析

当权限通过 GRANT 语句修改后，MySQL 服务器会立即注意到这些更改，并重新加载授权表到内存。
这种重新加载会影响所有已存在客户端会话的权限，权限变更在客户端的下一次请求时生效。
因此，事务中失败的语句只需重新执行即可生效，无需回滚或重新连接。
选项 C 是正确的做法，能够最小化事务中断。

总结

遇到权限不足错误时，只要管理员已经授予权限，可以直接在当前事务中重新执行失败语句，无需回滚或断开连接。

Q22: Steps to Implement GTID Replication in MySQL 8

Question (English)

An existing asynchronous replication setup is running MySQL 8.
Which two steps are a part of implementing GTID replication?

A) On the slave, alter the MySQL master connection setting with:
CHANGE MASTER TO MASTER_AUTO_POSITION = 1;

B) Execute this on the slave to enable GTID:
RESET SLAVE; START SLAVE GTID_NEXT = AUTOMATIC;

C) Enable GTID by executing this on the master and the slave:
SET GLOBAL GTID_ENABLED = on;

D) Restart MySQL (master and slave) with these options enabled:

--gtid_mode=ON
--log-bin
--log-slave-updates
--enforce-gtid-consistency

E) On the slave, alter the MySQL master connection setting with:
ALTER channel CHANGE MASTER TO MASTER_AUTO_POSITION = 1;

F) Execute this on the slave to enable GTID:
START SLAVE IO_THREAD WITH GTID;

Answer: A, D

中文翻译

一个已有的异步复制环境运行 MySQL 8。
以下哪两步是实现 GTID 复制的一部分？

A）在从服务器上修改主服务器连接设置为：
CHANGE MASTER TO MASTER_AUTO_POSITION = 1;

B）在从服务器上执行以下命令启用 GTID：
RESET SLAVE; START SLAVE GTID_NEXT = AUTOMATIC;

C）在主服务器和从服务器上执行以下命令启用 GTID：
SET GLOBAL GTID_ENABLED = on;

D）重启主从 MySQL 服务器，启用以下选项：

--gtid_mode=ON
--log-bin
--log-slave-updates
--enforce-gtid-consistency

E）在从服务器上修改主服务器连接设置为：
ALTER channel CHANGE MASTER TO MASTER_AUTO_POSITION = 1;

F）在从服务器上执行以下命令启用 GTID：
START SLAVE IO_THREAD WITH GTID;

选项解析

A) 在从服务器上更改 MySQL 主连接设置为：
CHANGE MASTER TO MASTER_AUTO_POSITION = 1;

解释：这个命令是配置从服务器以 GTID 为基础的复制所必需的。
通过设置 MASTER_AUTO_POSITION = 1，表示从服务器应使用 GTID 进行复制，而不是传统的基于位置的复制。
这个配置告诉 MySQL 从主服务器的二进制日志开始使用 GTID 进行复制。
该选项正确。

B) 在从服务器上执行以下命令启用 GTID：
RESET SLAVE; START SLAVE GTID_NEXT = AUTOMATIC;

解释：这个选项不正确。
虽然 RESET SLAVE 是有效的，但它通常用于重置复制配置，在从服务器当前正在复制时使用可能不安全。
START SLAVE GTID_NEXT = AUTOMATIC; 并不是一个有效的方式来启动从服务器的复制。
该选项错误。

C) 在主服务器和从服务器上执行以下命令启用 GTID：
SET GLOBAL GTID_ENABLED = on;

解释：这个选项并不是直接用于启用 GTID 复制的步骤。
GTID 的启用实际上是通过配置参数在 MySQL 启动时实现的，而不是通过这条命令在运行时动态设置。
该选项错误。

D) 重启 MySQL（主和从）并启用以下选项：

--gtid_mode=ON
--log-bin
--log-slave-updates
--enforce-gtid-consistency

解释：这个选项是正确的，因为在设置 GTID 复制之前，需要在 MySQL 的配置中启用这些参数。
--gtid_mode=ON 允许 GTID 功能，
--log-bin 启用二进制日志，
--log-slave-updates 确保从服务器上的更新也被记录到二进制日志中，
--enforce-gtid-consistency 则确保所有事务都遵循 GTID 的一致性规则。
这些参数需要在 MySQL 启动时指定，才能正确地配置 GTID 复制。
该选项正确。

E) 在从服务器上更改 MySQL 主连接设置为：
ALTER channel CHANGE MASTER TO MASTER_AUTO_POSITION = 1;

解释：尽管这条命令看似正确，但 ALTER CHANNEL 不是做 GTID 复制的标准做法。
通常情况下，使用 CHANGE MASTER TO 来配置主连接。
因此，这个选项不是最佳实践。
该选项错误。

F) 在从服务器上执行以下命令启用 GTID：
START SLAVE IO_THREAD WITH GTID;

解释：这个选项是无效的。
在 MySQL 中并没有提供 START SLAVE IO_THREAD WITH GTID; 这样的命令。
GTID 复制是通过在从服务器上设置 CHANGE MASTER TO MASTER_AUTO_POSITION = 1; 来启用的，而不是通过这种方式。
该选项错误。

MySQL GTID（全局事务标识符）复制简介

GTID介绍

全局事务标识符（GTID）是一种用于标识和跟踪在 MySQL 中执行的每个事务的机制。
每个事务都有一个唯一的 GTID，能够在主从复制中提供更好的一致性和容错能力。

GTID复制的优点

简化的故障恢复：当主服务器出现故障并进行备份时，从服务器可以通过 GTID 来快速找到并重放缺失的事务。
无需手动跟踪位置：GTID 使得主从复制无需依赖二进制日志的具体位置，可以直接使用 GTID 进行复制，这简化了管理。
支持多源复制：GTID 可以在同一从服务器上来自多个主服务器的复制，简化了多源复制的实现。

启用GTID的步骤

要启用 GTID 复制，必须在 MySQL 配置中进行以下步骤：
- 修改配置文件（my.cnf 或 my.ini）添加以下参数，并重启 MySQL 服务：
```
[mysqld]
gtid_mode = ON
log_bin = mysql-bin
log_slave_updates = ON
enforce-gtid-consistency = ON
```

主从设置

在主服务器上：
- 确保已启用 GTID，配置完毕后重启主服务器。
在从服务器上：
- 执行命令以使用 GTID 复制：
```
CHANGE MASTER TO MASTER_AUTO_POSITION = 1;
START SLAVE;
```
- 这将配置从服务器以使用 GTID 进行复制。

监控GTID复制状态

使用以下命令监控复制状态：

SHOW MASTER STATUS;
SHOW SLAVE STATUS\G

通过 SHOW SLAVE STATUS 命令，可以检查从服务器的 GTID 信息及复制的健康状态。

GTID_NEXT

MySQL 使用 GTID_NEXT 来指示当前上下文的 GTID，可以在特定事务之前设定以便控制事务的标识。

GTID的备份与恢复

备份完成后，可以使用 GTID 进行恢复，确保数据的一致性。
恢复时，可以使用 CHANGE MASTER TO 命令指定 GTID 范围。

注意事项

在实施 GTID 复制时，请确保所有涉及的服务器都在相同的主版本上运行，并且各个服务器的配置一致。
如果需从传统基于位置的复制切换到 GTID 复制，必须先停止现有的复制，然后进行 GTID 的配置。

总结

实现 GTID 复制的关键步骤是：

D) 在主从服务器配置文件中启用 GTID 相关参数并重启。
A) 在从服务器上设置复制连接使用 GT

Q23: You are using mysqlcheck for server maintenance.

Which two statements are true?

Question (English)

You are using mysqlcheck for server maintenance.
Which two statements are true?

A) The mysqlcheck --optimize --all-databases command reclaims free space from table files.
B) The mysqlcheck --analyze --all-databases command performs a series of checks to spot eventual table corruptions.
C) The mysqlcheck command can be renamed mysqlrepair so that it repairs tables by default.
D) The mysqlcheck --repair --all-databases command can repair an InnoDB corrupted table.
E) The mysqlcheck --check --all-databases command takes table write locks while performing a series of checks.

Answer: A, C

中文翻译

你正在使用 mysqlcheck 进行服务器维护。
以下哪两项说法正确？

A）mysqlcheck --optimize --all-databases 命令回收表文件中的空闲空间。
B）mysqlcheck --analyze --all-databases 命令执行一系列检查以发现表损坏。
C）可以将 mysqlcheck 命令重命名为 mysqlrepair，使其默认修复表。
D）mysqlcheck --repair --all-databases 命令可以修复 InnoDB 损坏的表。
E）mysqlcheck --check --all-databases 命令在执行检查时会对表加写锁。

解析

A) `mysqlcheck --optimize --all-databases` 命令回收表文件中的空闲空间。

解释：此命令会执行 OPTIMIZE TABLE，它通过重建表和索引来回收未使用的空间，从而提高性能。
适用于 MyISAM 和 InnoDB 表。
因此，该说法是正确的。

B) `mysqlcheck --analyze --all-databases` 命令执行一系列检查以发现表损坏。

解释：ANALYZE TABLE 用于更新表的统计信息，帮助查询优化器制定更好的执行计划。
它并不用于检测表的损坏。
因此，该说法是错误的。

C) 可以将 `mysqlcheck` 命令重命名为 `mysqlrepair`，使其默认修复表。

解释：MySQL 中确实存在一个 mysqlrepair 命令，它是 mysqlcheck 的一个符号链接，默认执行 --repair 操作。
重命名 mysqlcheck 为 mysqlrepair 会改变其默认行为为修复表。
因此，该说法是正确的。

D) `mysqlcheck --repair --all-databases` 命令可以修复 InnoDB 损坏的表。

解释：REPAIR TABLE 只支持 MyISAM 表。
InnoDB 表的修复需要通过 InnoDB 的恢复机制或备份恢复来完成。
mysqlcheck --repair 无法修复 InnoDB 表。
因此，该说法是错误的。

E) `mysqlcheck --check --all-databases` 命令在执行检查时会对表加写锁。

解释：CHECK TABLE 命令通常会对表加读锁而非写锁，以保证检查的一致性且不阻止读取操作。
写锁会阻止读写，影响性能，通常不在检查时加写锁。
具体锁类型依赖于存储引擎和 MySQL 版本，但默认不会加写锁。
因此，该说法是错误的。

mysqlcheck 工具概述

mysqlcheck 是 MySQL 提供的客户端工具，用于执行表的维护操作，包括检查（check）、修复（repair）、优化（optimize）和分析（analyze）表。
该工具通过执行对应的 SQL 语句（如 CHECK TABLE、REPAIR TABLE、OPTIMIZE TABLE、ANALYZE TABLE）实现功能。
支持的存储引擎和功能依赖于这些 SQL 语句的支持情况。
执行维护操作时会对表加锁，检查通常使用读锁，修复和优化可能涉及写锁。
支持对单个表、单个数据库或所有数据库进行维护。
支持重命名命令来改变默认行为，例如：
- mysqlrepair 默认执行修复操作
- mysqlanalyze 默认执行分析操作
- mysqloptimize 默认执行优化操作

使用条件与注意事项

需要 MySQL 服务正在运行，无需停止服务器即可执行维护。
修复操作可能导致数据丢失，建议先备份。
并非所有存储引擎都支持所有操作，MEMORY 表不支持检查操作，InnoDB 表不支持 REPAIR。
维护操作可能耗时较长，特别是在大表或多数据库场景下。

常用选项

--all-databases：检查所有数据库的所有表（不包括 INFORMATION_SCHEMA 和 performance_schema，除非显式指定）。
--analyze：分析表，更新统计信息，帮助查询优化。
--auto-repair：自动修复检测到损坏的表。
--check：检查表错误（默认操作）。
--check-only-changed：仅检查自上次检查后发生变化的表。
--extended：进行更彻底的检查或修复，但耗时较长。
--fast：快速检查，只检查未正常关闭的表。
--optimize：优化表，回收空间，重建索引。
--repair：修复表，能修复几乎所有问题（除非唯一键不唯一）。
--force：遇到错误继续执行。
--silent：静默模式，仅输出错误信息。
--verbose：详细模式，输出操作过程信息。
--skip-write-binlog：禁止将 ANALYZE、OPTIMIZE、REPAIR 语句写入二进制日志。

其他说明

可以通过选项文件配置参数，支持多种连接方式和安全选项（如 SSL）。
支持多因素认证密码选项。
支持压缩连接（但部分压缩选项已弃用）。
支持指定特定数据库或表进行操作。
支持各种调试选项，方便排查问题。

总结

mysqlcheck 是 MySQL 提供的便捷表维护工具，可在服务器运行时执行检查、修复、优化和分析操作。它支持多种选项和灵活的调用方式，适合日常数据库维护和故障排查，但针对不同存储引擎支持程度不同，尤其是 InnoDB 表的修复需谨慎操作并备份数据。

正确选项是 A 和 C：
- --optimize 可回收表文件空闲空间。
- 重命名为 mysqlrepair 会使默认操作变为修复表。
其他选项均不正确，特别是 InnoDB 表不能用 mysqlcheck --repair 修复，--analyze 不是检查损坏的工具，--check 不加写锁。

Q24: Examine this statement:

mysql> DROP ROLE r_role1, r_role2;

Which two are true?

Question (English)

A) It fails if at least one of the roles does not exist.
B) You must revoke all privileges from r_role1 and r_role2 before dropping the roles.
C) Existing connections can continue to use the roles' privileges until they reconnect.
D) You must revoke r_role1 and r_role2 from all users and other roles before dropping the roles.
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.

Answer: A, F

中文翻译

请检查以下语句：

mysql> DROP ROLE r_role1, r_role2;

以下哪两项说法正确？

A）如果至少有一个角色不存在，则操作失败。
B）必须先撤销r_role1和r_role2的所有权限，才能删除角色。
C）现有连接可以继续使用角色权限直到重新连接。
D）必须先从所有用户和其他角色撤销r_role1和r_role2，才能删除角色。
E）如果没有r_role1和r_role2的ADMIN权限，则操作失败。
F）如果任何角色被指定在mandatory_roles变量中，则操作失败。

解析

A) It fails if at least one of the roles does not exist.

如果删除的角色中有不存在的角色，命令会失败。
正确。MySQL 默认情况下，如果尝试删除不存在的角色，会报错导致失败，除非使用 IF EXISTS 选项。

B) You must revoke all privileges from r_role1 and r_role2 before dropping the roles.

删除角色前必须先撤销所有该角色的权限。
错误。删除角色时不要求先撤销角色的权限，DROP ROLE 会同时删除角色及其权限。

C) Existing connections can continue to use the roles' privileges until they reconnect.

现有连接在未重新连接前仍可使用该角色的权限。
错误。角色删除后，权限立即失效，现有连接不能继续使用被删除角色的权限。

D) You must revoke r_role1 and r_role2 from all users and other roles before dropping the roles.

删除角色前必须从所有用户和角色中撤销该角色。
错误。MySQL 自动处理角色与用户、角色之间的关联关系，无需手动撤销。

E) It fails if you do not have the ADMIN OPTION of the roles r_role1 and r_role2.

删除角色需要拥有该角色的 ADMIN OPTION，否则失败。
错误。删除角色需要有 DROP ROLE 权限，不是必须拥有 ADMIN OPTION。

F) It fails if any of the roles is specified in the mandatory_roles variable.

如果角色在 mandatory_roles 系统变量中指定，则无法删除。
正确。mandatory_roles 中的角色是强制分配给用户的角色，不能被删除。

DROP ROLE 语句详细说明

1. 语法

DROP ROLE [IF EXISTS] role_name [, role_name ...]

用于删除一个或多个角色（角色是权限的命名集合）。

2. 权限要求

需要拥有全局权限 DROP ROLE 或 CREATE USER。
当系统变量 read_only 启用时，还需要 CONNECTION_ADMIN 权限（或已废弃的 SUPER 权限）。
从 MySQL 8.0.16 起，拥有 CREATE USER 权限的用户可以删除已锁定或未锁定的账户。拥有 DROP ROLE 权限的用户只能删除已锁定的账户（未锁定账户通常是登录用的用户账号，不仅仅是角色）。

3. mandatory_roles 限制

被 mandatory_roles 系统变量指定的角色不能被删除。尝试删除会失败。

4. 执行行为

DROP ROLE 是原子操作，要么所有指定角色都成功删除，要么遇错时全部回滚，不做任何更改。
默认情况下，如果试图删除不存在的角色，会报错导致失败。
使用 IF EXISTS 选项时，试图删除不存在的角色会产生警告而非错误，命令仍继续执行。

5. 二进制日志（binlog）记录

成功执行时，DROP ROLE 语句会被写入二进制日志，包含所有指定角色（即使使用了 IF EXISTS，也会包含不存在的角色）。
失败时不写入二进制日志，执行回滚。

6. 角色名称格式

角色名格式遵循 MySQL 角色命名规范，可带主机名部分，如 'webapp'@'localhost'。
如果省略主机名，默认使用 %（任意主机）。

7. 角色删除后的影响

被删除的角色会自动从所有被授予该角色的用户账号或其他角色中撤销。
对于当前会话，权限变化会在下一条执行的语句生效。

总结

删除角色时，如果有任何角色不存在且未使用 IF EXISTS，命令会失败。
如果角色在 mandatory_roles 系统变量中指定，则无法删除。
不需要手动撤销角色权限或从用户、其他角色中撤销角色，MySQL 会自动处理。
删除角色需要 DROP ROLE 权限，而非必须拥有角色的 ADMIN OPTION。
角色删除后，权限立即失效，不支持现有连接继续使用。

Q25 (English)

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=UDP
C) --database=world
D) --user=admin
E) --password
F) --protocol=pipe
G) --host=192.0.2.1
H) --socket=/tmp/mysql.sock
I) --shared-memory-base-name=world

Answer: C, D, E, G

你在Linux工作站上安装了默认的MySQL客户端。你有管理员登录凭据，需连接运行在远程主机 192.0.2.1:3306（Windows系统）上的MySQL服务器，并连接 world 数据库。
要用一条命令完成此连接，需要指定哪四个选项？

A）--port=3306
B）--protocol=UDP
C）--database=world
D）--user=admin
E）--password
F）--protocol=pipe
G）--host=192.0.2.1
H）--socket=/tmp/mysql.sock
I）--shared-memory-base-name=world

答案： C、D、E、G

解析 / Explanation

远程连接需要指定主机地址（G）、用户名（D）和密码（E）。
指定连接的数据库（C）方便直接进入目标数据库。
端口3306是MySQL默认端口，Linux客户端默认使用，无需显式指定（A可省略）。
选项F、I、H为Windows本地连接相关（命名管道、共享内存、Unix socket），不适用于Linux远程TCP/IP连接。
UDP协议（B）MySQL不支持，MySQL使用TCP/IP协议。

因此，正确选项为：C、D、E、G。

Summary

To connect from a Linux MySQL client to a remote MySQL server on Windows via TCP/IP, specify:

--host=192.0.2.1 (remote server IP)
--user=admin (login user)
--password (prompt for password)
--database=world (default database to use)

Port 3306 is default and usually omitted.

Q26

英文题目：
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) global_variables
B) session_variables
C) variables_by_thread
D) user_variables_by_thread

答案： C

中文翻译：
你想查看所有现有连接的 sort_buffer_size 会话变量的值。你可以查询 performance_schema 中的哪个表？

A）global_variables
B）session_variables
C）variables_by_thread
D）user_variables_by_thread

解析：

A) global_variables
- 存储全局变量值，不区分线程。
- 不是会话变量。
B) session_variables
- 存储当前会话（自己连接）的变量值，不区分其他线程。
C) variables_by_thread
- 存储所有线程的会话变量值，按线程区分。
- 可以查看所有连接的会话变量。
D) user_variables_by_thread
- 存储所有线程的用户自定义变量（SET @var=val），不是系统变量。

MySQL变量类型

全局变量（Global Variables）
影响整个服务器实例，所有连接共享。
会话变量（Session Variables）
只影响当前连接（线程）。每个连接可以有不同的会话变量值。
用户变量（User-defined Variables）
用户自定义，格式如 @var_name，仅在当前会话中有效。

performance_schema中相关表

表名	描述	作用范围
`global_variables`	存储当前服务器的所有全局变量及其值	服务器全局
`session_variables`	存储当前连接的所有会话变量及其值	当前连接
`variables_by_thread`	存储所有线程（连接）的会话变量，按线程区分	所有连接
`user_variables_by_thread`	存储所有线程的用户自定义变量，按线程区分	所有连接

查看所有连接的会话变量

由于会话变量是线程相关的，查看所有连接的会话变量值需查询 performance_schema.variables_by_thread 表。
该表按线程（线程ID）区分，包含每个线程的会话变量名称和值。

示例查询

SELECT THREAD_ID, VARIABLE_NAME, VARIABLE_VALUE
FROM performance_schema.variables_by_thread
WHERE VARIABLE_NAME = 'sort_buffer_size';

注意事项

performance_schema 需要开启，并且相关消费者和监控功能需要启用，才能收集这些数据。
查询 variables_by_thread 可以帮助诊断不同连接中变量设置差异，便于调优和故障排查。

Q27

英文题目：
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) log_throttle_queries_not_using_indexes=5
B) long_query_time=5 log_throttle_queries_not_using_indexes=5
C) long_query_time=5
D) long_query_time=5 log_throttle_quries_not_using_indexes=5 min_examined_row_limit=5000
E) long_query_time=5 min_examined_row_limit=5000
F) min_examined_row_limit=5000
G) log_throttle_quries_not_using_indexes=5 min_examined_row_limit=5000

答案： E

中文翻译：
你的 my.cnf 包含以下设置：

[mysqld]
log_output=FILE
slow_query_log
long_query_time=2.01
log_queries_not_using_indexes

你想记录扫描至少5000条记录且运行时间超过5秒或未使用索引的查询。
你需要添加或修改哪些慢查询日志配置？

A）log_throttle_queries_not_using_indexes=5
B）long_query_time=5 log_throttle_queries_not_using_indexes=5
C）long_query_time=5
D）long_query_time=5 log_throttle_quries_not_using_indexes=5 min_examined_row_limit=5000
E）long_query_time=5 min_examined_row_limit=5000
F）min_examined_row_limit=5000
G）log_throttle_quries_not_using_indexes=5 min_examined_row_limit=5000

解析：

A) log_throttle_queries_not_using_indexes=5
- 限制每分钟记录到慢查询日志中的未使用索引的查询数量，此处为5.只节流未使用索引的查询日志，不符合题目条件。
B) long_query_time=5 log_throttle_queries_not_using_indexes=5
- 修改时间阈值，但加了节流选项，题目没要求。
C) long_query_time=5
- 修改时间阈值，但没设置行数限制。
D) long_query_time=5 log_throttle_quries_not_using_indexes=5 min_examined_row_limit=5000
- 拼写错误（quries 应该是 queries），且加了节流。
E) long_query_time=5 min_examined_row_limit=5000
- 正确修改时间阈值和行数限制，符合题意。
F) min_examined_row_limit=5000
- 只设置行数限制，没调整时间阈值。
G) log_throttle_quries_not_using_indexes=5 min_examined_row_limit=5000
- 拼写错误且没调整时间阈值。

慢查询日志详解

慢查询日志定义
- 记录执行时间超过 long_query_time 秒且扫描行数不少于 min_examined_row_limit 的 SQL 语句。
- 用于发现执行缓慢的查询，帮助优化。
执行时间说明
- 不包括获取初始锁的时间。
- 语句执行完毕并释放所有锁后才写入日志，日志顺序可能与执行顺序不同。
参数说明
- long_query_time：慢查询时间阈值，默认10秒，最小0秒，可精确到微秒。
- min_examined_row_limit：扫描的最小行数阈值。
- slow_query_log：启用或禁用慢查询日志。
- slow_query_log_file：慢查询日志文件名，默认是 host_name-slow.log，位于数据目录。
- log_output：日志输出目标，如文件（FILE）、表（TABLE）等。
- log_slow_admin_statements：是否记录耗时的管理语句（如 ALTER TABLE、ANALYZE TABLE 等）。
- log_queries_not_using_indexes：是否记录未使用索引的查询（表中行数≥2时有效）。
- log_throttle_queries_not_using_indexes：对未使用索引查询的日志进行节流，限制每分钟记录条数，默认0（无限制）。
日志记录规则（判断是否记录语句）
- 语句必须满足以下条件之一：
  - 不是管理语句，或者启用了 log_slow_admin_statements
- 并且满足以下条件之一：
  - 执行时间≥long_query_time
  - 或启用了 log_queries_not_using_indexes 且查询未使用索引
- 并且扫描行数≥min_examined_row_limit
- 并且未被 log_throttle_queries_not_using_indexes 限制过滤
日志内容
- 每条慢查询前有 # 注释行，包含：执行时间、锁等待时间、返回行数、扫描行数等。
- 开启 log_slow_extra 后，日志会额外记录线程ID、错误号、网络流量、存储引擎读写统计、临时表创建数、排序信息等详细指标。
- 日志中密码会被掩码处理，不以明文形式记录。
日志文件管理
- 可以动态启用/禁用慢查询日志和更改日志文件名。
- 如果选择输出到表（TABLE），可能遇到“打开文件过多”错误。
- 日志时间戳时区由 log_timestamps 控制，表日志时间需自行转换。
复制环境
- 默认从库不记录复制的语句到慢查询日志。
- 通过 log_slow_replica_statements（MySQL 8.0.26及以后）或 log_slow_slave_statements（之前版本）可更改此行为，但仅限语句格式的二进制日志。
日志分析
- 慢查询日志文件可能包含不同行格式（含额外字段或不含），分析工具可根据字段数判断。
- 可使用 mysqldumpslow 工具对日志文件进行汇总分析，简化查看。

Q28

English:
Examine this command and output:

mysql> SELECT * FROM data_locks LIMIT 1\G
**************************************************************************
ENGONE: INNODB  
ENDINE_LOCJK_I: 1200:146  
ENGINE_TRANSACTION_ID: 1200  
THREAD_ID:45  
ECENT_ID:11  
OBJECT_SCHEMA: mydb  
OBJECT_NAME: mytable1  
PARTITION_NAME: NULL  
SUSPARTITION_NAME: NULL  
INDEX_NAME: NULL  
OBJECT_INSTANCE_BEGIN:118793337250203  
LOCK_TYPE: RECORD  
LOCK_MODE: X  
LOCK_STATUS: GRANTED  
LOCK_DATA: 1922,192

Which two statements are true?

A) The lock is an intentional lock.
B) The lock is a shared lock.
C) The lock is at the metadata object level.
D) The lock is an exclusive lock.
E) The lock is a row-level lock.
F) The lock is at the table object level.

Answer: D, E

中文翻译：
检查以下命令及输出：

mysql> SELECT * FROM data_locks LIMIT 1\G
**************************************************************************
ENGONE: INNODB  
ENDINE_LOCJK_I: 1200:146  
ENGINE_TRANSACTION_ID: 1200  
THREAD_ID:45  
ECENT_ID:11  
OBJECT_SCHEMA: mydb  
OBJECT_NAME: mytable1  
PARTITION_NAME: NULL  
SUSPARTITION_NAME: NULL  
INDEX_NAME: NULL  
OBJECT_INSTANCE_BEGIN:118793337250203  
LOCK_TYPE: RECORD  
LOCK_MODE: X  
LOCK_STATUS: GRANTED  
LOCK_DATA: 1922,192

以下哪两项是正确的？

A）该锁是意向锁。
B）该锁是共享锁。
C）该锁是元数据对象级别锁。
D）该锁是排它锁。
E）该锁是行级锁。
F）该锁是表对象级别锁。

解析：

A) 该锁是意向锁。
意向锁（Intentional Lock）是 InnoDB 为协调多粒度锁而设置的锁类型，通常是意向共享锁（IS）或意向排他锁（IX）。题中显示锁类型为 RECORD（记录锁），不是意向锁，因此此选项错误。
B) 该锁是共享锁。
共享锁（Shared Lock）允许多个事务读取同一资源但不允许修改。共享锁在 InnoDB 中表示为 S。题中锁模式是 X，表示排他锁（Exclusive Lock），非共享锁，此选项错误。
C) 该锁是在元数据对象级别。
元数据锁（Metadata Lock）锁定数据库对象定义结构，如表结构等。题中锁类型为 RECORD，表示行级锁，不是元数据锁，此选项错误。
D) 该锁是排他锁。
排他锁（Exclusive Lock）表示对资源的独占访问，防止其他事务读写。题中锁模式为 X，即排他锁，此选项正确。
E) 该锁是行级锁。
行级锁（Row-level Lock）锁定具体数据行，锁类型为 RECORD 表明是行锁。题中锁类型为 RECORD，此选项正确。
F) 该锁是在表对象级别。
表级锁锁定整个表，锁类型一般为 TABLE。题中锁类型为 RECORD，表明是行锁，不是表锁，此选项错误。

MySQL Performance Schema `data_locks` 表简介

用于显示当前数据库中被持有或请求的数据锁信息。
适合诊断高并发环境下的性能问题。
收集的信息来源于服务器已有数据，无额外内存或 CPU 开销，无需额外参数控制采集。

主要字段说明

字段名	含义及说明
`ENGINE`	持有或请求锁的存储引擎（如 InnoDB）。
`ENGINE_LOCK_ID`	存储引擎内部锁的唯一标识符，格式内部定义且可能变动，应用不可依赖具体格式。
`ENGINE_TRANSACTION_ID`	发出锁请求的事务ID，代表锁的拥有者。可与 `INNODB_TRX.TRX_ID` 关联查询事务详情。
`THREAD_ID`	创建该锁的会话线程ID，可与 Performance Schema 线程表关联查询线程详情。
`EVENT_ID`	产生该锁的事件ID，配合 `THREAD_ID` 可查找父事件（等待、阶段、语句、事务事件等）。
`OBJECT_SCHEMA`	被锁定对象所在的数据库（schema）名。
`OBJECT_NAME`	被锁定的表名。
`PARTITION_NAME`	被锁定的分区名（若有），否则为 NULL。
`SUBPARTITION_NAME`	被锁定的子分区名（若有），否则为 NULL。
`INDEX_NAME`	被锁定的索引名，InnoDB 总会有索引名（如 GEN_CLUST_INDEX），非 NULL。
`OBJECT_INSTANCE_BEGIN`	锁对象在内存中的地址。
`LOCK_TYPE`	锁类型。InnoDB 常见值：`RECORD`（行级锁）、`TABLE`（表级锁）。
`LOCK_MODE`	锁模式。InnoDB 允许值包括：`S`（共享锁）、`X`（排他锁）、`IS`（意向共享锁）、`IX`（意向排他锁）等。
`LOCK_STATUS`	锁状态。`GRANTED` 表示锁已被授予，`WAITING` 表示正在等待锁。
`LOCK_DATA`	与锁相关的数据。当 `LOCK_TYPE` 是 `RECORD` 时，显示被锁记录的主键或唯一索引值。非行锁时通常为 NULL。

使用场景及说明

查询 data_locks 表可以了解当前系统中所有已持有和请求的锁，帮助定位锁竞争和阻塞问题。
与 data_lock_waits 表联合使用，可查看锁等待关系，明确被阻塞的锁和阻塞锁。
该表替代早期的 INFORMATION_SCHEMA.INNODB_LOCKS 表，后者仅显示被阻塞的锁，而 data_locks 显示所有锁信息。
访问权限只需对 Performance Schema 有 SELECT 权限，不需要额外的 PROCESS 权限。

与旧表 `INNODB_LOCKS` 的对应关系

INNODB_LOCKS 字段	data_locks 字段	说明
LOCK_ID	ENGINE_LOCK_ID	锁的唯一标识
LOCK_TRX_ID	ENGINE_TRANSACTION_ID	事务ID
LOCK_MODE	LOCK_MODE	锁模式
LOCK_TYPE	LOCK_TYPE	锁类型
LOCK_TABLE	OBJECT_SCHEMA, OBJECT_NAME	数据库名和表名
LOCK_INDEX	INDEX_NAME	索引名
LOCK_SPACE	无	不存在对应字段
LOCK_PAGE	无	不存在对应字段
LOCK_REC	无	不存在对应字段
LOCK_DATA	LOCK_DATA	锁相关数据

总结

data_locks 表是 MySQL Performance Schema 提供的重要视图，用于监控和诊断数据库中锁的状态，尤其在 InnoDB 存储引擎下，它详细展示了锁的类型、模式、对象及锁定的数据内容，有助于定位性能瓶颈和锁竞争问题。合理利用该表能有效辅助数据库调优和故障排查。

Q29

English:
After a clean shutdown with innodb_fast_shutdown=0, the top-level data directory files were accidentally deleted.
Which two files must be restored from backup to allow the database to start cleanly?

A) ibdata1
B) mysql.ibd
C) ib_logfile0
D) ibtmp1
E) ib_buffer_pool
F) undo_001

Answer: A, B

中文翻译：
在使用 innodb_fast_shutdown=0 干净关闭后，误删了顶层数据目录中的所有文件，必须从备份恢复哪两个文件才能让数据库干净启动？

A）ibdata1
B）mysql.ibd
C）ib_logfile0
D）ibtmp1
E）ib_buffer_pool
F）undo_001

解析：

A) ibdata1
- InnoDB 系统表空间文件，包含数据字典、撤销日志、插入缓冲等关键元数据。
- 数据库启动时必须存在，否则无法识别 InnoDB 表和事务信息。
- 误删后必须从备份恢复。
B) mysql.ibd
- 某个 InnoDB 表的独立表空间文件（启用 file-per-table 模式时生成）。
- 存储该表的实际数据和索引。
- 丢失该文件会导致对应表数据不可用，需从备份恢复。
C) ib_logfile0
- InnoDB 重做日志文件之一，用于崩溃恢复。
- 干净关闭后日志内容已应用，可重新生成，无需恢复备份。
D) ibtmp1
- InnoDB 临时表空间文件，用于临时表和排序缓冲。
- 启动时自动创建，无需恢复。
E) ib_buffer_pool
- InnoDB 缓冲池保存文件，用于加快重启速度。
- 非关键文件，不影响数据完整性，非必须恢复。
F) undo_001
- InnoDB 撤销日志文件，存储事务回滚和 MVCC 信息。
- 干净关闭时内容已合并，通常包含在系统表空间。
- 单独文件不一定存在或必须恢复。

MySQL InnoDB 关键文件及恢复知识点

InnoDB 系统表空间（ibdata1）
- 包含数据字典、撤销日志、插入缓冲等元数据，是核心文件，启动时必须存在。
- 误删后需从备份恢复，否则数据库无法启动。
独立表空间文件（.ibd 文件）
- 启用 file-per-table 后，每个表有对应的 .ibd 文件存储数据和索引。
- 误删对应 .ibd 文件会导致该表数据不可恢复，需从备份恢复。
- 存放在数据目录对应数据库子目录下。
重做日志文件（ib_logfile0, ib_logfile1 等）
- 用于崩溃恢复，记录事务 redo 日志。
- 干净关闭后日志内容已应用，文件可安全删除或重新生成，无需恢复。
临时表空间文件（ibtmp1）
- 用于临时表和排序操作数据存储。
- 启动时自动创建，丢失后可自动恢复，无需备份恢复。
缓冲池保存文件（ib_buffer_pool）
- 保存缓冲池状态，加快重启速度。
- 非关键文件，丢失不影响数据完整性，无需恢复。
撤销日志文件（undo_001 等）
- 存储事务回滚和 MVCC 数据。
- 通常包含在系统表空间中，部分版本可能存在独立文件。
- 干净关闭后日志已合并，无需单独恢复。
innodb_fast_shutdown 参数
- 0：完全关闭，执行完整清理和合并，保证数据文件一致。
- 1：快速关闭，跳过部分清理，启动时需更长恢复时间。
- 2：非常快速关闭，跳过大部分清理，启动时恢复时间更长。
数据恢复原则
- 干净关闭后，必须恢复系统表空间文件（ibdata1）和所有相关 .ibd 表空间文件，才能保证数据库正常启动和数据完整。
- 重做日志和临时文件不必恢复。
- 备份策略应包含系统表空间和所有表的 .ibd 文件。

Q30

English:
Which two statements about MySQL Enterprise Backup are true?

A) Supports incremental backups.
B) Creates logical backups.
C) Supports recovery to remote MySQL systems.
D) Only supports backing up table structure.
E) Supports backup of remote MySQL systems.
F) Supports hot or warm backups.

Answer: A, F

中文翻译：
关于 MySQL Enterprise Backup，以下哪两项是正确的？

A）支持增量备份。
B）创建逻辑备份。
C）支持恢复到远程 MySQL 系统。
D）仅支持备份表结构。
E）支持远程 MySQL 系统备份。
F）支持热备或温备。

解析：

A) 支持增量备份
MySQL Enterprise Backup 支持增量备份，即只备份自上次备份以来发生变化的数据，节省备份时间和存储空间。此项正确。
B) 创建逻辑备份
MySQL Enterprise Backup 创建的是物理备份（文件级别的备份），而不是逻辑备份（如 mysqldump 导出的 SQL 文本）。此项错误。
C) 支持恢复到远程 MySQL 系统
恢复操作一般在本地执行，不支持直接恢复到远程 MySQL 服务器。此项错误。
D) 只支持备份表结构
备份包含数据和表结构，不是只备份表结构。此项错误。
E) 支持备份远程 MySQL 系统
不支持直接对远程 MySQL 服务器进行备份，备份通常在本地服务器执行。此项错误。
F) 支持热备份或温备份
支持热备份（在线备份），可在数据库运行时备份，不影响写操作，也支持温备份（部分锁定的备份方式）。此项正确。

说明

MySQL Enterprise Backup 专为高效可靠地备份 InnoDB 存储引擎创建的表而设计，也支持 MyISAM 及其他存储引擎的表。
热备份允许在数据库运行且应用程序读写数据时执行备份，不阻塞正常操作，适合大数据量和业务关键场景。
对于非 InnoDB 表，进行温备份，备份期间这些表不可修改。
建议将新表默认存储引擎设置为 InnoDB，或将现有表转换为 InnoDB，以提升备份效率。

更多信息请参阅官方手册：https://dev.mysql.com/doc/mysql-enterprise-backup/en/

Q31

English:
What is the correct syntax to enable Transparent Data Encryption (TDE) on an existing InnoDB table?

A) ALTER TABLE t1 ENCRYPTION='Y';
B) ALTER TABLE t1 WITH ENCRYPTION USING MASTER KEY;
C) ALTER TABLE t1 SET TDE = 'ON';
D) ALTER TABLE t1 ADD ENCRYPTED_TABLESPACE = 'Y';

Answer: A

中文翻译：
对已有 InnoDB 表启用透明数据加密（TDE）的正确语法是什么？

A）ALTER TABLE t1 ENCRYPTION='Y';
B）ALTER TABLE t1 WITH ENCRYPTION USING MASTER KEY;
C）ALTER TABLE t1 SET TDE = 'ON';
D）ALTER TABLE t1 ADD ENCRYPTED_TABLESPACE = 'Y';

解析：

A) ALTER TABLE t1 ENCRYPTION='Y';
这是 MySQL 中启用 TDE 的正确语法。通过修改表的加密属性，将其设置为加密状态。此语法有效且官方支持。
B) ALTER TABLE t1 WITH ENCRYPTION USING MASTER KEY;
该语法不符合 MySQL 标准，语法错误或不存在。
C) ALTER TABLE t1 SET TDE = 'ON';
MySQL 中不存在此语法，错误。
D) ALTER TABLE t1 ADD ENCRYPTED_TABLESPACE = 'Y';
该语法不正确，MySQL 不支持通过添加字段来启用加密。

透明数据加密（TDE）相关知识点

TDE的作用
- 用于对 InnoDB 表的数据文件进行加密，防止数据文件被非法访问时泄露敏感信息。
- 加密过程对应用透明，无需修改应用程序即可使用加密表。
启用TDE的条件
- 需使用支持加密功能的 MySQL 版本（如 MySQL Enterprise Edition）。
- 必须配置并启用密钥管理插件（Keyring Plugin），用于管理加密密钥。
启用TDE的语法
- 对已有 InnoDB 表启用加密的标准语法为：
```
ALTER TABLE 表名 ENCRYPTION='Y';
```
- 该语法将现有表转换为加密表，数据文件将被加密。
- 创建新表时，也可以通过添加 ENCRYPTION='Y' 选项创建加密表。
表加密状态
- ENCRYPTION='N' 表示未加密。
- ENCRYPTION='Y' 表示已加密。
- 也支持其他状态如 ENCRYPTION='D'（默认）、ENCRYPTION='R'（恢复中）等。
密钥管理
- 加密密钥由密钥管理插件统一管理，如 keyring_file、keyring_aws、keyring_hashicorp 等。
- 密钥管理插件负责密钥的存储、轮换和访问控制。
限制和注意事项
- 并非所有存储引擎和表类型都支持 TDE，主要针对 InnoDB。
- 加密表的备份和恢复需确保密钥同步，否则恢复后无法访问数据。
- 启用加密后，性能可能略有下降，具体视硬件和负载而定。

Q32

English:

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

Which statement is true?

A) The user has no username defined, so the connected username defaults to ''@'%'.
B) The user is authorized as rsmith@localhost.
C) The user is authenticated as the anonymous proxy user ''@'%'.
D) The user is authorized as accounting@localhost.
E) The user logged in using --user=accounting option.

Answer: D

中文翻译：

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

以下哪项正确？

A）用户未定义用户名，连接用户名默认成 ''@'%'.
B）用户被授权为 rsmith@localhost。
C）用户认证为匿名代理用户 ''@'%'.
D）用户被授权为 accounting@localhost。
E）用户使用 --user=accounting 选项登录。

解析：

例子命令：
```
GRANT PROXY ON accounting@localhost TO ''@'%';
```
该语句表示匿名用户（用户名为空，host为任意）被授权代理（“冒充”）accounting@localhost 用户。
查询结果说明：
- USER() 是客户端连接时的用户名和主机，这里是 jsmith@localhost，说明客户端用该用户名连接。
- CURRENT_USER() 是 MySQL 实际用来判断权限的用户，这里是 accounting@localhost，说明权限是以该身份执行。
- @@proxy_user 是代理用户，这里是 ''@'%'（匿名用户）。
关系梳理：
1. 客户端连接时用的是 jsmith@localhost，这是实际连接用户名。
2. MySQL 发现 jsmith@localhost 没有直接权限，或在代理权限检查时，将其视为匿名用户 ''@'%'。
3. 匿名用户 ''@'%' 被授权代理成 accounting@localhost，因此 MySQL 允许以 accounting@localhost 身份执行权限检查。
4. 最终执行权限是以 accounting@localhost 身份判断。
换句话说：
- 代理用户是匿名用户 ''@'%'，
- 被代理用户是 accounting@localhost，
- 客户端连接用户名是 jsmith@localhost，但被当作匿名用户处理代理权限，代理成 accounting@localhost。

结论

匿名用户 ''@'%' 代理成了 accounting@localhost。
连接用户 jsmith@localhost 被当作匿名用户处理，实际获得了 accounting@localhost 权限。

根据此，选项分析如下：

选项	说明	正误
A	连接用户名默认成 `''@'%'`	错误
B	用户被授权为 `rsmith@localhost`	错误
C	认证为匿名代理用户 `''@'%'`	错误
D	被授权为 `accounting@localhost`	正确
E	使用 `--user=accounting` 登录	错误

MySQL 代理用户（Proxy Users）相关知识点

代理用户定义
- 代理用户（Proxy User）：外部连接用户，可代表另一个用户进行权限检查和操作。
- 被代理用户（Proxied User）：被代理的用户身份和权限被代理用户使用。
代理用户支持条件
- 认证插件或 MySQL 服务器必须支持代理功能。
- 代理用户账号需配置相应认证插件。
- 被代理用户账号必须存在，且具备对应权限。
- 被代理用户一般禁止直接登录（如使用 mysql_no_login 插件）。
- 代理用户必须被授权对被代理用户的 PROXY 权限。
- 认证插件需返回不同于客户端用户名的用户名，指示代理映射。
代理用户工作流程
- 客户端以代理用户身份连接。
- 认证插件验证身份，返回被代理用户用户名。
- 服务器验证代理用户权限。
- 权限检查和操作以被代理用户身份进行。

创建代理用户示例

CREATE USER 'employee_ext'@'localhost' IDENTIFIED WITH my_auth_plugin AS 'auth_string';
CREATE USER 'employee'@'localhost' IDENTIFIED WITH mysql_no_login;
GRANT ALL ON employees.* TO 'employee'@'localhost';
GRANT PROXY ON 'employee'@'localhost' TO 'employee_ext'@'localhost';

防止被代理用户直接登录
- 使用 mysql_no_login 插件禁止登录。
- 使用 ACCOUNT LOCK 锁定账号。
- 设置复杂密码且不告知他人。
授权与撤销 PROXY 权限
- GRANT PROXY ON 'proxied_user' TO 'proxy_user'; 授权。
- REVOKE PROXY ON 'proxied_user' FROM 'proxy_user'; 撤销。
- 可批量操作。
- 需具备 GRANT PROXY 权限或被代理用户授权。
默认代理用户
- 创建空用户名和主机的账号（''@''）作为默认代理用户。
- 认证插件根据外部信息映射真实用户名。
- 注意匿名用户（''@'%'）与默认代理用户（''@''）优先级冲突。
服务器代理映射支持
- 某些认证插件（PAM、Windows）自带代理映射。
- 不支持代理的插件可启用 check_proxy_users 变量。
- 启用插件变量支持特定插件代理映射。
代理用户映射限制
- 不支持匿名用户代理。
- 单个代理用户代理多个被代理用户时映射不确定，建议避免。
代理用户系统变量
- @@proxy_user：当前代理用户，未代理时为 NULL。
- external_user：部分插件返回的外部用户标识。
代理用户优势与应用
- 统一管理权限，避免多用户单独授权。
- 作为角色机制替代，实现权限委托。
- 常用于集成外部认证系统（LDAP、Windows认证等）与 MySQL 权限管理。

Q33

English:
Which three advantages does mysqlbackup have over mysqldump?

A) mysqlbackup restores data from physical backups, which is faster than logical backups.
B) mysqlbackup can backup InnoDB tables without blocking, reducing wait time.
C) mysqlbackup allows concurrent logical backups to speed up backup and restore.
D) mysqlbackup does not backup MySQL system tables, shortening backup time.
E) mysqlbackup can partially backup stored procedures.
F) mysqlbackup integrates tape backup and supports virtual tape options.

Answer: A, B, F

中文翻译：
使用 mysqlbackup 相较于 mysqldump 的三个优点是什么？

A）mysqlbackup 从物理备份恢复数据，速度比逻辑备份快。
B）mysqlbackup 可以备份 InnoDB 表而不阻塞，减少等待时间。
C）mysqlbackup 允许并发逻辑备份，提升备份和恢复速度。
D）mysqlbackup 不备份 MySQL 系统表，缩短备份时间。
E）mysqlbackup 可以部分备份存储程序。
F）mysqlbackup 集成磁带备份并支持虚拟磁带选项。

解析：

A) mysqlbackup 从物理备份中恢复数据，速度比逻辑备份更快。
- 物理备份是直接备份数据库文件（如数据文件、日志文件等），恢复时只需复制文件，速度快。
- mysqldump 是逻辑备份，将数据导出为 SQL 语句，恢复时需要重新执行 SQL，速度较慢。
B) mysqlbackup 可以对 InnoDB 表进行备份时不阻塞，减少等待时间。
- mysqlbackup 支持 InnoDB 的热备份（在线备份），备份过程中不会锁表或阻塞写操作，业务影响较小。
- mysqldump 备份时通常会锁表，影响正常业务。
F) mysqlbackup 集成磁带备份并支持虚拟磁带选项。
- mysqlbackup 支持与磁带备份设备集成，适合企业级备份方案。
- 支持虚拟磁带库（VTL），方便备份管理和存储。
C) mysqlbackup 不支持并发逻辑备份，主要是物理备份工具。
D) mysqlbackup 会备份 MySQL 系统表，确保备份完整性。
E) mysqlbackup 工具不能单独或部分备份存储过程、函数、触发器等逻辑对象，因为：mysqlbackup 是用于物理备份（例如 InnoDB 表空间文件、redo/undo logs、binary logs 等）的工具。逻辑对象（如存储过程、函数、触发器、事件）存储在 mysql 系统数据库中，以表格形式存在，可以逻辑导出。

MySQL 备份与恢复类型总结

物理备份与逻辑备份
- 物理备份
  - 直接复制数据库存储的文件和目录（如数据文件、日志文件）。
  - 适合大型重要数据库，恢复速度快。
  - 备份输出更紧凑，备份速度快，无需数据转换。
  - 备份粒度从整个数据目录到单个文件，具体取决于存储引擎（例如 InnoDB 支持 file-per-table）。
  - 可以在 MySQL 服务关闭时备份，也可以在线备份（需要锁定机制保证数据一致性）。
  - 典型工具：MySQL Enterprise Backup 的 mysqlbackup，文件系统命令（cp、tar 等）。
  - 物理备份的可移植性依赖于硬件架构相似性。
- 逻辑备份
  - 通过查询 MySQL 服务器导出数据库结构和数据（如 CREATE 和 INSERT 语句）。
  - 适合较小数据量，支持跨平台迁移和编辑。
  - 备份速度较慢，备份文件较大。
  - 备份粒度可到数据库或表级别，适用于所有存储引擎。
  - 备份时 MySQL 服务器需运行。
  - 典型工具：mysqldump，SELECT ... INTO OUTFILE。
  - 恢复时通过执行 SQL 语句或加载文本文件。
在线备份与离线备份
- 在线备份（热备份）
  - 在 MySQL 服务器运行时进行备份，客户端可继续访问数据库。
  - 需要适当锁定以确保数据一致性，MySQL Enterprise Backup 自动处理锁定。
  - 对业务影响较小。
- 离线备份（冷备份）
  - 在 MySQL 服务器关闭时备份。
  - 备份过程简单，无客户端干扰。
  - 可能影响业务可用性，通常在备份副本时使用。
- 恢复操作同样区分在线与离线，在线恢复对客户端影响更大。
本地备份与远程备份
- 本地备份：在 MySQL 服务器所在主机执行备份。
- 远程备份：从远程主机发起备份，输出可写在服务器或客户端。
- mysqldump 支持本地和远程连接，输出可在客户端或服务器端生成。
快照备份
- 利用文件系统快照技术（如 LVM、ZFS）进行备份，快速生成某一时间点的文件系统副本。
- MySQL 自身不支持快照备份，需第三方工具配合。
全量备份与增量备份
- 全量备份：备份 MySQL 服务器在某一时间点的所有数据。
- 增量备份：备份某一时间段内的数据变化，通常基于二进制日志。
- 增量备份依赖开启二进制日志功能。
全量恢复与时间点恢复
- 全量恢复：恢复至备份时刻的数据库状态。
- 时间点恢复（增量恢复）：基于二进制日志，将数据库恢复到某个具体时间点。
- 时间点恢复通常在全量恢复后执行。
表维护
- 保持数据完整性，检测和修复表损坏。
- InnoDB 表一般不易损坏。
- MyISAM 表可使用 mysqlcheck 等工具检测和修复。
备份调度、压缩与加密
- 备份调度用于自动化备份流程。
- 压缩备份文件节省存储空间。
- 加密备份文件防止未授权访问。
- MySQL 自身不提供压缩和加密功能，可通过 MySQL Enterprise Backup 或第三方工具实现。

更多详细内容请参考官方文档：
https://dev.mysql.com/doc/refman/8.0/en/backup-types.html

Q34

English:
Which two statements are true about the mysqld-auto.cnf file?

A) This file is for storing MySQL Server configuration options in JSON format.
B) This file is for logging purposes only and is never processed.
C) This file is for storing MySQL server_uuid values only.
D) It is read and processed at the beginning of startup configuration.
E) It is read and processed at the end of startup configuration.
F) It is always updated with changes to system variables. (Only SET PERSIST and SET PERSIST_ONLY update it)

Answer: A, E

中文翻译：
关于 mysqld-auto.cnf 文件，以下哪两项是正确的？

A）该文件用于以 JSON 格式存储 MySQL 服务器配置选项。
B）该文件仅用于日志记录，且从不被处理。
C）该文件仅用于存储 MySQL server_uuid 值。
D）该文件在启动配置开始时被读取和处理。
E）该文件在启动配置结束时被读取和处理。
F）该文件会随着系统变量的更改而始终更新。（仅 SET PERSIST 和 SET PERSIST_ONLY 会更新它）

解析：

A. This file is for storing MySQL Server configuration options in JSON format.
- 正确。
  mysqld-auto.cnf 文件以 JSON 格式保存通过 SET PERSIST 和 SET PERSIST_ONLY 持久化的服务器变量。
B. This file is for logging purposes only and is never processed.
- 错误。
  它不是日志文件，MySQL 启动时会读取和应用里面的配置项。
C. This file is for storing MySQL server_uuid values only.
- 错误。
  它不仅仅保存 server_uuid，还包含多种持久化的系统变量。
D. It is read and processed at the beginning of startup configuration.
- 错误。
  官方文档说明：mysqld-auto.cnf 会在配置文件解析和命令行参数处理之后读取和处理（也就是最后），确保后面的 PERSIST 配置可以覆盖参数文件。
E. It is read and processed at the end of startup configuration.
- 正确。
  MySQL 启动时，是在其他配置全部读完后，最后才处理 mysqld-auto.cnf，以便 PERSIST 持久化的设置能覆盖普通参数。
F. It is always updated with changes to system variables. (Only SET PERSIST and SET PERSIST_ONLY update it)
- 错误。
  可以使用 SET PERSIST 或 SET PERSIST_ONLY 持久化变量时才会更新 mysqld-auto.cnf，普通 SET 或其他配置项更改不会自动写入该文件,错在主句“总是被更新”。

MySQL 持久化系统变量总结

系统变量与持久化背景
- MySQL 服务器通过系统变量配置运行参数，变量可分为全局和会话级别。
- 许多变量支持动态修改，可通过 SET 语句临时改变当前实例配置。
- 传统配置方式需修改配置文件（如 my.cnf）或重启服务器，操作不便且需主机访问权限。
持久化系统变量功能
- MySQL 支持通过 SET PERSIST 和 SET PERSIST_ONLY 语句，在运行时将系统变量的更改写入数据目录下的 mysqld-auto.cnf 文件，实现重启后依然生效的持久配置。
- SET PERSIST 同时更改当前运行时和持久配置。
- SET PERSIST_ONLY 仅更改持久配置，不影响当前运行时，适用于只允许启动时设置的只读变量。
- 使用 RESET PERSIST 可删除持久化设置。
持久化配置的优势
- 远程或本地客户端均可持久化配置，无需登录服务器主机或手动编辑配置文件。
- 通过权限控制限制谁可以执行持久化操作。
- 配置错误即时反馈，避免启动时因错误配置导致的问题。
- 配置后可通过 RESTART 语句立即让服务器应用新配置。
mysqld-auto.cnf 文件
- 采用 JSON 格式存储持久化系统变量及元数据（如修改时间、用户、主机）。
- 文件在服务器启动时被读取，持久化变量生效。
- 文件内容包括两个部分：
  - mysql_server_static_options：存储只读变量（由 SET PERSIST_ONLY 设置），这些变量作为命令行参数传递。
  - 其他变量通过执行等效于 SET GLOBAL 的操作生效，生效时间较晚。
- 不应手动编辑该文件，避免解析错误导致启动失败。
敏感变量的持久化存储（MySQL 8.0.29+）
- 支持加密持久化敏感变量（如密码、密钥），保护配置安全。
- 需启用 keyring 组件支持密钥管理。
- 敏感变量存储在加密格式中，启动时解密使用。
- 配置参数 persist_sensitive_variables_in_plaintext 控制是否允许明文存储敏感变量及启动行为。
- 具备 SENSITIVE_VARIABLES_OBSERVER 权限的用户可查看敏感变量值，普通用户不可见。
- 在日志中记录修改敏感变量的语句时，值会被替换为 <redacted>，防止泄露。
查看持久化变量信息
- Performance Schema 的 persisted_variables 表可查询当前持久化配置。
- variables_info 表显示变量的最后修改时间和用户信息。
- RESET PERSIST 会影响 persisted_variables 表内容，但不会立即影响 variables_info，需重启后生效。

配置文件读取顺序

Windows 系统（优先级从低到高）：
%WINDIR%\my.ini, %WINDIR%\my.cnf → C:\my.ini, C:\my.cnf → BASEDIR\my.ini, BASEDIR\my.cnf → --defaults-extra-file 指定的文件 → %APPDATA%\MySQL\.mylogin.cnf → DATADIR\mysqld-auto.cnf
Unix/Linux 系统（优先级从低到高）：
/etc/my.cnf → /etc/mysql/my.cnf → SYSCONFDIR/my.cnf → $MYSQL_HOME/my.cnf → --defaults-extra-file 指定的文件 → ~/.my.cnf → ~/.mylogin.cnf → DATADIR/mysqld-auto.cnf
文件后读取的配置项会覆盖前面同名项。
mysqld 的 --user 选项以首次出现为准，防止命令行覆盖配置文件。

更多详细内容请参考官方文档：
https://dev.mysql.com/doc/refman/8.0/en/option-files.html#option-file-order

Q35

English:
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 non-encrypted files are backed up.
C) The backup includes only data files and their metadata.
D) Only InnoDB data and log files are backed up.
E) Only files for MySQL or its built-in storage engines are backed up.

Answer: E

中文翻译：
查看以下成功执行的命令：

$ mysqlbackup --user=dba --password --port=3306 --with-timestamp --only-known-file-types --backup-dir=/export/backups backup

以下哪项是正确的？

A）只备份存储在独立表空间中的表。
B）只备份非加密文件。
C）备份仅包括数据文件及其元数据。
D）只备份 InnoDB 数据和日志文件。
E）只备份 MySQL 或其内置存储引擎的文件。

答案： E

解析：

A) 只备份存储在独立表空间中的表。
解释：此选项错误。命令中没有限制只备份独立表空间的表，备份范围不是仅限于独立表空间。
B) 只备份未加密的文件。
解释：此选项错误。命令没有指定排除加密文件，备份不会仅限于未加密文件。
C) 备份仅包括数据文件和它们的元数据。
解释：此选项错误。备份范围不仅仅是数据文件和元数据，可能还包含日志文件和其他相关文件。
D) 只备份 InnoDB 的数据文件和日志文件。
解释：此选项错误。命令没有限定只备份 InnoDB 存储引擎相关文件，备份可能包含多个存储引擎的文件。
E) 只备份 MySQL 或其内置存储引擎的文件。
解释：此选项正确。--only-known-file-types 参数表示只备份 MySQL 及其内置存储引擎识别的文件，排除未知或第三方存储引擎文件。

mysqlbackup 工具简介

mysqlbackup 是 MySQL 官方提供的备份和恢复客户端工具，操作简便。
支持备份、打包、解包、应用增量变更和恢复数据库文件。

备份内容

备份所有 InnoDB 表及索引，包括系统表空间（默认包含所有 InnoDB 表）和独立表空间（file-per-table 模式下的单表文件，支持 Antelope 和 Barracuda 格式）。
备份所有 MyISAM 表及索引。
备份其他存储引擎管理的表。
备份 MySQL 数据目录下的其他相关文件，如记录 MyISAM 表结构的 .sdi 文件。
备份数据库子目录下的其他所有文件。

主要功能

创建完整备份。
对备份数据进行打包和解包。
在备份过程中应用 InnoDB 表的变更（增量变更）。
恢复数据、索引和日志文件，可恢复到原位置或指定位置。

使用示例

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

也可以将参数写入配置文件 [mysqlbackup] 节点，通过配置文件启动：

mysqlbackup --defaults-file=/usr/local/mysql/my.cnf backup

支持命令行参数覆盖配置文件参数，例如启用压缩：

mysqlbackup --defaults-file=/usr/local/mysql/my.cnf --compress --user=backupadmin --password --port=18080 backup

注意事项

连接 MySQL 的用户需具备备份所需权限（详见权限管理章节）。
--with-timestamp 选项会在备份目录下创建以时间戳命名的子目录，便于区分备份时间。
运行备份的用户或定时任务需有权限复制数据库文件至备份目录。
连接超时时间应设置足够长，确保备份过程中连接不被断开。mysqlbackup 会在备份每个数据库后发送 ping 保持连接。
备份性能优化可参考相关章节内容。

常用命令参数说明

--backup-dir：指定备份数据存放目录。
--backup-image：指定备份镜像文件路径。
--with-timestamp：备份目录下创建带时间戳的子目录。
--only-known-file-types：仅备份 MySQL 及其内置存储引擎识别的文件类型。
--only-innodb：仅备份 InnoDB 数据和日志文件。
--backup_innodb_data_file_path：指定 InnoDB 系统表空间文件的路径和大小。
--backup_innodb_log_group_home_dir：指定 InnoDB 日志文件的备份目录。
--backup_innodb_undo_directory：指定 InnoDB Undo 日志单独表空间的目录。

云存储相关参数

--cloud-access-key-id、--cloud-secret-access-key：AWS S3 访问密钥。
--cloud-bucket：云存储桶名称。
--cloud-host、--cloud-proxy、--cloud-region 等：云存储访问配置。
--cloud-trace：打印云操作追踪信息。

压缩与加密

--compress：创建压缩格式备份。
--compress-level：压缩级别。
--encrypt：加密备份镜像。
--encrypt-password：加密密钥密码。

连接相关参数

--user、--password、--host、--port、--socket：数据库连接参数。
--connect_timeout：连接超时时间。
--login-path：从 .mylogin.cnf 文件指定登录路径读取参数。

操作控制

--incremental：增量备份。
--incremental-backup-dir：增量备份目录。
--incremental-base：增量备份的基准备份。
--no-locking：备份时禁用表锁。
--skip-binlog、--skip-relaylog：跳过二进制日志或中继日志备份。
--sleep：复制数据时每复制 1MB 后休眠毫秒数。

性能调优

--limit-memory：备份操作可用内存大小（MB）。
--process-threads、--read-threads、--write-threads：备份操作的并发线程数。
--page-reread-count、--page-reread-time：页面重读最大次数及等待时间。

日志与调试

--debug：打印调试信息。
--trace：设置追踪日志级别。
--messages-logdir、--skip-messages-logdir：消息日志目录配置或禁用。
--show-progress：定期输出备份进度。

其他

--defaults-extra-file、--defaults-file：指定额外或唯一配置文件。
--no-defaults：不读取任何默认配置文件。
--help：显示帮助信息。
--version：显示版本信息。
--rename：恢复时重命名指定表。
--dst-entry、--src-entry：用于单文件备份提取指定文件或目录

Q36

English:
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='one' LIMIT 1;
B) UPDATE world.country SET Name='new' WHERE Name='old'; (WHERE requires SELECT privilege)
C) UPDATE world.country SET Name='first' ORDER BY Name LIMIT 1; (ORDER BY requires SELECT privilege)
D) UPDATE world.country SET Name=CONCAT('New ', Name); (CONCAT function's Name column also requires SELECT privilege)
E) UPDATE world.country SET Name='all';

Answer: A, E

中文翻译：
查看以下语句及输出：

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)

以下哪两条 SQL 语句是 jsmith 可以执行的？

A）UPDATE world.country SET Name='one' LIMIT 1;
B）UPDATE world.country SET Name='new' WHERE Name='old';（WHERE 需要 SELECT 权限）
C）UPDATE world.country SET Name='first' ORDER BY Name LIMIT 1;（ORDER BY 需要 SELECT 权限）
D）UPDATE world.country SET Name=CONCAT('New ', Name);（CONCAT 函数中的 Name 列也需要 SELECT 权限）
E）UPDATE world.country SET Name='all';

解析：

jsmith 用户权限如下：
- USAGE 权限（基本连接权限，无实际操作权限）
- 仅对 world.country 表的 Name 列拥有 UPDATE 权限（只能更新 Name 列）
A) UPDATE world.country SET Name='one' LIMIT 1;
- 只更新 Name 字段，且无 WHERE/ORDER BY，无需SELECT权限。可执行（正确）
B) UPDATE world.country SET Name='new' WHERE Name='old';
- WHERE 子句涉及 Name 字段，MySQL 执行时需要对 Name 字段有 SELECT 权限。没SELECT权限无法执行。
C) UPDATE world.country SET Name='first' ORDER BY Name LIMIT 1;
- ORDER BY 涉及 Name 字段排序，MySQL 也要求有 SELECT(Name) 权限。不能执行。
D) UPDATE world.country SET Name=CONCAT('New ', Name);
- SET 子句右侧用到了 Name 字段，每次运算前需要读原 Name，MySQL 要求有 SELECT(Name) 权限。不能执行。
E) UPDATE world.country SET Name='all';
- 更新 Name 字段，赋定值（不依赖原有数据，无 WHERE/ORDER BY/表达式），只需UPDATE(Name) 权限。可以执行（正确）。

SHOW GRANTS 语句简介

用于显示 MySQL 用户账号或角色所拥有的权限和角色，结果以 GRANT 语句形式展示。

语法示例：

SHOW GRANTS [FOR user_or_role [USING role [, role] ...]]

需要 mysql 系统库的 SELECT 权限（查看自己权限除外）。
显示用户或角色的权限和角色授权。
MySQL 8.0 中不再用 ALL PRIVILEGES 表示全局权限，而是列出具体权限。
支持显示角色权限及部分撤销权限。

更多权限说明请见官方文档：
https://dev.mysql.com/doc/refman/8.0/en/grant.html#grant-privileges

Q37

English:
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) Reads from the slave can return outdated data for some time, until it applies all transactions from its relay log.
B) A small amount of committed transactions may be lost in case they were committed just before the disk failure.
C) 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.
D) 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.
E) Reads from the slave can return outdated data until the value of the rpl_semi_sync_master_timeout variable is reached.

Answer: A, B

中文翻译：
你配置了半同步复制并且有一个从库，rpl_semi_sync_master_timeout 从未达到。
发现主库磁盘系统故障，主库数据完全无法恢复。
以下哪两项是正确的？

A）从从库读取的数据可能在一段时间内是过时的，直到应用完其中继日志中的所有事务。
B）如果事务在磁盘故障前刚提交，少量已提交事务可能会丢失。
C）事件发生后，应用可以立即从从库读取数据，并且依赖其返回完整且最新的数据。
D）从库会自动识别主库不可达，并执行必要操作以让应用开始使用从库作为新主库。
E）从库返回的数据可能过时，直到达到 rpl_semi_sync_master_timeout 变量值。

解析：

A) 从从库读取的数据可能在一段时间内是过时的，直到从库应用完中继日志中的所有事务。
- 正确。即使是半同步复制，从库在应用事务时也有延迟，读取时可能会比主库落后，导致数据过时。
B) 可能会丢失少量已提交的事务，如果这些事务是在磁盘故障前刚提交的。
- 正确。半同步复制保证事务提交至少被一个从库接收，但主库磁盘故障导致主库数据不可恢复，这些刚提交且未完全复制的事务可能丢失。
  比如特殊情况：从库完成拉取事务，但还未向主库完成ACK确认（主库宕机）；此时从库拥有该事务，但主库没有完成该事务，主库会将该事务丢弃。
  类似于TCP三次握手，如果时间颗粒度划分越小，事情就越复杂。
C) 事件发生后，应用程序可以立即从从库读取并依赖其返回完整且最新的数据。
- 错误。由于从库存在延迟，且主库数据不可用，从库数据不一定是最新的，不能完全依赖。
D) 从库会自动检测主库不可达，并自动执行必要操作，使应用可以开始使用从库作为新主库。
- 错误。MySQL复制不会自动完成主从切换，需要人工或自动化工具介入完成切换。
E) 从从库读取的数据会过时，直到达到rpl_semi_sync_master_timeout变量的值。
- 错误。rpl_semi_sync_master_timeout是主库等待从库确认的超时时间，与从库数据是否过时无直接关系。

MySQL半同步复制（Semisynchronous Replication）

一、概述

MySQL 默认采用异步复制，主库写入二进制日志，副本（从库）异步拉取并执行事务。
异步复制存在主库崩溃时数据丢失风险，因为未必所有事务都传递给从库。
全同步复制要求所有从库提交事务后主库才返回，保障数据一致性但性能开销大。
半同步复制介于异步和全同步之间，主库等待至少一个从库确认收到事务后才提交，保障数据至少存在两个地方，降低数据丢失风险，性能开销适中。

二、工作原理

从库连接主库时声明支持半同步复制。
主库启用半同步复制且至少有一个半同步从库时，提交事务的线程阻塞，等待从库确认收到事务事件（写入并刷新中继日志）。
若超时未收到确认，主库回退为异步复制继续提交事务。
当至少一个半同步从库赶上后，主库恢复半同步复制模式。
阻塞结束后，主库返回事务提交结果给客户端。

三、特点与优势

提高数据完整性和一致性，降低主库故障时数据丢失风险。
允许配置等待确认的从库数量和超时时间，灵活平衡性能与安全。
默认等待确认时机为同步二进制日志后提交事务前，可配置为提交事务后等待确认。
支持对非事务性表的回滚操作也进行半同步处理。
对非显式事务语句（自动提交）也执行等待确认。

四、配置与监控

半同步复制需在主库和从库双方启用对应插件。
主要配置参数包括等待确认的从库数、超时时间、等待确认的时机（提交前或提交后）。
MySQL 8.0.23后，新增优化参数减少锁竞争，提高多从库环境性能。

五、注意事项

主库崩溃后切换到从库作为新主库时，原主库不能再用作复制源，避免数据冲突。
适合网络延迟较低、从库数量适中的场景。
性能损耗约为网络往返时延，网络越快性能越好。

六、总结

半同步复制在保证数据安全性和复制性能之间取得平衡，是MySQL中常用的复制方式。合理配置等待确认数量和超时时间，有助于提高系统容错能力和数据一致性。

MySQL复制源服务器的配置选项和系统变量

一、复制源服务器标识

每台复制源和从库必须设置唯一的server_id，范围为1到2^32-1，确保复制拓扑中唯一。

二、启动选项

--show-replica-auth-info（MySQL 8.0.26及以后）和已废弃的--show-slave-auth-info用于在SHOW REPLICAS输出中显示复制用户及密码信息，配合--report-user和--report-password使用。

三、关键系统变量

auto_increment_increment 和 auto_increment_offset
- 用于控制AUTO_INCREMENT列的值分配，特别适合循环复制（source-to-source）场景。
- auto_increment_increment控制自增步长，默认1。
- auto_increment_offset控制自增起始值，默认1。
- 例如，auto_increment_increment=10, auto_increment_offset=5时，生成序列为5,15,25,35…
- 这两个变量全局和会话均可设置，影响当前会话或全局所有表的AUTO_INCREMENT列。
- 在Group Replication启动时，会自动调整这两个变量（多主模式下）。
版本相关变量
- immediate_server_version：保存复制源服务器的MySQL版本号，用于从库正确处理不同版本间的语法和语义差异。
- original_server_version：保存事务最初提交服务器的版本号，用于跨版本复制兼容性。
- 这两个变量由复制系统自动设置，用户不可随意修改。
半同步复制相关变量（需要安装半同步复制插件）
- rpl_semi_sync_master_enabled：控制是否启用半同步复制（主库端），默认关闭。
- rpl_semi_sync_master_timeout：主库等待从库确认事务的超时时间，单位毫秒，默认10000（10秒）。超时后回退为异步复制。
- rpl_semi_sync_master_trace_level：半同步复制调试级别，有4个等级（1-64），用于不同详细程度的日志信息。
- rpl_semi_sync_master_wait_for_slave_count：事务提交前，主库等待多少个从库确认，默认1。设置为2

Q38

English:
Which two are true about binary logs used in asynchronous replication?
A) They are pulled from the master to the slave.
B) They are pushed from the master to the slave.
C) They contain events that describe all queries run on the master.
D) They contain events that describe only administrative commands run on the master.
E) They contain events that describe database changes on the master.

Answer: A, E

中文翻译

关于异步复制中使用的二进制日志，以下哪两项是正确的？

A）二进制日志是从主库拉取到从库的。

这是正确的。在MySQL异步复制中，从服务器通过IO线程从主服务器拉取二进制日志事件，然后在自己的SQL线程上执行这些事件以保持数据同步。

B）二进制日志是从主库推送到从库的。

这是错误的。二进制日志不会主动推送给从服务器，而是从服务器主动连接主服务器并拉取日志。

C）二进制日志包含描述主库上所有查询的事件。

这是错误的。二进制日志只记录了会修改数据库状态的事件（如INSERT、UPDATE、DELETE等），而不是所有查询（例如SELECT查询不会被记录）。

D）二进制日志仅包含描述主库上管理命令的事件。

这是错误的。二进制日志包含的是数据库变更事件，而不仅仅是管理命令。

E）二进制日志包含描述主库数据库变更的事件。

这是正确的。二进制日志记录了导致数据库状态改变的事件，是复制的基础。

MySQL复制实现（Replication Implementation）

1. 复制的基础原理

复制基于源服务器（主服务器）对其数据库所有变更（如更新、删除等）进行记录，这些变更以事件的形式写入二进制日志（binary log）。
二进制日志是对所有修改数据库结构或数据内容事件的记录，通常不包含SELECT查询，因为SELECT不修改数据库。

2. 二进制日志的传输方式

每个副本服务器（从服务器）连接到源服务器后，会主动请求（拉取）二进制日志的副本。复制数据是由从服务器拉取，而不是主服务器推送。
从服务器接收到二进制日志事件后，会执行这些事件，从而在从服务器上重现主服务器上的数据库变更，包括表的创建、结构修改以及数据的插入、删除和更新。

3. 副本服务器的独立性

每个从服务器是独立的，异步地重放来自主服务器二进制日志的事件。
从服务器可以根据自身速度读取和应用日志事件，可以随时启动或停止复制进程，且不会影响主服务器或其他从服务器的更新。

4. 复制线程与状态监控

复制过程由多个线程协同完成，具体细节可参见“复制线程”相关章节。
主服务器和从服务器会定期报告复制状态，便于管理员监控复制进程。

5. 中继日志与复制元数据

从服务器在处理从主服务器拉取的二进制日志之前，会先将其写入本地的中继日志（relay log）。
从服务器还会记录当前在主服务器二进制日志和本地中继日志中的处理位置，用于复制的准确跟踪和恢复。

6. 复制过滤规则

从服务器可以根据配置的规则对复制的事件进行过滤，只应用符合条件的数据库变更事件。
这些过滤规则根据不同的配置选项和变量进行评估，具体应用细节可参见“服务器如何评估复制过滤规则”章节。

MySQL二进制日志（Binary Log）

1. 二进制日志的内容和作用

二进制日志包含描述数据库变更的“事件”，如表的创建、数据修改等。
还包含可能导致变更的语句事件（如DELETE语句即使匹配到0行也会记录），除非使用基于行的日志格式。
记录每条修改数据语句的执行时间。
二进制日志主要用于两大用途：
1）复制：主服务器通过二进制日志向从服务器传递数据变更事件，从服务器重放这些事件实现数据同步。
2）数据恢复：备份恢复后，通过重放备份后记录的二进制日志事件实现增量恢复，保持数据最新。

2. 不记录的语句

不记录不修改数据的语句，如SELECT、SHOW等。
如果需要记录所有语句（例如调试问题），应使用通用查询日志（General Query Log）。

3. 性能影响与安全

启用二进制日志会稍微降低性能，但其对复制和恢复的好处远大于性能损失。
二进制日志对意外停机具有恢复能力，只记录完整事件或事务。
出于安全考虑，日志中包含的密码会被重写为非明文形式。
MySQL 8.0.14起支持二进制日志和中继日志加密，防止日志被未授权访问。

4. 配置与管理

默认启用二进制日志（log_bin=ON），初始化数据目录时除外。
可通过启动参数如--log-bin指定日志文件基础名和路径。
日志文件名由基础名加数字后缀组成，服务器重启、日志刷新或日志文件达到最大大小时创建新文件。
有对应的日志索引文件记录所有日志文件名，不建议手动编辑。
服务器ID（server_id）用于复制中标识服务器，必须唯一。
可以通过SET sql_log_bin=OFF语句在有权限的客户端会话中禁用当前会话的二进制日志记录。

5. 日志格式与事务处理

支持三种日志格式：基于行（row-based）、基于语句（statement-based）、混合格式（mixed）。
非事务性表的更新立即写入日志，事务性表的更新在事务提交时一次性写入。
如果事务回滚且包含非事务性表修改，日志中会写入ROLLBACK事件确保复制一致性。
事务语句缓存由binlog_cache_size控制，过大事务可能使用临时文件，影响性能。

6. 日志文件大小与缓存

max_binlog_size限制单个日志文件最大大小，大事务不会被拆分。
binlog_cache_use和binlog_cache_disk_use状态变量用于监控缓存使用情况，指导缓存大小调优。

7. 复制相关

从服务器默认启用log_replica_updates（或旧版log_slave_updates），将从主服务器接收的更新写入自己的二进制日志，从而支持多级复制。
主服务器不要删除还被从服务器使用的二进制日志文件，可以用PURGE BINARY LOGS命令安全删除旧日志。

8. 日志查看与恢复

使用mysqlbinlog工具查看和重放二进制日志内容，支持恢复和审计。
日志写入顺序保证与执行提交顺序一致，确保复制正确性。
MySQL 8.0通过InnoDB的两阶段提交机制和sync_binlog=1配置保证日志和数据文件同步，防止崩溃后数据与日志不一致。
若发现日志文件比预期短，可能导致复制不一致，需要重新同步数据快照。

9. 错误处理

binlog_error_action配置遇到日志写入错误时的行为，默认停止服务器，可设置忽略错误但风险较大。

10. 重要系统变量会被记录到二进制日志中，并在从服务器解析日志时生效，如sql_mode、foreign_key_checks、unique_checks等。

总结

MySQL复制通过主服务器记录数据库变更事件到二进制日志，从服务器主动拉取日志并重放，实现数据的异步同步。复制过程涉及多个线程、中继日志和过滤规则，确保复制的灵活性、独立性和可靠性。二进制日志是数据库复制和恢复的核心机制，记录所有修改数据库结构和内容的事件，支持灵活的日志格式和安全加密，具有良好的性能和崩溃恢复能力。合理配置和管理二进制日志对于保证数据一致性和复制稳定性至关重要。

Q39

English:
Which three actions will secure a MySQL server from network-based attacks?
A) Allow connections from the application server only.
B) Use network file system (NFS) for storing data.
C) Construct a perimeter network to allow public traffic.
D) Use MySQL Router to proxy connections to the MySQL server.
E) Change the listening port to 3307.
F) Place the MySQL instance behind a firewall.

Answer: A, C, F

中文翻译：
以下哪三项措施可以保护 MySQL 服务器免受基于网络的攻击？
A）仅允许来自应用服务器的连接。
B）使用网络文件系统（NFS）存储数据。
C）构建边界网络以允许公共流量。
D）使用 MySQL Router 代理连接到 MySQL 服务器。
E）将监听端口更改为 3307。
F）将 MySQL 实例置于防火墙后面。
解析：
• 限制连接来源（A）和置于防火墙后面（F）是常见安全措施。
• 构建边界网络（C）可隔离内部网络与公共网络。

Perimeter network（边界网络）

通常也称为DMZ（Demilitarized Zone，隔离区），是指在企业内部网络与公共网络（如互联网）之间设置的一个受控区域。它的目的是作为内部网络与外部网络之间的缓冲区，提高安全性。

Allow public traffic（允许公共流量）

指允许来自互联网或公共网络的访问流量进入这个边界网络，从而访问放置在该区域中的公共服务（如网站服务器、邮件服务器、DNS服务器等）。

通过构建边界网络，可以限制外部访问者直接访问内部网络资源，减少安全风险，同时保证公共服务的可用性。简单来说，就是搭建一个安全的中间网络区域，让外部用户可以访问特定的公共服务，同时保护内部网络不被直接暴露。

• 其他选项不直接提升安全。
• 因此正确答案为 A、C、F。

Q40

English:
Which three sets of item information are visible in the mysql system database?
A) Performance monitoring information
B) Plugins
C) Audit log events
D) Rollback segments
E) Information about table structures
F) Time zone information and definitions
G) Help topics

Answer: B, F, G

中文翻译：
在 mysql 系统数据库中，可见哪三类信息？
A）性能监控信息
B）插件
C）审计日志事件
D）回滚段
E）表结构信息
F）时区信息和定义
G）帮助主题

解析：

mysql 库包含插件表（B）、时区信息（F）和帮助主题（G）。
性能监控信息通常在 performance_schema，审计日志和回滚段不在 mysql 库。
表结构信息存在于各数据库的元数据表，而非 mysql 库。
因此正确答案是 B、F、G。

MySQL系统数据库（mysql schema）：

https://dev.mysql.com/doc/refman/8.0/en/system-schema.html

1. 概述

mysql schema 是MySQL的系统架构，包含MySQL服务器运行所需的各种系统表。
这些表主要分为两类：
- 数据字典表：存储数据库对象的元数据。
- 系统表：用于其他操作性功能。
所有这些表默认使用InnoDB存储引擎，存储在单个名为 mysql.ibd 的表空间文件中。

2. 数据字典表（Data Dictionary Tables）

包含数据库对象的元数据信息，如数据库、表、列、索引、触发器、外键等。
这些表在MySQL 8.0引入，是数据字典的新实现，取代了旧版本中的部分系统表。
数据字典表不可直接通过 SELECT 查询，也不会出现在 SHOW TABLES 或 INFORMATION_SCHEMA.TABLES 中。
通过对应的 INFORMATION_SCHEMA 视图可以访问大部分元数据信息。
主要表包括：
- schemata：数据库信息
- tables：表信息
- columns：列信息
- indexes：索引信息
- foreign_keys：外键信息（通过视图访问）
- triggers：触发器信息
- 以及其他用于存储事件、存储过程参数、分区、统计信息等的表。

3. 授权系统表（Grant System Tables）

存储用户账户及其权限信息。
包括用户权限、数据库权限、表权限、列权限、存储过程权限、代理权限等。
从MySQL 8.0开始，这些表改用InnoDB存储引擎，支持事务。
主要表包括：
- user：用户账户及全局权限
- db：数据库级权限
- tables_priv、columns_priv：表和列权限
- procs_priv：存储过程权限
- password_history：密码变更历史

4. 对象信息系统表（Object Information System Tables）

用于存储服务器组件、可加载函数和插件的信息。
主要表包括：
- component：服务器组件
- func：可加载函数
- plugin：服务器端插件

5. 日志系统表（Log System Tables）

用于存储日志信息，支持日志查询。
主要表包括：
- general_log：通用查询日志
- slow_log：慢查询日志
这些表使用CSV存储引擎。

6. 服务器端帮助系统表（Server-Side Help System Tables）

存储服务器端帮助信息，支持 HELP 命令。
包括类别、关键字、帮助主题等表。

7. 时区系统表（Time Zone System Tables）

存储时区相关信息和定义，用于时间函数和时区转换。
包括时区ID、闰秒、时区名称及转换规则等表。

8. 复制系统表（Replication System Tables）

支持复制功能，存储复制相关信息，如GTID、二进制日志索引、从服务器状态等。
主要表包括：
- gtid_executed：GTID执行信息
- slave_master_info、slave_relay_log_info、slave_worker_info：从服务器复制元数据

9. 优化器系统表（Optimizer System Tables）

用于查询优化器，存储统计信息和成本模型数据。
主要表包括：
- innodb_index_stats、innodb_table_stats：InnoDB持久化统计信息
- server_cost、engine_cost：优化器成本估算

10. 其他系统表（Miscellaneous System Tables）

一些不属于上述类别的系统表。
包括审计日志表（需Enterprise版）、防火墙相关表、FEDERATED引擎使用的服务器表、InnoDB动态元数据表等。

总结

MySQL的 mysql 系统架构包含丰富的系统表，涵盖了数据库元数据、用户权限、插件、日志、帮助信息、时区数据、复制信息、优化器统计等多种功能模块。数据字典实现了对数据库对象的集中管理，且多数数据通过 INFORMATION_SCHEMA 视图对外提供访问接口。系统表的设计和存储引擎的改进提升了MySQL的管理能力和性能表现。

Q41

English:
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.389450z 24 Query select @@version_comment limit 1
2019-12-17T00:36:23.929519z 25 Connect root@localhost on mydb using SSL/TLS
2019-12-17T00:36:23.929846z 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.045498z 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) A deadlock occurs after innodb_lock_wait_timeout seconds.
B) Connection 24 experiences a lock wait timeout.
C) Connection 25 experiences a lock wait timeout.
D) All statements execute without error.
E) A deadlock occurs immediately.
Answer: E

中文翻译：
查看以下通用查询日志条目：
时间 Id 命令参数
2019-12-17T00:36:23.389450z 24 Connect root@localhost 在 mydb，使用 SSL/TLS
2019-12-17T00:36:23.389450z 24 Query select @@version_comment limit 1
2019-12-17T00:36:23.929519z 25 Connect root@localhost 在 mydb，使用 SSL/TLS
2019-12-17T00:36:23.929846z 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.045498z 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

所有 UPDATE 语句引用的行都存在。
以下哪项描述了该语句序列的结果？
A）死锁在 innodb_lock_wait_timeout 秒后发生。
B）连接 24 发生锁等待超时。
C）连接 25 发生锁等待超时。
D）所有语句无错误执行。
E）立即发生死锁。

解释

1. 分析锁竞争情况

连接 24 在事务中先更新了 t1 表中 ID=130 的行，获得了该行的排它锁。
连接 25 在事务中先更新了 t2 表中 ID=3805 的行，获得了该行的排它锁。
连接 25 接着尝试更新 t1 表中 ID=130 的行，这时该行已被连接 24 锁定，连接 25 会等待锁释放。
连接 24 最后尝试更新 t2 表中 ID=3805 的行，这时该行已被连接 25 锁定，连接 24 会等待锁释放。

2. 锁等待的循环依赖

连接 24 等待连接 25 释放 t2 锁，连接 25 等待连接 24 释放 t1 锁。
这形成了一个循环等待，典型的死锁场景。

3. 死锁检测和处理

InnoDB 会立即检测到死锁。
服务器会回滚其中一个事务（通常是等待时间较短或代价较小的那个），解除死锁。
因此，死锁不会导致无限等待或锁等待超时。

结论

正确答案：E) 立即发生死锁。

MySQL InnoDB 死锁

1. 什么是死锁

死锁是指多个事务因相互持有对方所需的锁而无法继续执行，所有事务都在等待对方释放锁，导致循环等待，最终无事务能完成操作。

2. 死锁产生的原因

事务以相反的顺序锁定多个表中的行（如通过 UPDATE 或 SELECT ... FOR UPDATE 语句），形成循环等待。
事务锁定索引记录的范围和间隙时，由于时序问题，各事务部分获得锁但又等待其他锁，导致死锁。

3. 如何减少死锁发生的可能性

使用事务代替 LOCK TABLES 语句。
保持插入或更新操作的事务尽量短小，避免长时间持锁。
多个事务更新多表或大范围行时，确保各事务的操作顺序一致（例如都按相同顺序执行 SELECT ... FOR UPDATE）。
在 SELECT ... FOR UPDATE 和 UPDATE ... WHERE 语句涉及的列上创建索引。
死锁发生与隔离级别无关，因为隔离级别影响读操作行为，而死锁源于写操作的锁竞争。

4. 死锁检测与处理

默认启用死锁检测。
一旦检测到死锁，InnoDB 会自动回滚其中一个事务（称为“牺牲者”），释放锁，允许其他事务继续。
如果禁用死锁检测（通过设置 innodb_deadlock_detect 为 OFF），则依赖 innodb_lock_wait_timeout 超时来回滚事务。
因此，即使应用逻辑正确，也必须处理事务重试的情况。

5. 诊断和日志

使用 SHOW ENGINE INNODB STATUS 查看最近一次死锁信息。
若死锁频繁，可启用 innodb_print_all_deadlocks，将所有死锁信息打印到 MySQL 错误日志，便于分析。

6. 参考章节

17.7.5.1 An InnoDB Deadlock Example（死锁示例）
17.7.5.2 Deadlock Detection（死锁检测）
17.7.5.3 How to Minimize and Handle Deadlocks（如何最小化和处理死锁）

总结

MySQL InnoDB 的死锁是写操作中因锁竞争导致的循环等待，系统默认自动检测并回滚牺牲者事务。合理设计事务顺序、缩短事务时间、创建合适索引等措施能有效减少死锁发生。开发者需做好死锁重试机制和日志分析，保证系统稳定高效运行

Q42

English:
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 'Threads%';
+----------------+----------------+---------------+---------+
| 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.00 sec)
Which change should optimize the number of buffer pool instances for this workload?
A) Decrease the number of buffer pool instances to 4.
B) Increase the number of buffer pool instances to 16. (thread_running is 16)
C) Increase the number of buffer pool instances to 12.
D) Decrease the number of buffer pool instances to 1.
E) Increase the number of buffer pool instances to 32.
Answer: B

中文翻译：
查看以下输出：

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 'Threads%';
+----------------+----------------+---------------+---------+
| 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.00 sec)

针对该工作负载，应该如何调整缓冲池实例数以优化性能？

选项分析

选项	调整方案	解释
A	减少到4	实例数减少，适合低并发，线程多时锁竞争加剧
B	增加到16（线程数）	实例数与并发线程数匹配，减少锁竞争，提高并发性能
C	增加到12	折中方案，适合线程数介于8~16之间，平衡锁竞争与管理开销
D	减少到1	单实例锁竞争严重，适合极低并发场景
E	增加到32	实例数远大于线程数，管理和同步开销大，反而影响性能

解析

InnoDB 缓冲池实例（innodb_buffer_pool_instances）用于减少多线程环境下的锁竞争。
实例数通常建议与活跃线程数（如 Threads_running）接近或略少。
题中 Threads_running = 16，当前实例数为8，存在锁竞争空间，可提升实例数。
增加到16更能减少锁竞争，提高性能，尤其在高并发环境下。

正确答案

B) 增加缓冲池实例数至16。

MySQL InnoDB 缓冲池

InnoDB 缓冲池（Buffer Pool）简介
缓冲池是 InnoDB 用于缓存数据页和索引页的内存区域，显著提高读写性能。
大小由参数 innodb_buffer_pool_size 控制，通常设置为系统内存的大比例。
缓冲池实例（Buffer Pool Instances）
为减少多线程锁竞争，InnoDB 将缓冲池划分为多个实例（innodb_buffer_pool_instances）。
每个实例管理缓冲池的一部分内存，实例间独立，减少锁争用。
实例数越多，锁竞争越少，但管理和同步开销增加。
合理设置实例数的原则
实例数一般与服务器的并发线程数（活跃线程数）匹配或略少。
典型建议每实例管理至少 1 GiB 缓冲池内存，实例数不宜过多或过少。
缓冲池较大时（>1 GiB）应增加实例数减少锁竞争。
实例数过少易锁竞争成为瓶颈；过多则同步开销增大影响性能。
线程数与实例数的关系
观察当前活跃线程数（如 Threads_running）是调整实例数参考依据。
实例数应接近活跃线程数，避免过度竞争或资源浪费。
其他相关参数
innodb_buffer_pool_chunk_size：缓冲池每个块大小，实例数 × 块数 × 块大小 = 缓冲池总大小。
innodb_buffer_pool_size：缓冲池总大小。

总结

合理调整 innodb_buffer_pool_instances 参数，使其与系统并发线程数匹配，有助减少锁竞争，提高 InnoDB 并发性能和整体数据库吞吐量。避免实例数过多或过少，保持平衡是优化关键。

Q43

English:
Which three requirements must be enabled for group replication?
A) Primary key or primary key equivalent on every table
B) Semi-sync replication plugin
C) Binary log ROW format
D) Binary log MIXED format
E) Replication filters
F) Binary log checksum
G) Slave updates logging
Answer: A, C, G

中文翻译：

组复制必须启用哪三项要求？
A）每个表必须有主键或等效主键
B）半同步复制插件
C）二进制日志 ROW 格式
D）二进制日志 MIXED 格式
E）复制过滤器
F）二进制日志校验和
G）从库更新日志记录

解析：

• 组复制要求每个表必须有主键。
• 二进制日志必须使用 ROW 格式。
• 从库更新日志必须启用以保证复制一致性。
• 因此答案为 A、C、G

20.1.1.2 组复制（Group Replication）

https://dev.mysql.com/doc/refman/8.0/en/group-replication-summary.html

1. 基本概念

组复制是一种用于实现容错系统的技术。一个复制组由一组服务器组成，每个服务器都持有全部数据的副本（共享无状态架构，shared-nothing）。
组内服务器通过消息传递进行交互，通信层保证了原子消息和全序消息的投递。这些特性为构建更高级的数据库复制方案提供了坚实基础。

2. MySQL Group Replication 特点

基于上述通信特性，MySQL Group Replication 实现了多主、任意节点可写（multi-source update everywhere）的复制协议。
一个复制组由多个服务器组成，每个成员都可以独立执行事务。
读写事务只有在获得组内批准后才能提交，即事务的提交是全组协商的结果，而非发起服务器单方面决定。
只读事务无需组内协调，可立即提交。

3. 事务广播与全局顺序

当一个读写事务准备提交时，发起服务器会原子广播写入值（变更的行）及其写集合（变更行的唯一标识）。
通过原子广播，要么所有成员都收到该事务，要么都收不到；所有成员接收事务的顺序也完全一致，从而建立了全局事务顺序。

4. 并发冲突与认证

不同成员上并发执行的事务可能存在冲突。
通过比较不同事务的写集合，进行行级别冲突检测（认证，certification）。
如果两个并发事务修改了同一行，则存在冲突。先被排序的事务胜出（first commit wins），后排序的事务回滚。
例如，t1和t2并发修改同一行，若t2排序在t1前，则t2提交，t1回滚。
如果事务间经常冲突，建议在同一服务器上发起这些事务，以便通过本地锁管理器同步，减少回滚。

5. 事务应用与最终一致性

在实际应用和外部化已认证事务时，组复制允许各成员在不破坏一致性和有效性的前提下，略微偏离全局顺序。
组复制是最终一致性系统：只要写入流量减缓或停止，全体成员最终拥有完全一致的数据。
写入高峰期间，不同成员应用事务的顺序可能略有差异，但不会影响一致性。
在多主模式下，本地事务认证后可立即外部化，即使有更早的远程事务尚未应用，只要无冲突即可。
在单主模式下，主节点上并发且无冲突的本地事务偶尔也可能以与全局顺序不同的顺序提交；从节点（只读）始终按全局顺序应用事务。

6. 小结与对比

MySQL Group Replication 协议基于消息一致性和全序保证，实现了安全高效的多主复制。
与传统MySQL复制或半同步复制相比，组复制拥有更强的故障容错和自动冲突处理能力。
Paxos及共识相关的底层协议细节在此未展开描述。

20.3.1 组复制要求（Group Replication Requirements）

https://dev.mysql.com/doc/refman/8.0/en/group-replication-requirements.html

一、基础设施要求（Infrastructure）

InnoDB存储引擎
- 所有数据必须存储在InnoDB事务型存储引擎中，因为组复制依赖于事务和冲突检测。
- 其他存储引擎（如MEMORY、MyISAM等）不支持，使用可能导致组复制出错。
- 可以通过 disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY" 禁止其他存储引擎。
主键约束
- 组内所有需要复制的表必须有主键或非空唯一键，用于唯一标识行，便于冲突检测。
- 组复制有内置主键检查机制，和 sql_require_primary_key 变量的检查不完全一致。
网络性能
- 建议所有组成员部署在低延迟、高带宽的网络环境，需保证所有成员间的双向通信畅通（不能被防火墙等阻断）。
- 支持IPv4、IPv6及混合网络，也可用于VPN环境。
- 局域网成员可用更高效的本地通信通道，但部分操作（如加入组）仍需TCP网络。

二、服务器实例配置（Server Instance Configuration）

唯一的服务器ID
- 每个组成员需配置唯一的 server_id，范围为1到(2^32)-1。
二进制日志（Binary Log）
- 必须开启二进制日志（MySQL 8.0默认开启），参数为 --log-bin。
- 组复制依赖于二进制日志内容进行复制。
复制日志记录
- 必须开启 log_replica_updates=ON（8.0.26前为 log_slave_updates=ON），MySQL 8.0默认已开启。
二进制日志行格式
- 必须使用 binlog_format=row（默认），组复制依赖行格式复制检测并发冲突。
二进制日志校验和
- MySQL 8.0.21之前需设置 binlog_checksum=NONE，8.0.21及之后支持默认 CRC32。
GTID设置
- 必须开启 gtid_mode=ON 和 enforce_gtid_consistency=ON，组复制基于GTID进行事务跟踪。
- 若需设置 gtid_purged，需在组复制未运行时操作。
复制信息库
- 需设置 master_info_repository=TABLE 和 relay_log_info_repository=TABLE（8.0默认，FILE已废弃），保证复制元数据一致性和可恢复性。
写集合提取
- 设置 transaction_write_set_extraction=XXHASH64（8.0默认，从8.0.26起该参数已废弃），用于收集主键信息以实现冲突检测和认证。
默认表加密
- default_table_encryption 值需在所有组成员一致（可为ON或OFF），运行中无法修改。
表名大小写
- lower_case_table_names 需在所有组成员一致，建议设为1以兼容InnoDB（不是所有平台默认值）。
二进制日志依赖跟踪
- 可选设置 binlog_transaction_dependency_tracking=WRITESET，有助于分布式恢复性能优化。
多线程复制
- 组成员支持多线程复制（默认开启并行复制）。参数：
  - replica_parallel_workers（8.0.26前为 slave_parallel_workers），默认4，可设1~1024。
  - replica_preserve_commit_order=ON 配合 replica_parallel_type=LOGICAL_CLOCK（默认），确保事务提交顺序一致。
XA分布式事务
- 8.0.29及以上支持Detached XA事务（xa_detach_on_prepare=ON，默认），允许预处理后由其他连接提交或回滚。

三、注意事项

组复制相关配置需在所有成员保持一致，否则可能导致组成员无法正常加入或工作。
某些参数（如 default_table_encryption、lower_case_table_names）运行中不可更改。
多线程复制相关设置建议采用默认值，除非有特殊需求。
网络环境和主键设计是组复制成功部署的基础保障。

四、总结

MySQL Group Replication 要求所有成员使用InnoDB引擎、主键完整、网络互通、二进制日志开启、GTID一致、复制元数据表、并行复制等关键配置。
配置前需检查所有表和参数，确保对应要求，方可保证高可用、高一致性的组复制环境。

Q44

English:
Examine this command, which executes successfully on InnoDB Cluster: dba.dropMetadataSchema()
Which two statements are true?
A) The command drops the mysql_innodb_cluster_metadata schema and re-creates it. (No re-creation)
B) The mysql_innodb_cluster_metadata schema is dropped from the instance where the connection was established.
C) Connections driven by MySQL Router are not affected by the command. (Metadata no longer exists)
D) The mysql_innodb_cluster_metadata schema is dropped from all reachable members of the cluster.
E) Group Replication will be dissolved and all metadata purged. (Requires explicit dissolve)
F) Group Replication is still operational, but InnoDB Cluster must be reimported under MySQL Shell.

Answer: D, F

中文翻译：

查看以下在 InnoDB Cluster 上成功执行的命令：dba.dropMetadataSchema()
以下哪两项是正确的？
A）该命令会删除并重新创建 mysql_innodb_cluster_metadata 模式。（不重建）
B）mysql_innodb_cluster_metadata 模式只从当前连接实例删除。
C）MySQL Router 驱动的连接不会受该命令影响。（元数据已不存在）
D）mysql_innodb_cluster_metadata 模式会从集群所有可达成员删除。
E）组复制将被解散且所有元数据被清除。（需执行 dissolve）
F）组复制仍然运行，但必须在 MySQL Shell 下重新导入 InnoDB Cluster。

解析：

• 该命令删除所有可达成员上的元数据模式。
• 组复制仍然运行，需重新导入集群。
• 因此答案为 D、F。

Q45

English:
Which three commands can report all the current connections running on the MySQL server?
A) SELECT * FROM sys.metrics
B) SELECT * FROM information_schema.events
C) SELECT * FROM sys.statement_analysis
D) SELECT * FROM information_schema.processlist
E) SHOW EVENTS
F) SHOW FULL PROCESSLIST
G) SELECT * FROM performance_schema.threads
H) SELECT * FROM performance_schema.events_transactions_current

Answer: D, F, G

中文翻译：

以下哪三条命令可以报告 MySQL 服务器上所有当前连接？
A）SELECT * FROM sys.metrics
B）SELECT * FROM information_schema.events
C）SELECT * FROM sys.statement_analysis
D）SELECT * FROM information_schema.processlist
E）SHOW EVENTS
F）SHOW FULL PROCESSLIST
G）SELECT * FROM performance_schema.threads
H）SELECT * FROM performance_schema.events_transactions_current

解析：

• information_schema.processlist 和 SHOW FULL PROCESSLIST 都显示当前连接。
• performance_schema.threads 也显示线程信息。
• 其他选项不直接显示当前连接。
• 因此答案为 D、F、G。

10.14.1 访问进程列表（Accessing the Process List）

1. 进程信息的来源

MySQL 进程信息可以通过以下方式获取：

SHOW PROCESSLIST 语句：查看当前连接和线程的详细信息。
mysqladmin processlist 命令：命令行工具获取进程列表。
INFORMATION_SCHEMA.PROCESSLIST 表：以表格方式查询进程信息。
Performance Schema processlist 表：高性能的进程信息表，MySQL 8.0.22 开始，SHOW PROCESSLIST 可基于此表实现，无需加锁，性能更好。
Performance Schema threads 表（PROCESSLIST_ 前缀的列）：不仅包含前台线程，还包含后台线程，提供线程类型和服务器内部位置等额外信息，便于更全面的线程监控。
sys schema 的 processlist 和 session 视图：对 Performance Schema threads 表的数据做了格式化，session 视图会过滤掉后台线程，仅显示用户会话。

注意：

使用 threads 表获取线程信息不需要加锁，性能影响极小；而 SHOW PROCESSLIST、INFORMATION_SCHEMA.PROCESSLIST、mysqladmin processlist 等方式获取信息时需要加锁，可能会对服务器性能产生负面影响。
sys schema 的 processlist 视图是 threads 表的更便捷展示；session 视图则过滤了后台线程，仅显示会话信息。

2. 访问进程列表所需权限

拥有 PROCESS 权限：可以看到所有线程（包括其他用户的线程）。
没有 PROCESS 权限：非匿名用户只能看到自己的线程，匿名用户无法查看任何线程。
Performance Schema threads 表：采用不同的权限模型（详见官方文档相关章节）。

3. 进程列表条目的内容

每个进程列表条目包含以下信息（以 SHOW PROCESSLIST 输出为例，其他来源类似）：

Id：客户端连接标识符。
User：线程所属的用户。
Host：线程所属的主机。
db：线程当前使用的默认数据库（未选择则为 NULL）。
Command：线程当前执行的命令。
State：线程当前状态。大多数状态为快速操作，若线程长时间停留某状态，需排查问题。
Time：线程已处于当前状态的秒数。部分情况下该值可由线程通过 SET TIMESTAMP 修改。对于复制 SQL 线程，该值为最后一个复制事件的时间戳与当前主机时间的差值。
Info：线程正在执行的 SQL 语句（SHOW PROCESSLIST 仅显示前 100 字符，SHOW FULL PROCESSLIST 或其它信息源可查看完整语句）。

注意事项：

进程列表中的 Command 和 State 值可能随 MySQL 版本变化而变动，应用程序应注意兼容性。
具体 Command 和 State 的取值及含义，请参考官方文档相关章节说明。

Q46

English:
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 ((MONTH(birth_date)));
B) ALTER TABLE employees ADD INDEX (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);
D) ALTER TABLE employees ADD INDEX (birth_month);
E) ALTER TABLE employees ADD INDEX ((CAST(birth_date->>'.month′ASunsigned)));
F) ALTER TABLE employees ADD COLUMN birth_month tinyint unsigned GENERATED ALWAYS AS (birth_date->>'$.month') VIRTUAL NOT NULL,ADD INDEX (birth_month) ;

Answer: A, C

中文翻译：

查看以下成功执行的建表语句：

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;

再看以下查询：

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

你需要添加一个索引以减少查询处理的行数。以下哪两条语句可以做到这一点？
A）ALTER TABLE employees ADD INDEX ((MONTH(birth_date)));
B）ALTER TABLE employees ADD INDEX (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);
D）ALTER TABLE employees ADD INDEX (birth_month);
E）ALTER TABLE employees ADD INDEX ((CAST(birth_date->>'.month′ASunsigned)));
F) ALTER TABLE employees ADD COLUMN birth_month tinyint unsigned GENERATED ALWAYS AS (birth_date->>'$.month') VIRTUAL NOT NULL,ADD INDEX (birth_month) ;

解析：

选项	语句	是否支持	解析
A	`ALTER TABLE employees ADD INDEX ((MONTH(birth_date)));`	✅ 有效	使用了函数索引，正确。
B	`ALTER TABLE employees ADD INDEX (birth_date);`	❌ 部分有效	对 `birth_date` 建索引，在 `WHERE MONTH(birth_date) = 4` 这种表达式查询下，不能完全利用索引，但在范围查询等情况下可能有帮助。本题场景优化有限。
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` 并建索引，查询可改为 `WHERE birth_month = 4`，可直接利用索引，极大优化查询。
D	`ALTER TABLE employees ADD INDEX (birth_month);`	❌ 不成立	表中还没有 `birth_month` 字段，直接建索引会报错，需先添加该字段。
E	`ALTER TABLE employees ADD INDEX ((CAST(birth_date->>'.month' AS unsigned)));`	❌ 不支持	`birth_date` 是 DATE 类型，不是 JSON，不能这样转换和建索引。
F	`ALTER TABLE employees ADD COLUMN birth_month tinyint unsigned GENERATED ALWAYS AS (birth_date->>'month') VIRTUAL NOT NULL, ADD INDEX (birth_month);`	❌ 不适用	`birth_date` 不是 JSON 类型，不能用 `->>'month'` 语法。

MySQL 8.0.13+ 函数索引（Functional Key Parts）要点与常见用法

说明	示例/语法	是否支持	解析
普通索引	`INDEX (col1, col2(10))`	✅ 支持	可对列或列前缀建索引。
单一函数索引	`INDEX ((ABS(col1)))`	✅ 支持	8.0.13+ 支持对表达式结果建索引，需用括号包裹表达式。
多函数索引	`INDEX ((col1 + col2), (col1 - col2), col1)`	✅ 支持	可混合函数键和普通列键。
函数索引降序	`ALTER TABLE t1 ADD INDEX ((col1 * 40) DESC);`	✅ 支持	支持 ASC/DESC 排序。
忘记括号	`INDEX (col1 + col2, col3 - col4)`	❌ 不支持	表达式必须用括号括起，否则报错。
仅用列名	`INDEX ((col1), (col2))`	❌ 不支持	不能对单列名用函数键语法，直接写 `INDEX (col1, col2)`。
列前缀函数键	`INDEX ((SUBSTRING(col1,1,10)))`	✅ 支持	用 `SUBSTRING()` 进行“前缀”索引，但查询语句要完全匹配表达式。
外键	任何函数键	❌ 不支持	函数索引不能用于外键定义。
主键	`PRIMARY KEY ((col1+col2))`	❌ 不支持	主键不能包含函数索引键。
UNIQUE	`UNIQUE INDEX ((ABS(col1)))`	✅ 支持	支持唯一约束。
SPATIAL/FULLTEXT	`SPATIAL INDEX ((...))`/`FULLTEXT INDEX ((...))`	❌ 不支持	不支持空间和全文索引。
复制表	`CREATE TABLE ... LIKE`	✅ 支持	LIKE 语句会复制函数索引定义。
删除被引用列	先删索引后删列	-	若某列被函数键引用，需先删索引再删列。
JSON 函数键	`INDEX ((CAST(data->>'$.name' AS CHAR(30))))`	✅ 支持	推荐用 CAST 转为定长类型，如 CHAR(30)。
JSON 错误用法	`INDEX ((data->>'$.name'))`	❌ 不支持	返回 LONGTEXT 类型，不能无前缀建索引。
JSON 建议	`INDEX ((CAST(data->>'$.name' AS CHAR(30)) COLLATE utf8mb4_bin))`	✅ 推荐	保证排序规则与查询一致，索引能被有效利用。

注意事项：

函数索引本质是隐藏虚拟生成列，受虚拟生成列所有限制。
不能用子查询、参数、变量、存储函数等。
查询条件需与索引表达式完全一致（如 SUBSTRING、CAST 参数、collation 等），否则无法用上索引。
若类型/排序规则不一致，需用 COLLATE 显式指定。

示例：

CREATE TABLE employees (
  data JSON,
  INDEX idx ((CAST(data->>"$.name" AS CHAR(30)) COLLATE utf8mb4_bin))
);

-- 查询时
SELECT * FROM employees WHERE data->>'$.name' = 'James';

Q47

English:
Which three are types of InnoDB tablespaces?
A) Schema tablespaces
B) Temporary table tablespaces
C) Encryption tables
D) Data tablespaces
E) Redo tablespaces
F) Undo tablespaces

Answer: B, D, F

中文翻译：

以下哪三项是 InnoDB 表空间类型？
A）模式表空间
B）临时表表空间
C）加密表
D）数据表空间
E）重做日志表空间
F）撤销表空间

解析：

A) Schema tablespaces（模式表空间）
不是 InnoDB 的表空间类型。Schema（模式）是数据库对象的逻辑集合，没有对应的物理表空间概念。

B) Temporary table tablespaces（临时表表空间）
属于 InnoDB 表空间类型。从 MySQL 5.7 开始，InnoDB 支持将临时表的数据存储在专用的临时表表空间中（如 ibtmp1），用于存储内部临时表和用户临时表的数据。

C) Encryption tables（加密表）
不是表空间类型。加密表是指开启了加密功能的表，但并不是一种表空间类型。

D) Data tablespaces（数据表空间）
属于 InnoDB 表空间类型。主要包括系统表空间（ibdata1）和每个表的独立表空间（.ibd 文件），用于存储表的数据和索引。

E) Redo tablespaces（重做日志表空间）
不是表空间类型。Redo log（重做日志）用于崩溃恢复，存储在 redo log 文件中，不属于表空间。

F) Undo tablespaces（撤销表空间）
属于 InnoDB 表空间类型。Undo tablespace 用于存储事务的撤销信息，以支持回滚和多版本并发控制（MVCC）。

正确答案

B) Temporary table tablespaces（临时表表空间）
D) Data tablespaces（数据表空间）
F) Undo tablespaces（撤销表空间）

关于表空间

https://dev.mysql.com/doc/refman/8.0/en/innodb-tablespace.html

InnoDB 表空间（Tablespaces）相关知识点总结

1. 什么是表空间

表空间（Tablespace）是 InnoDB 存储引擎用于在物理文件中组织和管理数据的一种逻辑结构。表空间可以包含多个表的数据和索引，也可以为每张表单独分配文件。合理配置和理解表空间有助于数据库的性能优化和管理。

2. InnoDB 常见表空间类型

系统表空间（System Tablespace）
- 文件如 ibdata1。
- 存储 InnoDB 的数据字典、回滚段、部分表和索引数据（如果未启用独立表空间）。
- 是最早期 InnoDB 的主要数据存储方式。
独立表表空间（File-Per-Table Tablespace）
- 每个 InnoDB 表单独一个 .ibd 文件。
- 通过参数 innodb_file_per_table=ON 启用（MySQL 5.6 及以后默认开启）。
- 便于表的管理、空间回收和表级别操作。
临时表表空间（Temporary Table Tablespace）
- 用于存储内部和用户的临时表数据。
- 临时表表空间文件（如 ibtmp1）在 MySQL 启动时创建，关闭时删除。
- 防止临时数据污染主数据文件。
撤销表空间（Undo Tablespace）
- 用于存储事务的撤销信息，支持回滚和多版本并发控制（MVCC）。
- 可以配置为多个独立的 undo 表空间文件。

3. 其他相关但不是表空间的概念

重做日志（Redo Log）
- 用于崩溃恢复，保证事务的持久性（ACID）。
- 存储在 redo log 文件中（如 ib_logfile0），不是表空间。
加密表
- 指表的数据被加密存储，但“加密表”不是一种表空间类型。
- 表空间可以被加密，但加密本身不是表空间分类。
Schema（模式）
- 逻辑数据库对象集合，不是物理表空间类型。

4. 典型表空间文件举例

表空间类型	物理文件示例	作用说明
系统表空间	ibdata1	存储元数据、部分数据和索引
独立表表空间	employees.ibd	存储单个表的数据和索引
临时表表空间	ibtmp1	存储所有临时表的数据
撤销表空间	undo_001, undo_002	存储事务的撤销信息

5. 总结

InnoDB 支持多种表空间类型，常见有系统表空间、独立表表空间、临时表表空间和撤销表空间。
合理配置和管理表空间有助于数据库的性能、维护和扩展性。
Redo log、Schema、加密表等概念与表空间不同，不属于表空间类型的分类。

Q48

English:
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) Data files could be deleted.
B) Users could overwrite configuration files.
C) SQL injections could be used to insert bad data into the database.
D) Extra startup time would be required for the MySQL server to reset the privileges.
E) MySQL binaries could be damaged, deleted, or altered.

Answer: A, B

中文翻译：

检查时发现 MySQL 安装的数据目录权限变为递归的所有用户可读写执行。运行权限错误的安装有哪些两个主要隐患？
A）数据文件可能被删除。
B）用户可能覆盖配置文件。
C）SQL 注入可用于插入恶意数据。
D）MySQL 启动时需额外时间重置权限。
E）MySQL 二进制文件可能被破坏、删除或篡改。

解析：

A) 数据文件可能被删除。
✅ 正确。任何用户都可以删除数据文件，造成数据丢失。
B) 用户可能会覆盖配置文件。
✅ 正确。如果配置文件权限不当，任何用户都可以修改或替换配置文件，影响数据库安全和服务行为。
C) 可以通过 SQL 注入向数据库插入恶意数据。
❌ 不直接相关。SQL 注入属于应用层安全问题，与文件系统权限无直接关系。
D) MySQL 服务器重置权限时会导致启动时间增加。
❌ 不正确。MySQL 不会在启动时自动修复文件权限，因此不会影响启动时间。
E) MySQL 二进制文件可能被损坏、删除或篡改。
❌ 不正确。MySQL 二进制文件通常不在数据目录。

• 因此答案为 A 和 B。

Q49

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

A) INFORMATION_SCHEMA.INNODB_METRICS
B) SHOW ENGINE INNODB STATUS;
C) INFORMATION_SCHEMA.STATISTICS
D) SHOW STATUS;
E) SHOW TABLE STATUS;
F) INFORMATION_SCHEMA.INNODB_TABLESTATS

A,B

中文翻译：

以下哪两种工具可以用于监控 InnoDB 全局锁定（锁）状态？

A) INFORMATION_SCHEMA.INNODB_METRICS
B) SHOW ENGINE INNODB STATUS;
C) INFORMATION_SCHEMA.STATISTICS
D) SHOW STATUS;
E) SHOW TABLE STATUS;
F) INFORMATION_SCHEMA.INNODB_TABLESTATS

Each Option Explained

A) INFORMATION_SCHEMA.INNODB_METRICS
✅ 正确。该表提供了许多与 InnoDB 相关的全局统计指标，包括锁定相关的计数器和状态。
B) SHOW ENGINE INNODB STATUS;
✅ 正确。该命令能详细显示 InnoDB 引擎的当前状态信息，其中包括锁等待、锁持有等详细锁信息。
C) INFORMATION_SCHEMA.STATISTICS
❌ 只提供表和索引的统计信息，不包含锁相关信息。
D) SHOW STATUS;
❌ 提供全局/会话状态变量，虽然有部分锁相关变量，但不如 A/B 专注和详细。
E) SHOW TABLE STATUS;
❌ 显示表的元数据信息，不包含锁定详情。
F) INFORMATION_SCHEMA.INNODB_TABLESTATS
❌ 提供表级统计数据，不包含具体锁状态信息。

正确答案

A) INFORMATION_SCHEMA.INNODB_METRICS
B) SHOW ENGINE INNODB STATUS;

InnoDB 锁监控相关知识点总结

1. 为什么要监控 InnoDB 锁状态？

InnoDB 存储引擎支持多种锁（如行锁、表锁），用于保证数据一致性和并发安全。
锁冲突、死锁、长时间锁等待会影响数据库性能，甚至导致业务阻塞。
监控锁状态有助于发现和解决性能瓶颈、死锁和慢查询等问题。

2. 主要监控工具及其作用

SHOW ENGINE INNODB STATUS;
- 这是 MySQL 诊断 InnoDB 状态的核心命令。
- 输出详细的 InnoDB 引擎内部状态，包括：
  - 当前等待锁的事务
  - 持有的锁
  - 死锁信息
  - 等待队列
  - 最新的死锁检测信息
- 可用于定位死锁、锁等待和事务冲突等问题。
INFORMATION_SCHEMA.INNODB_METRICS
- 这是一个系统表，记录了大量 InnoDB 内部的性能指标（metrics），许多与锁相关。
- 常见锁相关指标有：
  - lock_row_lock_current_waits：当前正在等待的行锁数量
  - lock_row_lock_waits：历史上发生过的行锁等待次数
  - lock_row_lock_time：累计行锁等待时间
  - 这些指标可以用于监控全局锁等待和锁竞争情况。
- 可定期查询该表，结合监控系统绘制趋势图。

3. 其他相关但不适用的工具

INFORMATION_SCHEMA.STATISTICS
- 仅包含表和索引的统计信息，不包含锁信息。
SHOW STATUS;
- 包含一些全局状态变量，部分变量与锁有关，但粒度有限，不如前两者详细。
SHOW TABLE STATUS;
- 主要显示表的元数据和基本状态，不涵盖锁定信息。
INFORMATION_SCHEMA.INNODB_TABLESTATS
- 提供表级统计信息，不包含锁的实时状态。

4. 实践建议

日常监控可用 INFORMATION_SCHEMA.INNODB_METRICS 获取锁相关统计数据，分析锁等待和冲突趋势。
遇到业务阻塞、死锁、慢SQL等问题时，使用 SHOW ENGINE INNODB STATUS; 获取实时详细锁信息，定位问题。
配合慢查询日志和事务监控工具，综合分析数据库性能瓶颈。

5. 总结

监控 InnoDB 锁状态对于发现和解决数据库并发性能问题至关重要。
最常用的工具为 SHOW ENGINE INNODB STATUS;（实时锁详情）和 INFORMATION_SCHEMA.INNODB_METRICS（全局锁指标）。
其他工具虽能提供部分信息，但不专注于锁监控。

17.7.1 InnoDB 锁机制要点总结

一、共享锁（Shared Lock, S Lock）与排他锁（Exclusive Lock, X Lock）

共享锁（S）：允许事务读取某行，多个事务可以同时持有同一行的共享锁。
排他锁（X）：允许事务更新或删除某行。一个事务持有排他锁时，其他事务对该行的任意锁请求都会被阻塞，直到锁释放。

二、意向锁（Intention Lock）

实现多粒度锁并发（行锁与表锁共存）。
意向共享锁（IS）：表明事务打算在表内某些行加共享锁（如SELECT ... FOR SHARE）。
意向排他锁（IX）：表明事务打算在表内某些行加排他锁（如SELECT ... FOR UPDATE）。
意向锁是表级锁，不阻塞除全表锁外的任何操作，只表明有行级锁的意图。
兼容性示意表（✔️=兼容，❌=冲突）：

X IX S IS

X ❌ ❌ ❌ ❌

IX ❌ ✔️ ❌ ✔️

S ❌ ❌ ✔️ ✔️

IS ❌ ✔️ ✔️ ✔️

	X	IX	S	IS
X	❌	❌	❌	❌
IX	❌	✔️	❌	✔️
S	❌	❌	✔️	✔️
IS	❌	✔️	✔️	✔️

三、记录锁（Record Lock）

行级锁，实际上是索引记录上的锁。即使表没有显式索引，InnoDB 也会用隐藏聚簇索引进行行锁定。
例如：SELECT ... FOR UPDATE 会锁定匹配条件的所有索引记录。

四、间隙锁（Gap Lock）

锁定索引记录之间的“间隙”，防止其他事务在该间隙插入新记录，而不影响已有记录。
主要用于防止幻读，提高一致性。
在唯一索引精确查找时不会使用间隙锁（如主键查找）。
多个事务可同时持有同一间隙锁（无冲突），仅用于抑制插入。

五、Next-Key Lock

Next-Key Lock = 记录锁 + 前间隙锁
用于防止幻读，保证 REPEATABLE READ 隔离级别下的一致性。
锁定范围如：(10, 11]，即锁住11及其之前的间隙。
例子：索引值为10, 11, 13, 20，Next-Key锁可能锁定(10,11]、(11,13]、(13,20]等区间。

六、插入意向锁（Insert Intention Lock）

INSERT操作前在目标间隙上加的特殊锁，表明有插入意图。
允许多个事务并发在同一间隙不同位置插入（互不阻塞），只要不插入同一位置。
典型场景：索引有4、7，事务A插5，事务B插6，二者互不阻塞。

七、AUTO-INC锁

针对含AUTO_INCREMENT字段的表，插入时加的表级特殊锁，保证自增主键值的连续性和唯一性。
可通过innodb_autoinc_lock_mode参数调整锁定算法，权衡自增序列可预测性和并发性能。

八、空间索引谓词锁（Predicate Lock for Spatial Index）

针对SPATIAL空间索引，InnoDB无法像普通索引那样使用Next-Key Lock，因为空间数据无绝对顺序。
InnoDB采用谓词锁（predicate lock），锁住查询涉及的最小包围矩形（MBR），防止其他事务插入或修改与查询MBR重叠的数据，保证一致性。

Q50

English:
You want to dump all databases with names that start with "db". Which command will achieve this?
A) mysqlpump --include-tables=db.% --result-file=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 > all_db_backup.sql

Answer: C

中文翻译：

你想导出所有以 "db" 开头的数据库。以下哪个命令可以实现？
A）mysqlpump --include-tables=db.% --result-file=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 > all_db_backup.sql

解析：

mysqlpump 工具支持用 `--include-databases` 参数配合通配符（%）来筛选数据库名。

A) mysqlpump --include-tables=db.% --result-file=all_db_backup.sql
❌ 错误。--include-tables 用于指定表，不能用于筛选数据库。
B) mysqlpump --include-databases=db --result-file=all_db_backup.sql
❌ 错误。该参数仅匹配名为 "db" 的数据库，不支持通配符。
C) mysqlpump --include-databases=db% --result-file=all_db_backup.sql
✅ 正确。--include-databases=db% 会匹配所有以 "db" 开头的数据库。
D) mysqlpump > all_db_backup.sql
❌ 错误。没有指定要导出的数据库，会导出所有数据库，不能做前缀筛选。

正确答案

C) mysqlpump --include-databases=db% --result-file=all_db_backup.sql

https://dev.mysql.com/doc/refman/8.0/en/mysqlpump.html

6.5.6 mysqlpump — 数据库备份工具

注意：mysqlpump 自 MySQL 8.0.34 起已废弃，后续将被移除。官方建议优先使用 mysqldump 或 MySQL Shell 替代。

主要功能与特性

逻辑备份工具，生成可直接重建数据库对象和数据的 SQL 文件。
支持并行导出多个数据库及其内部对象（表、存储过程、账户等），大幅提升备份速度。
可灵活选择/排除库、表、事件、存储过程、用户等，支持通配符，控制导出内容粒度。
用户账户以 CREATE USER 和 GRANT 语句形式导出，而不是插入 mysql 库表。
支持输出压缩（LZ4、ZLIB），导出进度实时显示。
恢复时 InnoDB 二级索引延后创建，提高导入效率。

常见用法

# 备份所有数据库
mysqlpump --all-databases

# 备份指定数据库
mysqlpump db_name

# 备份数据库的部分表
mysqlpump db_name tbl1 tbl2

# 多数据库备份
mysqlpump --databases db1 db2

# 只导出用户账户，不导出任何数据库
mysqlpump --exclude-databases=% --users

# 推荐在 Windows 下用 result-file 避免编码问题
mysqlpump [options] --result-file=dump.sql

对象选择与过滤

--include-* 和 --exclude-* 可灵活筛选数据库、表、事件、存储过程、触发器、用户等。
通配符 % 匹配任意字符，_ 匹配单字符。
可多次指定，效果叠加。

例：

mysqlpump --exclude-databases=test,world
mysqlpump --include-tables=customer,invoice
mysqlpump --include-databases=db1,db2 --exclude-tables=db1.t1,db2.t2

并行导出

默认每个队列2线程，可用 --default-parallelism=N 设置。
用 --parallel-schemas=[N:]db_list 可为指定库设定线程数，多个参数可创建多个队列。
并行时不同对象的输出顺序可能交错，但不影响恢复。

例：

mysqlpump --parallel-schemas=3:db1,db2 --parallel-schemas=2:db3

常用选项摘要

--all-databases：导出所有数据库
--databases：后续参数都为数据库名
--exclude-databases/--include-databases：排除/包含数据库
--exclude-tables/--include-tables：排除/包含表
--users：以 SQL 语句导出用户账户
--add-drop-database/--add-drop-table/--add-drop-user：导出前加 DROP 语句
--compress-output：指定导出文件压缩算法（LZ4/ZLIB）
--default-parallelism/--parallel-schemas：并行控制
--single-transaction：InnoDB 快照一致性备份
--defer-table-indexes：数据插入后再建索引（默认开启）
--skip-definer：跳过 DEFINER/SQL SECURITY 信息
--watch-progress：显示进度

权限要求

备份表：SELECT
备份视图：SHOW VIEW
备份触发器：TRIGGER
未用 --single-transaction 时需 LOCK TABLES
备份账户需 mysql 库 SELECT 权限

主要限制

默认不导出 performance_schema、ndbinfo、sys、INFORMATION_SCHEMA，如需导出需显式指定。
不导出 InnoDB CREATE TABLESPACE。
不直接导出 mysql 库授权表（user、db 等），如需导出需单独指定表名。
并行导出时，不同对象的输出可能交错，恢复时不受影响。

其他说明

Windows PowerShell 重定向会生成 UTF-16 文件，无法直接恢复，建议用 --result-file。
MySQL Shell 提供更强大的并行备份与云兼容能力，是未来推荐方案。

Q51

English:
Examine this parameter setting:
audit_log=FORCE_LOG_PERMANENT
What effect does this have on auditing?
A) It will force the load of the audit plugin even in case of errors at server start.
B) It causes the audit log to be created if it does not exist.
C) It prevents the audit plugin from being removed from the running server.
D) It prevents the audit log from being removed or rotated.

Answer: C

中文翻译：

查看以下参数设置：
audit_log=FORCE_LOG_PERMANENT
该设置对审计有什么影响？
A）即使服务器启动时出现错误，也会强制加载审计插件。
B）如果审计日志不存在，则创建审计日志。
C）防止审计插件在运行时被移除。
D）防止审计日志被移除或轮换。

解析：

audit_log=FORCE_PLUS_PERMANENT（题目写错了）

这个参数会强制使审计插件（audit plugin）永久加载到 MySQL 服务器中，并且在服务器运行期间不能被卸载或移除。
即使有超级权限用户，也无法使用 UNINSTALL PLUGIN 或 UNINSTALL COMPONENT 命令卸载审计插件，除非重启服务器并移除参数。
各选项解释
A) It will force the load of the audit plugin even in case of errors at server start.
❌ 并不是忽略启动错误强制加载，而是保证插件一旦加载后不可移除。
B) It causes the audit log to be created if it does not exist.
❌ 该参数与日志文件的创建无关。
C) It prevents the audit plugin from being removed from the running server.
✅ 正确。该参数的核心作用就是防止审计插件被卸载。
D) It prevents the audit log from being removed or rotated.
❌ 和日志文件的移除或轮转无关。

FORCE_PLUS_PERMANENT 含义（MySQL 插件加载相关）

FORCE_PLUS_PERMANENT 是 MySQL 插件（如 audit_log）的加载模式选项之一，用于控制插件的加载和卸载行为。

四种常见加载选项

ON：正常加载插件，可以在运行时用 UNINSTALL PLUGIN 卸载。
OFF：不加载插件。
FORCE：强制加载插件，即使遇到错误也尽量加载，但仍可在运行时卸载。
FORCE_PLUS_PERMANENT：强制并永久加载插件，即插件加载后在服务器运行期间不能被卸载，即使有超级权限（UNINSTALL PLUGIN）也无法卸载，只有重启 MySQL 服务才能移除。

应用场景

用于安全、审计等关键插件，防止被恶意或意外卸载，保障插件始终生效。

常见于如下配置：

[mysqld]
plugin-load-add=audit_log.so
audit-log=FORCE_PLUS_PERMANENT

8.4.5.11 MySQL Enterprise Audit Log

https://dev.mysql.com/doc/refman/8.0/en/audit-log-reference.html#sysvar_audit_log_format

1. 基本概述

MySQL Enterprise Audit 提供了审计日志功能，包括日志表、函数、系统变量和状态变量等。
自 MySQL 8.0.34 起，legacy 模式已废弃，推荐使用基于审计表的过滤。

2. 审计日志表

mysql.audit_log_filter：定义过滤规则，存储为 JSON。
mysql.audit_log_user：存储账号与过滤器的关联。
可通过 audit_log_database 变量指定其他数据库存储审计表。

3. 审计日志函数

audit_log_encryption_password_get([keyring_id])
获取当前或指定 keyring_id 的审计日志加密密码（需启用 keyring）。
audit_log_encryption_password_set(password)
设置当前审计日志加密密码，并写入 keyring，触发日志文件轮转。
audit_log_filter_flush()
直接操作审计表后需调用，使更改生效（慎用，所有会话将与 filter 脱离）。
audit_log_filter_remove_filter(filter_name)
移除指定 filter，并解除所有分配给该 filter 的用户过滤。
audit_log_filter_remove_user(user_name)
解除指定用户的过滤器分配，支持 % 代表默认账户。
audit_log_filter_set_filter(filter_name, definition)
添加/更新过滤器定义，已用该 filter 的会话将自动解绑。
audit_log_filter_set_user(user_name, filter_name)
分配过滤器给用户，支持 % 代表默认账户，影响新连接。
audit_log_read([arg])
读取 JSON 格式的审计日志，支持 bookmark、时间戳等参数。
audit_log_read_bookmark()
返回最近事件的 bookmark，可用于增量读取。
audit_log_rotate()
手动轮转审计日志文件（需 AUDIT_ADMIN 权限）。

4. 常用系统变量与选项（部分关键说明）

--audit-log[=value]：控制插件加载（ON/OFF/FORCE/FORCE_PLUS_PERMANENT）。
audit_log_buffer_size：异步写入时的缓冲区大小。
audit_log_compression：日志文件压缩（NONE/GZIP）。
audit_log_connection_policy：连接事件记录策略（ALL/ERRORS/NONE，legacy 模式，已废弃）。
audit_log_database：指定审计表所在数据库。
audit_log_disable：一键禁用所有审计（需 AUDIT_ADMIN 权限）。
audit_log_encryption：日志文件加密（NONE/AES）。
audit_log_exclude_accounts / audit_log_include_accounts：legacy 模式下账户过滤（已废弃）。
audit_log_file：日志文件名（可设绝对路径）。
audit_log_format：日志格式（OLD/NEW/XML/JSON）。
audit_log_max_size：JSON 日志文件总大小上限，超限启动自动清理。
audit_log_policy / audit_log_statement_policy：事件/语句记录策略（legacy 模式，已废弃）。
audit_log_prune_seconds：JSON 日志文件按时间自动清理，单位秒。
audit_log_read_buffer_size：audit_log_read 读取缓冲区大小，默认 32K。
audit_log_rotate_on_size：单个日志文件超指定大小自动轮转。
audit_log_strategy：日志写入策略（ASYNCHRONOUS/PERFORMANCE/SEMISYNCHRONOUS/SYNCHRONOUS）。

5. 状态变量（常见）

Audit_log_current_size：当前日志文件大小。
Audit_log_events：处理过的事件总数。
Audit_log_events_filtered：被过滤（未写入）的事件数。
Audit_log_events_written：实际写入日志的事件数。
Audit_log_events_lost：因缓冲区不足丢弃的事件数（PERFORMANCE 模式）。
Audit_log_total_size：所有日志文件累计大小。
Audit_log_write_waits：异步模式下等待写入的次数。

6. 其他注意事项

审计表和函数需先用官方 SQL 安装，否则插件工作在 legacy 模式（已废弃）。
日志格式推荐使用 JSON，支持更灵活的过滤与增量读取。
多数变量支持动态修改，部分需重启生效。
legacy 相关变量和过滤方式已废弃，后续版本将移除。

Q52

English:
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/libplugin/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) [mysqld] default_authentication_plugin=caching_sha2_password
C) ALTER USER user IDENTIFIED WITH mysql_native_password BY 'password';
D) ALTER USER user IDENTIFIED WITH caching_sha2_password;
E) ALTER USER user IDENTIFIED WITH sha256_password;
F) [mysqld] default_authentication_plugin=mysql_native_password

Answer: C

中文翻译：

你最近将 MySQL 升级到 8.0。客户端出现错误：
Error 2059 (HY000): authentication plugin 'caching_sha2_password' cannot be loaded: /usr/local/mysql/libplugin/caching_sha2_password.so: cannot open shared object file: No such file or directory
以下哪个选项能让客户端连接到 MySQL 服务器？
A）[mysqld] default_authentication_plugin=sha256_password
B）[mysqld] default_authentication_plugin=caching_sha2_password
C）ALTER USER user IDENTIFIED WITH mysql_native_password BY 'password';
D）ALTER USER user IDENTIFIED WITH caching_sha2_password;
E）ALTER USER user IDENTIFIED WITH sha256_password;
F）[mysqld] default_authentication_plugin=mysql_native_password

解析：

• 该错误表示客户端缺少 caching_sha2_password 插件。
• 使用 mysql_native_password 认证插件可兼容旧客户端。
• 因此通过修改用户认证方式为 mysql_native_password 可以解决问题。
• 答案为 C。

A) [mysqld] default_authentication_plugin=sha256_password

❌ 这会将默认认证插件设为 sha256_password，但客户端未必支持。

B) [mysqld] default_authentication_plugin=caching_sha2_password

❌ 这与当前默认设置一致，无法解决问题。

C) ALTER USER user IDENTIFIED WITH mysql_native_password BY 'password';

✅ 正确。将用户的认证方式切换为 mysql_native_password，绝大多数客户端都支持，能解决连接问题。

D) ALTER USER user IDENTIFIED WITH caching_sha2_password;

❌ 认证插件未变，仍会报错。

E) ALTER USER user IDENTIFIED WITH sha256_password;

❌ 客户端未必支持该插件，可能仍无法连接。

F) [mysqld] default_authentication_plugin=mysql_native_password

❌ 该设置允许8.0之前的客户端连接到8.0服务器，但是，该设置应被视为临时设置，而不是长期或永久性解决方案，因为它会导致使用有效设置创建的新帐户放弃提供的改进的身份验证安全性 caching_sha2_password。

8.2.17 Pluggable Authentication（可插拔认证）

基本机制

客户端连接 MySQL 时，服务器根据用户名和主机，从 mysql.user 表查找账户及其对应的认证插件。
找不到插件则报错拒绝连接；找到后由插件实际执行认证并返回结果。
启动参数 --skip-grant-tables 时禁用认证插件，所有客户端可无认证连接（极不安全，仅本地连接可用）。

能力与优势

多认证方式选择：DBA 可为不同账户灵活选择/更换认证方式。
外部认证：支持如 PAM、Windows、LDAP、Kerberos 等外部认证（凭据不存于 mysql.user）。
代理用户（Proxy User）：认证插件可让连接用户以另一个用户身份工作（权限继承）。

MySQL 8.0 常见认证插件

mysql_native_password：传统密码哈希（8.0.34 起废弃，未来移除）。
caching_sha2_password：默认推荐，SHA-256，带缓存和更高安全性。
sha256_password：基础 SHA-256（已废弃）。
cleartext：明文密码传递（配合特定服务端插件用）。
PAM：系统 Pluggable Authentication Modules，支持代理。
Windows：本地 Windows 账户认证，支持代理。
LDAP：基于目录服务的认证，支持代理。
Kerberos：Kerberos 主体认证。
no_login：禁止任何直接登录，仅供代理或特权用途。
socket：基于 Unix socket 文件的本地认证。
FIDO：FIDO 硬件密钥认证（8.0.35 起废弃）。
test：用于测试和开发的插件。

默认认证插件

CREATE USER/ALTER USER 语句如未指定插件，采用 default_authentication_plugin（8.0.27 起支持多因子，分因子判断）。
多因子认证时，只有第一个因子可用 default_authentication_plugin 填充，后续因子必须显式指定插件。

插件安装与使用

内置插件无需安装，外部插件需在服务器和客户端分别安装对应库。
账户创建时指定插件名，或使用默认。
客户端可用 --default-auth=plugin_name 明示，若协议协商需其他插件则以服务器指定为准。
客户端找不到插件库时可用 --plugin-dir=路径 指定插件目录。

客户端/服务端兼容性

客户端与服务端需同时支持对应认证插件，否则无法连接。
不同 MySQL 版本、社区/企业版、不同 connector 之间可能存在兼容性问题。
建议服务端、客户端、连接器及时升级，避免因插件引入或移除导致连接失败。

编写连接器时的注意事项

客户端协议实现需有自身默认认证插件，遇到服务器指定的默认插件不存在时应有降级或回退机制。
典型如 libmysqlclient 默认 mysql_native_password，但遇到新插件会尝试加载。
客户端要支持新认证插件，需链接/加载新版 libmysqlclient 或实现协议细节。

适用性与限制

部分连接器如 Connector/C++、PHP（mysqlnd）仅支持 native 认证（除非动态链接新版 libmysqlclient）。
Windows 认证需域环境，否则只支持本地连接。
代理用户功能取决于认证插件是否支持。
复制和 FEDERATED 访问也需对应客户端插件支持。
第三方连接器需动态链接新版 libmysqlclient 或自行实现协议，才能支持更多认证插件和特性。

总结：

可插拔认证极大增强了 MySQL 认证的灵活性和安全性，支持多种认证方式和外部集成。
选型和升级时要关注插件兼容性、连接器支持度和安全配置。
代理用户、外部认证、无登录账户等高级用法都依赖插件的丰富能力和正确配置。

8.4.1.1 mysql_native_password 插件（Native Pluggable Authentication）

基本介绍

mysql_native_password 是 MySQL 早期的原生认证插件，基于传统的密码哈希方式（未引入可插拔认证前就已存在）。
该插件在 MySQL 服务器端和客户端都内置，无需单独加载或指定库文件。

生命周期与版本变化

MySQL 8.0.34 起：mysql_native_password 插件已废弃（deprecated）。
MySQL 8.4 起：该插件默认禁用。
MySQL 9.0.0 起：该插件被移除，无法再用。

插件文件名

组件	插件名（Plugin Name）
服务器端	mysql_native_password
客户端	mysql_native_password
库文件	无（插件内置，无需单独文件）

安装与使用

服务器端插件内置，无需手动加载，也不能通过卸载禁用（只能通过配置禁用）。
客户端插件内置于 libmysqlclient，所有基于该库的客户端都可用。
客户端连接时可用 --default-auth 明确指定认证插件：
mysql --default-auth=mysql_native_password ...
推荐使用更安全的新认证插件（如 caching_sha2_password），避免继续使用已废弃的 mysql_native_password。
有关可插拔认证的更多信息，见官方文档 Section 8.2.17。

8.4.1.2 Caching SHA-2 Pluggable Authentication（caching_sha2_password 插件）

基本介绍

MySQL 提供两种基于 SHA-256 的认证插件：
- caching_sha2_password（推荐/默认）：支持 SHA-256，具备服务端认证缓存和更广泛特性，性能好。
- sha256_password（已废弃，8.0.16 起不推荐）。
MySQL 8.0 起，caching_sha2_password 成为默认认证插件，取代了已废弃的 mysql_native_password。

优势

服务端维护内存认证缓存，反复连接时认证更快。
支持 RSA 密钥交换，无论服务器 SSL 库类型。
支持 Unix socket 和共享内存协议。
安全性高，支持 TLS/SSL 加密或 RSA 密钥加密密码传输。

插件文件名

组件	插件名（Plugin Name）
服务器端	caching_sha2_password
客户端	caching_sha2_password
库文件	无（内置，无需单独文件）

安装与使用

服务器端和客户端插件均为内置，无需安装或卸载。

创建账户时指定该插件（如未指定插件且默认即为 caching_sha2_password，可省略）：

CREATE USER 'sha2user'@'localhost' IDENTIFIED WITH caching_sha2_password BY 'password';
-- 或（默认插件已设置时）
CREATE USER 'sha2user'@'localhost' IDENTIFIED BY 'password';

更改默认认证插件（my.cnf或my.ini）：

[mysqld]
default_authentication_plugin=caching_sha2_password

安全连接/密码交换

推荐优先使用加密连接（TLS/SSL、Unix socket、共享内存），密码直接明文但通道加密。
若必须用未加密的 TCP/命名管道，需RSA 密钥对加密密码交换：
- 服务器端生成/指定 RSA 密钥对（相关系统变量：caching_sha2_password_private_key_path、caching_sha2_password_public_key_path）。
- 客户端需有公钥文件，或用 --get-server-public-key 选项向服务器请求公钥。
- 连接命令示例：
```
mysql --ssl-mode=DISABLED -u sha2user -p --get-server-public-key
```
- 也可用 --server-public-key-path=文件路径 指定本地公钥。

认证缓存机制

服务端缓存已通过认证的账号密码哈希，后续连接可直接校验缓存，速度更快。
首次连接、新建账号/密码变更/RENAME USER/FLUSH PRIVILEGES 后首次连接，需用安全连接或 RSA 密钥交换，成功后进入缓存。
缓存清理由内置的 sha2_cache_cleaner 审计插件自动完成（如账号变更、FLUSH PRIVILEGES、服务重启等）。

兼容性与安全

caching_sha2_password 是 MySQL 推荐的认证方式，兼容主流 MySQL 客户端和连接器（新版）。
密码从不以明文在网络上传输（即使未加密连接，也用 RSA 加密）。
若客户端不支持该插件，可能需升级或调整认证方式。

总结：

caching_sha2_password 是 MySQL 8.0+ 默认、推荐的高安全认证插件，兼具性能与安全，支持缓存和多种安全连接。
配置 RSA 密钥或 TLS/SSL，可完全避免密码明文暴露。
新系统和新账号应优先采用该认证方式。

Q53

English:
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 keeps InnoDB metadata changes in .sdi files in datadir.
B) MySQL Server stores a copy of the serialized data in the InnoDB user tablespace.
C) MySQL writes SDI to the binary log for distributed backups.
D) MySQL implicitly executes FLUSH TABLES and stores a snapshot backup of the metadata.
E) The metadata is serialized in JSON format in Serialized Dictionary Information (SDI).

Answer: B, E

中文翻译：

你对 MySQL 服务器中的某个模式做了表定义更改。
以下哪两条描述了 MySQL 服务器如何处理表定义更改？
A）MySQL 将 InnoDB 元数据更改保存在 datadir 的 .sdi 文件中。
B）MySQL 服务器将序列化数据副本存储在 InnoDB 用户表空间中。
C）MySQL 将 SDI 写入二进制日志以支持分布式备份。
D）MySQL 隐式执行 FLUSH TABLES 并存储元数据快照备份。
E）元数据以 JSON 格式序列化存储在序列化字典信息（SDI）中。

解析：

• InnoDB 将 SDI 数据存储在其表空间文件中。
• SDI 是以紧凑的 JSON 格式序列化的元数据。
• 其他存储引擎存储于 .sdi 文件。
• 答案为 B、E。

16.6 Serialized Dictionary Information (SDI)

什么是 SDI？

SDI（Serialized Dictionary Information，序列化字典信息）：MySQL 用于以紧凑 JSON 格式序列化存储数据库对象元数据的机制。
SDI 作为数据字典的冗余元数据，提升元数据的可恢复性和一致性。

存储位置

InnoDB：SDI 存储在各自的表空间（tablespace）文件中（不含临时表空间和 undo 表空间）。
NDBCLUSTER：SDI 存储于 NDB 字典。
其他存储引擎（如 MyISAM）：SDI 存储为 .sdi 文件，位于表所在数据库目录下。

特点与作用

SDI 记录仅描述其所在表空间内的表和表空间对象。
SDI 数据通过 DDL 操作（如建表、改表、删表等）和 CHECK TABLE FOR UPGRADE 进行更新。
MySQL 升级版本时不会自动更新 SDI 数据。
SDI 实现了元数据冗余：即使主数据字典不可用，也可通过 SDI 数据恢复元信息（如用 ibd2sdi 工具解析 InnoDB 表空间文件）。
对于 InnoDB，每条 SDI 记录至少占用一个索引页（默认 16KB），但实际存储是压缩的。
对于分区表，SDI 数据存储在第一个分区的表空间文件里。
MySQL 通过内部 API 在执行 DDL 时自动维护 SDI 记录。

总结

SDI 提供了数据字典的冗余、跨引擎的元数据序列化存储，增强了元数据的安全性和可恢复能力。
常用于灾备、迁移、升级、表空间恢复等高级场景。

Q54

English:
Which two statements are true about MySQL Installer?
A) It provides a uniform installation wizard across multiple platforms.
B) Manual download of separate product packages is required before installing them through MySQL Installer.
C) It provides only GUI-driven, interactive installations.
D) It performs product upgrades.
E) It installs most Oracle MySQL products.

Answer: D, E

中文翻译：

关于 MySQL Installer，以下哪两项是正确的？
A）它提供跨多个平台的统一安装向导。
B）需要先手动下载各个产品包才能通过安装程序安装。
C）它只支持图形界面交互式安装。
D）它支持产品升级。
E）它安装大多数 Oracle MySQL 产品。

解析：

A) It provides a uniform installation wizard across multiple platforms.
❌ 错误。MySQL Installer 仅适用于 Windows 平台，不是跨平台工具。
B) Manual download of separate product packages is required before installing them through MySQL Installer.
❌ 错误。MySQL Installer 会自动下载和安装所选产品，无需手动下载各个包。
C) It provides only GUI-driven, interactive installations.
❌ 错误。虽然它有 GUI，但也提供命令行（静默）安装方式。
D) It performs product upgrades.
✅ 正确。MySQL Installer 可以用于升级已安装的 MySQL 相关产品。
E) It installs most Oracle MySQL products.
✅ 正确。MySQL Installer 可安装绝大多数 Oracle MySQL 相关产品（如 MySQL Server、Workbench、Shell、Connector 等）。

总结

正确答案是 D 和 E。

Q55

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

# at 5000324
#191120 14155116 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:16' binlog.000036 | mysql
C) mysqlbinlog --stop-position=500453 binlog.000036 | mysql
D) mysqlbinlog --stop-datetime='2019-11-20 14:55:18' binlog.000036 | mysql

Answer: A

中文翻译：

查看 binlog.000036 二进制日志片段：

# at 5000324
#191120 14155116 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 */;
/*!*/;

rental 表被意外删除，你必须恢复该表。
你已恢复最后一次备份，该备份对应于 binlog.000036 的开始位置。
以下哪个命令可以完成恢复？
A）mysqlbinlog --stop-position=500324 binlog.000036 | mysql
B）mysqlbinlog --stop-datetime='2019-11-20 14:55:16' binlog.000036 | mysql
C）mysqlbinlog --stop-position=500453 binlog.000036 | mysql
D）mysqlbinlog --stop-datetime='2019-11-20 14:55:18' binlog.000036 | mysql

解析：

日志片段分析：

1. # at 5000324
  含义：这是二进制日志文件（binlog.000036）中的一个偏移位置（字节数）。
  通俗理解：binlog 文件从头开始数，第 5,000,324 个字节的位置处有一个事件记录。
  这个位置正好是 DROP TABLE 语句事件的“起始位置”。
1. #191120 14155116 server id 1 end_log_pos 500453 crc32 0x98159515 Query thread_id=9 exec_time=2 error_code=0 xid=1106
  #191120 14155116：事件发生的时间。
  191120 = 2019-11-20（即2019年11月20日）
  14155116 = 14:15:51.16（14点15分51秒16，注意这里格式有点特殊，通常是14:15:51）
  server id 1：产生该事件的 MySQL 服务器 ID（通常用于主从复制环境）。
  end_log_pos 500453：该事件在 binlog 文件中的“结束位置”（字节数）。
  crc32 0x98159515：事件的 CRC32 校验码，用于检测二进制日志完整性。
  Query：表示这是一个 SQL 查询事件。
  thread_id=9：执行该语句的线程 ID。
  exec_time=2：该语句执行用了 2 秒。
  error_code=0：执行时没有错误（0 代表成功）。
  xid=1106：事务编号（对于 DML 事务有用，这里是 DROP TABLE，但同样有编号）。
1. SET TIMESTAMP=1574222116/*!*/;
  含义：设置 SQL 语句的执行时间戳（Unix 时间戳）。
  作用：用于保证在恢复或主从复制时，重放 SQL 的时间与原始一致。
  1574222116：等价于 2019-11-20 14:15:16 UTC。
1. DROP TABLE 'rental' /* generated by server */;
  含义：真正执行的 SQL 语句——删除了名为 rental 的表。
  / generated by server / ：说明这个 SQL 是由服务器自动生成（不是直接由用户输入）。
1. /*!*/;
  含义：binlog 语法中的特殊标记，用于分隔结束。
总结
这个日志片段的意思是：
在 binlog.000036 文件的 5000324 字节处，发生了一个 DROP TABLE rental 的操作，这个事件在 500453 字节处结束。
你要恢复数据时，只需要回放到这个事件开始前的位置（即5000324），就不会执行 DROP TABLE 语句，从而避免 rental 表被删除。

选项解析

A) mysqlbinlog --stop-position=500324 binlog.000036 | mysql
✅ 正确。--stop-position=500324 表示只回放到 500324 字节处（即 DROP TABLE 语句开始之前），不会执行 DROP TABLE。
B) mysqlbinlog --stop-datetime='2019-11-20 14:55:16' binlog.000036 | mysql
❌ 错误。这个时间点在 DROP TABLE 之后，会包含 DROP TABLE。。
C) mysqlbinlog --stop-position=500453 binlog.000036 | mysql
❌ 错误。500453 是 DROP TABLE 语句的结束位置，这样会包含并执行 DROP TABLE。
D) mysqlbinlog --stop-datetime='2019-11-20 14:55:18' binlog.000036 | mysql
❌ 错误。这个时间点在 DROP TABLE 之后，会包含 DROP TABLE。
正确答案
A) mysqlbinlog --stop-position=500324 binlog.000036 | mysql

总结：

要恢复 DROP TABLE 之前的所有操作，mysqlbinlog 的 --stop-position 应设置为 DROP TABLE 语句的起始位置。

Q56

English:
Examine this query and output:

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

Output snippet:

-> 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)

Which two statements are true?
A) The query returns exactly 125 rows.
B) It takes more than 8 milliseconds to sort the rows.
C) The country table is accessed as the first table, and then joined to the city table.
D) 35 rows from the city table are included in the result.
E) The optimizer estimates that 51 rows in the country table have continent = 'Asia'.

Answer: A, C

中文翻译：

查看以下查询及输出：

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

输出片段：

-> 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)

以下哪两项是正确的？
A）查询返回了恰好125行。
B）排序耗时超过8毫秒。
C）country表是第一个访问的表，然后连接city表。
D）city表中包含35行数据。
E）优化器估计country表中continent='Asia'的行数为51。

执行计划结构

阅读顺序
从右到左：没有遇到并列的迭代器之前，都是从右边开始执行；
从上到下：遇到并列的迭代器，都是上边的先开始执行

-> 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)

每一层的详细说明

Sort 排序

Sort: <temporary>.Population DESC (actual time=8.306..8.431 rows=125 loops=1)
- 作用：对下层传上来的 125 行结果，按 city.Population 降序排序。
- 耗时：actual time=8.306..8.431
  注意这里有两个值，第一个值是获取第一行的实际时间，第二个值获取所有行的时间，如果循环了多次就是平均时间，单位毫秒。
  这表示排序操作的开始时间是 8.306 毫秒，结束时间是 8.431 毫秒。
- rows=125：排序前/后的数据行数。

Stream results

Stream results (actual time=0.145..8.033 rows=125 loops=1)
- 作用：数据流式传递到排序层。
- rows=125：收到 125 行数据。

Nested loop inner join 嵌套循环连接

Nested loop inner join (cost=241.12 rows=205) (actual time=0.141..7.787 rows=125 loops=1)
- 经优化器初步估算，合计输出大约 205 行，实际输出 125 行（与真实数据相关）。
- “嵌套循环内连接”：以 country 表为驱动，循环每一亚洲国家，对每个国家再查找其城市。

country 表相关

Filter: (world.country.Continent='Asia') (cost=25.40 rows=34) (actual time=0.064..0.820 rows=51 loops=1)
- 首先对 country 表做 Continent='Asia' 过滤。
- 优化器估计会过滤出 34 行，实际得到了 51 行（表明亚洲国家有 51 个）。
Table scan on country (cost=25.40 rows=239) (actual time=0.059..0.359 rows=239 loops=1)
- 对 country 表做全表扫描。
- 估算有 239 行，实际扫描了 239 行。

city 表相关

Filter: (world.city.Population > 100000) (cost=4.53 rows=6) (actual time=0.030..0.131 rows=2 loops=51)
- 仅保留人口超过 1,000,000 的城市。
- 优化器估算每次查找能找到 6 行，实际平均每个国家大约找到 2 行（loops=51，rows=2/每循环）。
- rows=2 loops=51 的含义：
  - 这里的“rows=2”是每次循环的平均输出行数，不是“每循环恰好2行”。
  - 即对每个国家实际过滤后得到的城市数并不是固定的，有的国家可能没有，有的有1个，有的有多个，只是平均大约2行。
- 总共循环 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)
- 对每个亚洲国家，使用 city 表的 CountryCode 索引查找所有该国的城市。
- 优化器预测每次查 18 行，实际平均查 35 行（每次都可能返回若干行）。
- 总计查找 51 次，每次对应一个国家。

执行流程总结

全表扫描 country，过滤 Continent='Asia' → 得到 51 个国家。
针对每个亚洲国家，索引查找 city（CountryCode=该国Code）→ 每国查出若干城市。
过滤每个城市人口大于 1,000,000。
所有满足条件的城市累加，合计 125 行。
最终按 city.Population 倒序输出结果。

关键字段说明

cost：优化器估算的代价。
rows：估算/实际处理的行数。
actual time：该步骤实际耗时（毫秒）。
loops：该操作执行的次数。

总结要点

执行计划是“倒着看”的，最上面是最后一步，最下面是最先扫描的数据源。
先扫描 country，再 join city，city 用索引查找。
筛选条件分别在对应表的 filter 层执行。
join 后结果集 125 行，排序输出。
优化器估算与实际行数有差异，EXPLAIN ANALYZE 能看到真实执行数据。

A) 该查询正好返回 125 行。

正确。
从 Sort <temporary>.Population DESC (actual time=8.306..8.431 rows=125 loops=1) 可以看出，最终排序操作处理了 125 行数据，说明最终输出结果就是 125 行。

B) 排序这些行花费了超过 8 毫秒。

错误。
actual time=8.306..8.431，这表示排序操作的开始时间是 8.306 毫秒，结束时间是 8.431 毫秒，实际耗费二者差0.125毫秒。

C) country 表作为第一个表被访问，然后与 city 表进行连接。

正确
执行计划中，先执行country.Continent = 'Asia'的筛选。

D) 有 35 行来自 city 表被包含在结果中。

错误。
实际结果中，row x loop 远远大于35，错误。

E) 优化器估计 country 表中有 51 行 continent = 'Asia'。

错误。
执行计划中 Filter (world.country, Continent='Asia') (cost=25.40 rows=34)，优化器估算是 34 行，而实际执行时是 51 行。

结论

正确选项是：A 和 C。

Q57

English:
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(:).
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.

Answer: B C

中文翻译：

查看以下 InnoDB Cluster 参数设置：

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)

部分状态信息：

"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" }
}

永久性网络故障使 host3 被隔离。
以下哪两项是正确的？
A) 当连接重新建立时，部署在 host3 上的实例将自动重新加入集群。
B) host1 挂掉会导致集群不可用。
C) 部署在 host3 上的实例被驱逐出集群，必须使用 cluster.addInstance('host3:3377') 重新加入。
D) 可以使用命令 cluster.setPrimaryInstance() 指定主实例。
E) 部署在 host2 上的实例被选为新的主实例。
F) 发出命令 cluster.switchToMultiPrimaryMode() 失败，无法启用多主模式。

解析：

场景描述

MemberWeight（成员加权）
- 用于决定主节点（primary / leader）选举时投票权重。
- 当前 host1=40、host2=30、host3=40，总投票权 110。
- 举例：若分区，权重更高的一侧有更大机会成为主。
exitStateAction='ABORT_SERVER'（隔离自杀）
- 指定节点若被视为“失联”，采取直接自杀（强制终止 mysqld 进程），以确保只有活跃分区继续服务，降低双活风险。
expelTimeout=1
- 失联节点被驱逐的等待时间仅1秒，极小容忍。
- 被隔离后迅速进入 expelled 或 offline 状态，无法继续投票（最小化脑裂窗口期）。
当前节点状态
- host3 为主（R/W），host1、host2 为只读从节点（R/O）。都显示 ONLINE。
网络故障情景
- host3（主节点）遭遇永久隔离，host1、host2 能互相通信也能互通。

题目分析：
- host3 被永久隔离，但由于 exitStateAction=ABORT_SERVER，它被隔离后立即会kill自身（关闭mysqld），不再对外提供服务。
- host1、host2 组成的分区会基于权重选主，权重70>一半，总权重仍然具备法定人数（一半是55）。
- host3 由于自杀，不会出现继续对外R/W的节点。
- 全程只有一侧服务，另一侧自动终止，不会双活，数据保持一致。

选项分析

A: host3不会自动重连，因为host3已经kill自身，需要人工手动调整（错误）。
B: host1 出故障后集群只剩host2了，未达到大多数节点（法定人数），集群无法正常工作（正确答案）。
C: host3在断网时驱逐出集群，因此必须手动使用 cluster.addInstance('host3:3377')重新加入（正确答案）。
D: InnoDB Cluster 支持管理员通过 cluster.setPrimaryInstance() 强制切换。（待定）。
E: 根据设置，选举权重较高的 host1 成为新的主实例（错误）。
F: 未知或未提供故障信息会导致启用多主模式失败(错误)。

InnoDB Cluster 管理与解散命令

1. 单主与多主模式切换

单主模式（Single-primary）：只有一个主节点（R/W），其余节点为只读（R/O）。
多主模式（Multi-primary）：所有节点都可读写（R/W）。
切换命令（要求所有节点 MySQL 8.0.15+ 且 ONLINE）：
- 切换为多主：Cluster.switchToMultiPrimaryMode()
- 切换为单主：Cluster.switchToSinglePrimaryMode([instance])
  - 指定 instance 参数，则该节点成为新主节点。
  - 不指定，则权重最高的节点为主（权重相同时选 UUID 最小的）。

2. 主节点选举与指定

集群默认自动选举主节点（通过权重）。
可以强制指定主节点（MySQL Shell 8.0.29+）：
- 命令：Cluster.setPrimaryInstance(instance[, options])
  - instance：要指定为主节点的目标节点。
  - runningTransactionsTimeout：可选，指定切换前等待事务完成的超时时间（0-3600 秒）。
选举通常在主节点异常离开时自动触发。

3. 集群成员移除

命令：Cluster.removeInstance(instance[, options])
说明：
- 可随时移除某个实例。
- interactive 选项：是否交互式确认。
- force 选项：强制移除元数据（适用于永久失联的节点）。
- 最后一个 ONLINE 节点无法通过此命令被移除。
- 若被移除节点有未应用的事务，等待 dba.gtidWaitTimeout 秒（默认 60），超时报错或（force=true 时）继续移除。

4. 解散集群

命令：Cluster.dissolve([options])
- 必须在 R/W 节点上操作。
- 移除所有元数据、配置，停用 Group Replication，但数据不会被删除。
- 若有无法访问的节点，推荐先恢复上线再解散，以防 split-brain。
- 若必须强制解散，可用 force: true 忽略失联节点。
- 解散后，原 Cluster 对象变量失效。

5. 交互与安全提示

交互模式下，解散或移除操作会提示是否继续，防止误操作。
强制解散时，失联节点可能继续运行，极易造成脑裂，务必确保这些节点不会再上线。

6. 相关参数说明

MemberWeight：影响主节点选举优先级。
exitStateAction：如 ABORT_SERVER，失去法定人数时自动关闭 mysqld 实例。
expelTimeout：成员失联多少秒后被驱逐（单位秒，1 秒极快）。
dba.gtidWaitTimeout：等待 GTID 事务同步的超时时间（默认 60 秒）。

7. 常用命令小结

-- 切换为多主模式
Cluster.switchToMultiPrimaryMode()

-- 切换为单主模式，并指定主节点
Cluster.switchToSinglePrimaryMode('host1:3306')

-- 强制指定主节点
Cluster.setPrimaryInstance('host1:3306', {runningTransactionsTimeout: 10})

-- 移除成员
Cluster.removeInstance('host2:3306', {force: true})

-- 解散集群（强制）
Cluster.dissolve({force: true})

8. 重要注意事项

解散操作不可逆，需重新 dba.createCluster() 创建。
强制操作前请确认所有失联节点不会再上线，否则极易形成脑裂。
集群管理命令要求在 ONLINE 且 R/W 节点上执行。

关于exitStateAction

运行 MySQL 8.0.12 及更高版本的实例具有 group_replication_exit_state_action 变量，您可以使用 AdminAPI exitStateAction选项进行配置。这控制在意外离开集群时实例执行的操作。默认情况下，该exitStateAction选项为 READ_ONLY,，这意味着意外离开集群的实例将变为只读。如果 exitStateAction设置为 OFFLINE_MODE（从 MySQL 8.0.18 开始可用），则意外离开集群的实例将变为只读并进入离线模式，在此模式下它们会断开现有客户端的连接并且不接受新连接（具有管理员权限的客户端除外）。如果 exitStateAction设置为 ABORT_SERVER，则在意外离开集群的情况下，实例将关闭 MySQL，并且必须重新启动才能重新加入集群。请注意，当您使用自动重新加入功能时，该exitStateAction 选项配置的操作仅在所有重新加入集群的尝试都失败的情况下才会发生。

参考：MySQL 8.0 官方 InnoDB Cluster 管理文档
https://dev.mysql.com/doc/refman/8.0/en/mysql-innodb-cluster.html

Q58

English:
You are asked to review possible options for a new MySQL instance. It will be a large, busy reporting data warehousing instance.

[mysqld]
innodb_data_file_path=

Which two configurations would satisfy long-term storage demands?
• A) ibdata1:12M;ibdata2:12M:autoextend
• B) ibdata1:12M:autoextend
• C) ibdata1:12M;/tmp/ibdata2:12M:autoextend
• D) ibdata1:12M;ibdata2:12M;ibdata3:12M
• E) ibdata1:12M:autoextend;ibdata2:12M:autoextend
• F) ibdata1:12M

Answer: A, B

中文翻译：

你被要求评估新 MySQL 实例的配置选项。该实例将是一个大型繁忙的报表数据仓库。

[mysqld]
innodb_data_file_path=

以下哪两项配置满足长期存储需求？
• A）ibdata1:12M;ibdata2:12M:autoextend
• B）ibdata1:12M:autoextend
• C）ibdata1:12M;/tmp/ibdata2:12M:autoextend
• D）ibdata1:12M;ibdata2:12M;ibdata3:12M
• E）ibdata1:12M:autoextend;ibdata2:12M:autoextend
• F）ibdata1:12M

解析：

A) ibdata1:12M;ibdata2:12M:autoextend
分析：有两个表空间文件，ibdata2 带 autoextend，可以自动增长，满足长期存储需求。
结论：✅ 满足
B) ibdata1:12M:autoextend
分析：只有一个表空间文件，但有 autoextend，可以自动增长。
结论：✅ 满足
C) ibdata1:12M;/tmp/ibdata2:12M:autoextend
分析：ibdata2 在 /tmp 目录下，/tmp 通常为临时空间，可能会被操作系统清理，不适合长期数据存储。
结论：❌ 不推荐用于长期存储
D) ibdata1:12M;ibdata2:12M;ibdata3:12M
分析：三个固定大小的表空间文件，都没有 autoextend，空间用完后无法扩展。
结论：❌ 不满足长期增长需求
E) ibdata1:12M:autoextend;ibdata2:12M:autoextend
分析：只有最后一个文件可以加 autoextend，这里两个数据文件都加了 autoextend，配置不合法，会报错。
结论：❌ 不合法
F) ibdata1:12M
分析：只有一个固定大小的表空间文件，无 autoextend，空间用完无法扩展。
结论：❌ 不满足长期增长需求

Q59

English:
Examine this command, which executes successfully:

mysqldump --master-data=2 --single-transaction --result-file=dump.sql mydb

Which two statements are true?
• A) It is a cold backup.
• B) It executes flush tables with read lock.
• C) It enforces consistent backups for all storage engines.
• D) This option uses the READ COMMITTED transaction isolation mode.
• E) The backup created is a consistent data dump.

Answer: B, E

中文翻译：

查看以下成功执行的命令：

mysqldump --master-data=2 --single-transaction --result-file=dump.sql mydb

以下哪两项是正确的？
• A）这是冷备份。
• B）执行了 flush tables with read lock。
• C）对所有存储引擎强制一致备份。
• D）该选项使用 READ COMMITTED 事务隔离级别。
• E）备份创建的是一致性数据转储。

解析：

A) It is a cold backup.

错误。
冷备份（cold backup）指的是数据库服务停机下的文件级备份。mysqldump 是在线逻辑备份，数据库服务正常运行时执行。
❌

B) It executes flush tables with read lock.

正确。
--single-transaction 结合 --master-data=2 会执行 flush tables with read lock 短暂加锁
✅

C) It enforces consistent backups for all storage engines.

错误。
--single-transaction 只对支持事务的存储引擎（如 InnoDB）保证一致性，不支持事务的表（如 MyISAM）不能保证一致性。
❌

D) This option uses the READ COMMITTED transaction isolation mode.

错误。
--single-transaction 默认在当前会话隔离级别下启动一致性快照，MySQL 默认是 REPEATABLE READ，不是 READ COMMITTED，除非用户显式设置。
❌

E) The backup created is a consistent data dump.

正确。
对于 InnoDB 等事务型表，--single-transaction 能保证备份期间数据一致（快照时刻的一致性）。
✅
。

Q60

English:
Examine this command and output:
txt
+-------------------------------+------------+
| Variable_name | Value |
+-------------------------------+------------+
| Firewall_access_denied | 7 |
| Firewall_access_granted | 4 |
| Firewall_access_suspicious | 3 |
| Firewall_access_cached_entries| 11 |
+-------------------------------+------------+
Which statement is true?
• A) Firewall_access_denied is the number of connection attempts from prohibited hosts that are denied.
• B) Firewall_cached_entries is the number of statements found in the query cache for users in DETECTING mode.
• C) Firewall_access_granted is the number of connections granted from whitelisted hosts.
• D) Firewall_access_suspicious is the number of statements logged as suspicious for users in DETECTING mode.

Answer: D

中文翻译：

题目描述

假设你执行如下命令并得到输出：

+-------------------------------+------------+
| Variable_name                 | Value      |
+-------------------------------+------------+
| Firewall_access_denied        | 7          |
| Firewall_access_granted       | 4          |
| Firewall_access_suspicious    | 3          |
| Firewall_access_cached_entries| 11         |
+-------------------------------+------------+

请判断下列哪项描述是正确的？

A) Firewall_access_denied 是被禁止主机的连接尝试数。
B) Firewall_cached_entries 是 DETECTING 模式下用户在查询缓存中找到的语句数。
C) Firewall_access_granted 是来自白名单主机的被允许连接数。
D) Firewall_access_suspicious 是 DETECTING 模式下被记录为可疑的语句数。

选项解析

选项	是否正确	解析
A	❌	Firewall_access_denied 统计的是被防火墙拒绝的 SQL 语句次数，而不是主机连接次数。
B	❌	Firewall_access_cached_entries 表示已缓存的语句条目数，与 DETECTING 模式无关，也不是查询缓存。
C	❌	Firewall_access_granted 表示被防火墙允许的 SQL 语句次数，而不是主机连接数，也与白名单主机无关。
D	✅	Firewall_access_suspicious 统计的是在 DETECTING（检测）模式下被标记为可疑并记录日志的 SQL 语句数。

正确答案

D) Firewall_access_suspicious 是 DETECTING 模式下被记录为可疑的语句数。

参考说明

MySQL Enterprise Firewall 可以监控、学习、阻断 SQL 语句，变量含义如下：
- Firewall_access_denied：被拒绝的语句次数。
- Firewall_access_granted：被允许的语句次数。
- Firewall_access_suspicious：在 DETECTING 模式下被判定为可疑的语句次数。
- Firewall_access_cached_entries：防火墙已缓存的 SQL 语句条目数量。
DETECTING 模式：即检测模式，记录并分析可疑 SQL，但不阻断。

MySQL Enterprise Firewall 相关知识点总结

Enterprise Firewall 简介

MySQL Enterprise Firewall（企业防火墙）是 MySQL 企业版提供的 SQL 防护功能。它能学习、记录和阻断不符合安全策略的 SQL 语句，有效防止 SQL 注入和异常访问。

主要工作模式

OFF（关闭）：不做任何拦截或记录。
LEARNING（学习）：记录所有执行的 SQL 语句，建立白名单，不做拦截。
DETECTING（检测）：对比白名单，遇到未收录的 SQL 语句时记录为可疑，但不阻断，仅产生警告日志。
PROTECTING（防护）：对比白名单，遇到未收录的 SQL 语句时直接阻断并记录日志。

主要状态变量

变量名	含义说明
Firewall_access_denied	被拒绝的 SQL 语句次数（PROTECTING 模式下拦截）
Firewall_access_granted	被允许执行的 SQL 语句次数（白名单内语句）
Firewall_access_suspicious	在 DETECTING 模式下被记录为可疑的 SQL 语句次数
Firewall_access_cached_entries	当前防火墙缓存的 SQL 语句条目数量

典型运维场景

上线前先用 LEARNING 模式收集业务正常 SQL，生成白名单。
切换到 DETECTING 模式，观察是否有异常 SQL 被记录为可疑，优化白名单。
正式切换到 PROTECTING 模式，阻断所有非白名单 SQL，提升安全性。
通过状态变量监控防火墙工作状态，及时发现异常访问和攻击行为。

注意事项

LEARNING 模式下建议仅在业务稳定、无攻击风险时使用，避免采集到恶意 SQL。
DETECTING 模式不会阻断，但能帮助发现潜在威胁。
PROTECTING 模式下，业务如有新 SQL 需及时更新白名单，否则会被拦截。
防火墙缓存有上限，可通过变量监控缓存命中及溢出情况。

参考链接

Q61

English:
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) Using PREPARED STATEMENTS
• C) Installing and configuring the Connection Control plugin
• D) Avoiding concatenation of SQL statements and user-supplied values in an application

Answer: C

中文翻译：

你希望保护自己的 MySQL 数据库，防止 SQL 注入攻击。下列哪种方法无法实现该目标？

A) 对所有数据库访问都使用存储过程
B) 使用预处理语句（PREPARED STATEMENTS）
C) 安装并配置 Connection Control 插件
D) 在应用层避免拼接 SQL 语句与用户输入的值

选项分析

A) 对所有数据库访问都使用存储过程

并不能自动防止 SQL 注入。存储过程内部如果拼接 SQL 或直接执行用户输入参数，依然可能被注入。
只有配合参数化调用，才可降低风险。
不能单独作为防注入手段。

B) 使用预处理语句（PREPARED STATEMENTS）

预处理语句能有效防止 SQL 注入，因为参数和 SQL 结构分离。
是业界推荐的防护措施。

C) 安装并配置 Connection Control 插件

Connection Control 插件用于防止暴力破解、连接滥用等，不针对 SQL 注入。
并不检查或阻断恶意 SQL 语句内容。
无法防止 SQL 注入。

D) 在应用层避免拼接 SQL 语句与用户输入的值

这是防注入的基本原则之一，能有效避免注入风险。

正确答案

C) 安装并配置 Connection Control 插件

该插件不会防护 SQL 注入，只能限制连接频率和数量。

核心知识点总结

SQL 注入的根本防护措施：参数化查询、预处理语句、避免 SQL 拼接。
存储过程本身不是防注入手段，关键在于其内部实现方式。
Connection Control 插件只能防止恶意连接/暴力破解，无法防止 SQL 注入。
应用层拼接 SQL 是高风险行为，必须避免。

Q62

English:
Which two statements are true about MySQL server multi-source replication?
• A) It relies on relay_log_recovery for resilient operations.
• B) It does not attempt to detect or resolve replication conflicts.
• C) It needs to be re-instanced after a crash to maintain consistency.
• D) It is not compatible with auto-positioning.
• E) It must use GTID replication.
• F) It uses only time-based replication conflict resolution.

Answer: A, B

中文翻译：

关于 MySQL 服务器的多源复制（multi-source replication），下列哪些说法是正确的？（多选）

A) 它依赖 relay_log_recovery 以实现高可用操作。
B) 它不会尝试检测或解决复制冲突。
C) 崩溃后需要重新实例化以保持一致性。
D) 它与自动定位（auto-positioning）不兼容。
E) 必须使用 GTID 复制。
F) 只使用基于时间的复制冲突解决方案。

选项分析

选项	正确性	解析
A	✅	在 MySQL 多源复制（Multi-Source Replication）环境中，relay_log_recovery = ON 对于多线程副本（Multithreaded Replica）的作用是自动修复因崩溃或意外中断导致的事务执行不一致和间隙问题。
B	✅	MySQL 多源复制本身不检测也不解决冲突（如同一表被多个源更新时），需要应用层处理。
C	❌	崩溃恢复依赖于复制机制，不需要重新初始化实例。
D	❌	多源复制兼容自动定位（auto-positioning），可与 GTID 或 POSITION 结合使用。
E	❌	多源复制不强制要求 GTID，也可以用传统 Position 方式。
F	❌	MySQL 没有内置基于时间的冲突解决机制，多源复制不解决冲突，完全依赖用户设计。

补充说明

MySQL 多源复制允许一个从库同时从多个主库接收数据流，但如果数据有交集（如同一张表被多个主库写），冲突不会自动处理。
是否用 GTID、auto-positioning 可根据实际需求灵活配置，并非强制要求。

MySQL 多源复制（Multi-Source Replication）知识点总结

一、基本原理

多源复制（Multi-Source Replication）允许一个从库（replica）并行地从多个主库（source/master）接收并应用事务。
每个主库对应从库上的一个复制通道（replication channel），每个通道独立同步指定源的数据。

二、常见应用场景

多台服务器集中备份到一台服务器
多分片（shard）表合并
多台服务器的数据整合汇总

三、核心特性与注意事项

不检测、不解决冲突：多源复制在应用事务时不做冲突检测与解决，如有冲突需由应用层处理。
每个通道对应不同主库：同一个从库上的多个通道，必须分别连接不同的主库，不能从同一主库建立多个通道。
- 原因：MySQL 通过 server_id 区分复制关系，无法通过通道名区分。
可结合多线程复制：可通过 replica_parallel_workers（8.0.26+）或 slave_parallel_workers 配置多线程，提升数据应用效率。每个通道的线程数一致，不能单独设置。
支持通道级复制过滤：8.0 起，支持为每个复制通道设置过滤规则（如只同步部分库/表），适用于多源有重叠数据场景。
- GTID 模式下若存在“菱形拓扑”，需保证各通道过滤规则一致，否则会有数据一致性风险。

四、相关操作

配置多源复制
启动、停止、重置多源复制
监控多源复制状态

总结：
MySQL 多源复制可用于多主合并、集中备份等场景，但自身不做冲突检测与自动解决，需应用层配合。合理配置通道及过滤规则，能有效提升数据整合与迁移效率。

Q63

English:
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 Initializing of buffer pool  
InnoDB: Error: log file ./ib_logfile0 is of different size 5242880 bytes  
InnoDB than specified in the .cnf file 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] Plugin 'Aborting  
190925 12:49:05 [ERROR] Plugin '/usr/sbin/mysqld: Shutdown complete

Which action would allow the server to start?
• A) Remove ib_logfile0 and ib_logfile1 files from the file system.
• B) Execute mysqladmin flush-logs.
• C) First run mysqld --initialize to refresh the size of ib_logfile.
• D) Create a new ib_logfile0 file of size 26214400.

Answer: A

中文翻译：
你使用了一个已有服务器的新配置，MySQL 服务器启动失败。查看错误日志截取：

190925 12:49:05 InnoDB: 初始化缓冲池，大小=3.0G  
190925 12:49:05 InnoDB: 缓冲池初始化完成  
InnoDB: 错误：日志文件 ./ib_logfile0 大小为 5242880 字节  
与配置文件中指定的大小 26214400 字节不同  
190925 12:49:05 [错误] 插件 'InnoDB' 初始化函数返回错误  
190925 12:49:05 [错误] 插件 'InnoDB' 注册为存储引擎失败  
190925 12:49:05 [错误] 插件 '中止'  
190925 12:49:05 [错误] 插件 '/usr/sbin/mysqld: 关闭完成

哪种操作可以让服务器启动？
• A）从文件系统中删除 ib_logfile0 和 ib_logfile1 文件。
• B）执行 mysqladmin flush-logs。
• C）先运行 mysqld --initialize 来刷新 ib_logfile 的大小。
• D）创建一个大小为 26214400 的新 ib_logfile0 文件。

解析：

ib_logfile0 文件实际大小与配置文件（如 innodb_log_file_size）不一致，导致 InnoDB 插件初始化失败，MySQL 无法启动。

正确处理方法

A) 从文件系统中删除 ib_logfile0 和 ib_logfile1 文件。

原因：
InnoDB 的 redo log（ib_logfile0、ib_logfile1 等）如果和配置中指定的大小不一致，必须先删除旧文件，MySQL 在下次启动时会根据新参数自动重建合适大小的 redo log 文件。
操作步骤：
1. 停止 MySQL 服务。
2. 删除数据目录下的 ib_logfile0、ib_logfile1 文件。
3. 启动 MySQL 服务，系统会自动生成新大小的 redo log 文件。

其它选项解析

B) 执行 mysqladmin flush-logs
- 无法解决日志文件大小不一致的问题。
C) 先运行 mysqld --initialize
- 该命令会初始化整个数据目录，会清空原有数据，用于新实例初始化，不适合已有数据的场景。
D) 手动创建一个新大小的 ib_logfile0 文件
- 不能手动创建空文件，必须由 MySQL 自动生成 redo log。

总结

只需删除旧的 redo log 文件（如 ib_logfile0、ib_logfile1），重启服务即可，数据不会丢失，InnoDB 会自动重建合适大小的日志文件。
切勿手动创建或用初始化命令覆盖原有数据目录。

InnoDB Redo Log（重做日志）知识点总结

一、基本原理与作用

Redo Log（重做日志）是InnoDB用于崩溃恢复的磁盘数据结构。
在正常运行时，所有表数据的更改操作（SQL语句或底层API调用）都会被编码并写入Redo Log。
如果发生意外宕机，未完成的数据文件更改会在MySQL启动初始化时根据Redo Log自动重做，保证数据一致性。

二、Redo Log文件结构与LSN

Redo Log以物理文件方式存储在磁盘上，记录所有被影响的数据修改。
Redo Log中每条记录都与LSN（Log Sequence Number，日志序列号）相关联，LSN不断递增。
数据修改时不断向Redo Log追加新数据；随着检查点（checkpoint）推进，最旧的数据被截断。

三、Redo Log容量配置（MySQL 8.0.30及以上）

用参数 innodb_redo_log_capacity 控制所有Redo Log文件总容量（单位字节），可动态调整。
```
SET GLOBAL innodb_redo_log_capacity = 8589934592;  -- 设置为8GB
```
改变容量后，系统会自动增加或减少文件数量和大小以匹配新设置。
若未设置该参数，则按 innodb_log_file_size * innodb_log_files_in_group 计算容量。
监控变量：
- Innodb_redo_log_capacity_resized：当前Redo Log总容量。
- Innodb_redo_log_resize_status：容量调整状态。
- 其它如 Innodb_redo_log_checkpoint_lsn, Innodb_redo_log_current_lsn 等。
文件位置和命名：
- 默认存放在数据目录下的 #innodb_redo 子目录内（或通过 innodb_log_group_home_dir 指定）。
- 文件名为 #ib_redoN（N为编号），备用文件带 _tmp 后缀。
- 一般维护32个Redo Log文件，每个大小约为总容量的1/32。

文件LSN范围可查询：

SELECT FILE_NAME, START_LSN, END_LSN FROM performance_schema.innodb_redo_log_files;

四、MySQL 8.0.30之前的Redo Log配置

默认有两个Redo Log文件：ib_logfile0 和 ib_logfile1，循环写入。
可通过 innodb_log_file_size 和 innodb_log_files_in_group 配置容量和数量。
修改容量需先停库，修改参数后重启，InnoDB会自动重建日志文件。

五、Redo Log自动配置

若启用 --innodb-dedicated-server，InnoDB会自动根据系统资源分配Redo Log等相关参数。

六、Redo Log归档（MySQL 8.0.17+）

为了解决备份期间Redo Log被覆盖而丢失的风险，引入了Redo Log归档功能。

需设置 innodb_redo_log_archive_dirs，指定归档目录（目录需存在且安全）。

SET GLOBAL innodb_redo_log_archive_dirs='label1:/path/to/archive1;label2:/path/to/archive2';

启动归档：

SELECT innodb_redo_log_archive_start('label', 'subdir');

归档期间，Redo Log会同时写入归档文件，供备份工具读取。
归档操作需持有 INNODB_REDO_LOG_ARCHIVE 权限；归档会话关闭或显式停止后归档文件被移除。

七、禁用Redo Logging（MySQL 8.0.21+）

可通过 ALTER INSTANCE DISABLE INNODB REDO_LOG 禁用Redo Logging，适用于新实例加载数据时提升速度。
警告： 禁用Redo Logging后如遇异常宕机，可能导致数据丢失和实例损坏，仅用于新实例数据导入场景。

启用/禁用Redo Logging需 INNODB_REDO_LOG_ENABLE 权限。

ALTER INSTANCE DISABLE INNODB REDO_LOG;
-- 加载数据
ALTER INSTANCE ENABLE INNODB REDO_LOG;

禁用期间不允许备份和Redo Log归档操作。

八、性能与安全注意

开启归档会略微增加写入负载，归档目录应选用安全且性能合适的磁盘。
禁用Redo Logging仅用于初始化数据，切勿在生产环境下操作。

九、相关监控与查询

查看Redo Log容量、状态和文件信息：

SHOW STATUS LIKE 'Innodb_redo_log_capacity_resized';
SHOW STATUS LIKE 'Innodb_redo_log_enabled';
SELECT * FROM performance_schema.innodb_redo_log_files;

十、参考文档

Q64

English:
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 ACCOUNT LOCK;
• B) ALTER USER baduser@hostname PASSWORD DISABLED;
• C) ALTER USER baduser@hostname MAX_USER_CONNECTIONS 0;
• D) ALTER USER baduser@hostname DEFAULT ROLE NONE;
• E) ALTER USER baduser@hostname IDENTIFIED WITH mysql_no_login;

Answer: A, E

中文翻译

某 MySQL 实例上，账户 baduser@hostname 已被攻破。以下哪两条命令可以阻止该账户的新连接？

A) ALTER USER baduser@hostname ACCOUNT LOCK;
B) ALTER USER baduser@hostname PASSWORD DISABLED;
C) ALTER USER baduser@hostname MAX_USER_CONNECTIONS 0;
D) ALTER USER baduser@hostname DEFAULT ROLE NONE;
E) ALTER USER baduser@hostname IDENTIFIED WITH mysql_no_login;

答案解析

选项	是否能阻止新连接	解析说明
A	✅	`ACCOUNT LOCK` 直接锁定账户，禁止新连接，现有连接不受影响。
B	❌	`PASSWORD DISABLED` 仅禁止通过密码认证登录，存在其他认证方式时无效。
C	❌	`MAX_USER_CONNECTIONS 0` 仅限制每用户最大连接数为0，部分版本无效或已存在连接不受影响。
D	❌	`DEFAULT ROLE NONE` 仅影响默认角色，不影响登录权限。
E	✅	`IDENTIFIED WITH mysql_no_login` 将认证插件切换为 `mysql_no_login`，彻底禁止任何方式登录。

正确答案

A) ALTER USER baduser@hostname ACCOUNT LOCK;
E) ALTER USER baduser@hostname IDENTIFIED WITH mysql_no_login;

Q65

English:
Your MySQL server is running on the Microsoft Windows platform. Which three local connection protocols are available to you?
• A) UDP
• B) TCP/IP
• C) X Protocol
• D) Named Pipes
• E) Shared Memory
• F) SOCKET

Answer: B, D, E

中文翻译：

问题描述

你的 MySQL 服务器运行在 Microsoft Windows 平台。下列哪三种本地连接协议可用？

A) UDP
B) TCP/IP
C) X Protocol
D) Named Pipes
E) Shared Memory
F) SOCKET

答案解析

选项	可用于Windows本地连接	说明
A	❌	UDP 非MySQL本地连接协议。
B	✅	TCP/IP 通用协议，支持本地和远程。
C	❌	非MySQL本地连接协议。
D	✅	Named Pipes，Windows特有的本地通信协议。
E	✅	Shared Memory，仅Windows支持的本地通信方式。
F	❌	SOCKET 仅适用于Unix/Linux平台（如 /tmp/mysql.sock）。

正确答案

B) TCP/IP
D) Named Pipes
E) Shared Memory

MySQL 客户端连接协议与平台支持

https://dev.mysql.com/doc/refman/8.0/en/transport-protocols.html

1. 支持的传输协议及平台

--protocol值	协议类型	适用平台
TCP	TCP/IP	所有平台
SOCKET	Unix socket文件	Unix及类Unix系统
PIPE	命名管道	Windows
MEMORY	共享内存	Windows

2. 本地与远程连接支持

TCP/IP：支持本地和远程连接
SOCKET（Unix socket文件）：仅支持本地连接（Unix/类Unix）
PIPE（命名管道）：仅支持本地连接（Windows）
MEMORY（共享内存）：仅支持本地连接（Windows）

注：命名管道协议在MySQL实现中不支持远程连接。

3. localhost 的解释

未指定协议时：
- Unix/类Unix：localhost 默认用 socket 文件连接
- 其它平台：localhost 默认用 TCP/IP 连接（127.0.0.1）
显式指定协议时：localhost 按所指定协议解释（如 --protocol=TCP 则总是TCP/IP）

4. 安全性与加密

TCP/IP 和 SOCKET 可通过TLS/SSL加密
- TCP/IP 默认不加密，可配置加密
- SOCKET（Unix socket）本地默认安全，也可加密，但加密收益不大
PIPE 和 MEMORY 不支持TLS/SSL加密
- PIPE（命名管道）可通过系统参数限制允许的用户
- MEMORY（共享内存）本地默认安全
require_secure_transport=ON 时，仅允许安全协议（加密TCP/IP、socket、shared memory）

5. 连接压缩

所有协议均支持连接压缩，压缩发生在加密之前。

6. 典型命令选项举例

显式指定协议连接：

mysql --protocol=TCP -h localhost
mysql --protocol=SOCKET -h localhost
mysql --protocol=PIPE -h localhost
mysql --protocol=MEMORY -h localhost

7. 小结

Windows本地可用协议：TCP/IP、PIPE（命名管道）、MEMORY（共享内存）
Unix本地可用协议：TCP/IP、SOCKET（Unix socket）

参考：https://dev.mysql.com/doc/refman/8.0/en/connection-access.html

Q66

English:
Four nodes are configured to use circular replication. Examine these configuration parameters for each node:

slave_parallel_type=DATABASE  
slave_parallel_workers=4  
slave_preserve_commit_order=0

Which statement is true?
• A) Setting slave_parallel_type=DATABASE won't work for circular replication; it should be set to LOGICAL_CLOCK.
• B) Setting slave_preserve_commit_order to ON will improve data consistency.
• C) Cross-database constraints can cause database inconsistency.
• D) Each slave thread is responsible for updating a specific database.
• E) Increasing slave_parallel_workers will improve high availability.
• F) Setting transaction_allow_batching to ON will improve data consistency.

Answer: C

中文翻译：

四个节点配置为使用环形复制。检查每个节点的配置参数：

slave_parallel_type=DATABASE  
slave_parallel_workers=4  
slave_preserve_commit_order=0

以下哪个描述是正确的？
• A）slave_parallel_type=DATABASE 不适用于环形复制，应设置为 LOGICAL_CLOCK。
• B）将 slave_preserve_commit_order 设置为 ON 会提高数据一致性。
• C）跨数据库约束可能导致数据库不一致。
• D）每个从线程负责更新特定数据库。
• E）增加 slave_parallel_workers 会提高高可用性。
• F）将 transaction_allow_batching 设置为 ON 会提高数据一致性。

解析：

参数配置

slave_parallel_type=DATABASE：以数据库为单位的并行复制
slave_parallel_workers=4：并行复制线程数
slave_preserve_commit_order=0：不保证并发事务的提交顺序

各选项分析

选项	正确性	解析说明
A	❌	`slave_parallel_type=DATABASE` 可用于环形复制，但有一致性风险，不是“不能用”。`LOGICAL_CLOCK` 支持跨库并发，但不是强制。
B	❌	将 `slave_preserve_commit_order` 设为 ON（1）会提升数据一致性，但是需要同时设置slave_parallel_type=LOGICAL_CLOCK，该设置在MySQL 8.0.27前不是默认值。
C	✅	跨数据库约束（如外键）可能导致不一致，特别是在并行复制和环形复制场景下，因并发事务顺序不确定。
D	❌	并非每个slave线程只负责一个数据库，线程分配是动态的，按并发事务划分。
E	❌	增加并行线程数提升的是复制性能，并不直接提升高可用性。
F	❌	`transaction_allow_batching` 主要影响批量事务处理，与数据一致性关系不大。

正确答案

C) Cross-database constraints can cause database inconsistency.

结论

环形复制和并行复制条件下，跨库约束风险更高，易因并发顺序不一致导致数据不一致。

slave_preserve_commit_order 中文详解与总结

1. 基本信息

命令行格式：--slave-preserve-commit-order[={OFF|ON}]
系统变量：slave_preserve_commit_order
作用域：全局
动态修改：支持
类型：布尔型
默认值：
- MySQL 8.0.27及以上：ON
- MySQL 8.0.26及以下：OFF
自MySQL 8.0.26起，该变量已弃用，推荐使用 replica_preserve_commit_order。

2. 主要功能

在多线程复制环境（replica_parallel_workers 或 slave_parallel_workers > 0）下，设置 slave_preserve_commit_order=1 可确保从库上的事务按照 relay log 的顺序执行和提交。
这样可防止 relay log 已执行事务序列出现缺口，使从库的事务历史与主库保持一致（有部分限制，见下文）。
该变量对未启用多线程复制的从库无效。

3. 不同版本的行为

MySQL 8.0.27及以后：
- 默认开启多线程复制（replica_parallel_workers=4）。
- slave_preserve_commit_order=ON 是默认值。
- slave_parallel_type=LOGICAL_CLOCK 也为默认值。
- 当 slave_parallel_workers=1 时，该参数被忽略（因顺序天然一致）。
MySQL 8.0.26及以前：
- 默认值为 OFF。
- 需手动开启并行复制和顺序保护。

4. 相关依赖与限制

MySQL 8.0.18及以前：开启该参数需启用 log_bin 和 log_slave_updates（默认已启用）。
MySQL 8.0.19及以后：可在关闭二进制日志的情况下使用。
slave_preserve_commit_order=ON 要求 slave_parallel_type=LOGICAL_CLOCK，该设置在MySQL 8.0.27前不是默认值。
修改该值或并行类型前，需停止复制应用线程。

5. OFF与ON的区别

OFF（默认/关闭）：多线程复制的各worker可并发提交，导致事务提交顺序可能与主库不同，事务序列可能出现缺口，不利于日志追踪与恢复。
ON（开启）：每个worker在事务提交前需等待前序事务提交，保证顺序一致，支持更安全的数据扩展和一致性。

6. 局限性与注意事项

不能防止主库binlog位置延迟，即Exec_master_log_pos可能落后于实际已执行事务的位置。
使用binlog过滤（如 --binlog-do-db）时，无法保证提交顺序和事务历史。
非事务性DML（如MyISAM表），可能会在relay log顺序前提交，导致顺序不一致。
MySQL 8.0.19之前，IF EXISTS语句在对象不存在时，顺序也可能不一致。
混合引擎非XA事务回滚，在某些情况下顺序也可能与relay log不一致。

7. 实用总结

多线程并行复制环境下，为保证主从一致性、便于数据追溯和恢复，建议开启 slave_preserve_commit_order=ON（或新变量名）。
该参数对并行复制高一致性场景（如环形复制、复杂拓扑）尤其重要。
需配合 slave_parallel_type=LOGICAL_CLOCK 使用，并注意相关局限。

8. 参考官方文档

Q67

English:
Examine this command, which executes successfully:

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

Which activity is performed?
• A) MySQL Router is restarted.
• B) MySQL Router configures all the cluster nodes based on the information retrieved from the InnoDB cluster metadata server.
• C) MySQL Router is configured based on the information in files in directory_path.
• D) MySQL Router configures itself based on the information retrieved from the InnoDB cluster metadata server.

Answer: D

中文翻译：

题目

审查以下能成功执行的命令：

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

该命令执行了哪项操作？

A) 重启 MySQL Router。
B) MySQL Router 基于从 InnoDB 集群元数据服务器检索的信息，配置所有集群节点。
C) MySQL Router 基于 directory_path 目录中的文件信息进行配置。
D) MySQL Router 基于从 InnoDB 集群元数据服务器检索的信息，配置自身。

正确答案

D) MySQL Router 基于从 InnoDB 集群元数据服务器检索的信息，配置自身。

翻译与解析

A（错误）：该命令并未重启 MySQL Router，而是执行引导（bootstrap）操作。
B（错误）：MySQL Router 只会配置自身，而不会去配置所有集群节点。
C（错误）：bootstrap 操作是根据 InnoDB 集群元数据服务器的信息来配置，而非仅依赖于本地目录中的文件。
D（正确）：--bootstrap 选项会让 MySQL Router 连接到指定的 InnoDB 集群元数据服务器（由 user@hostname:port 指定），获取集群的连接信息，然后自动生成自身的配置文件并保存在 --directory 指定的目录下，实现自动化配置自身。

MySQL Router `--bootstrap` 相关知识点总结

1. MySQL Router 简介

MySQL Router 是 MySQL 官方提供的轻量级中间件，主要用于在 MySQL 客户端与 MySQL 服务器或 InnoDB 集群之间提供透明的路由和负载均衡。它常用于高可用架构中，简化应用程序与数据库的连接。

2. `--bootstrap` 参数作用

--bootstrap 参数用于初始化 MySQL Router，使其能够自动根据 InnoDB 集群的元数据信息生成自身的配置文件。

语法结构如下：

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

主要流程：
1. MySQL Router 通过 user@hostname:port 连接到 InnoDB 集群的元数据服务器。
2. 获取集群拓扑、节点信息和路由信息。
3. 在 --directory 指定的目录中生成配置文件（如 mysqlrouter.conf），用于后续启动和使用。

3. 相关注意事项

需要使用有足够权限的用户账号进行 bootstrap（通常需要有读取 InnoDB 集群元数据的权限）。
--directory 指定的目录必须存在，且 MySQL Router 有写入权限。
bootstrap 过程只会配置当前 MySQL Router 实例，不会影响其他节点或服务器。
生成的配置文件包含集群连接信息、路由规则、监听端口等关键参数。

4. 常见应用场景

部署高可用 MySQL InnoDB 集群时，快速初始化 MySQL Router 实例。
需要自动感知集群拓扑变化，提高数据库访问的透明性和可用性。
简化客户端对集群的连接配置，避免手动维护复杂的路由规则。

Q68

English:
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 configure the Query Analysis built-in advisor to get notified about slow query execution.
• E) It is possible to list and analyze statements in an arbitrary graph range selection from timeseries graphs.

Answer: D, E

中文翻译：

关于使用 MySQL 企业监控 Query Analyzer，以下哪两项是正确的？
• A）可以检索到规范化语句，但永远无法获取执行的精确语句。
• B）Query Analyzer 视图中的单查询 QRTi 饼图基于所有语句的平均执行时间。
• C）可以从异构源（如 CSV）导入数据到 Query Analyzer。
• D）可以配置 Query Analysis 内置顾问以接收慢查询执行通知。
• E）可以列出并分析时间序列图中任意区间选择的语句。

解析：

A（错误）：Query Analyzer 可以显示归一化（normalized）的 SQL 语句，但也能显示实际执行的原始语句（通过参数和变量等信息），因此不是“永远无法看到原始语句”。
B（错误）：QRTi 饼图（Query Response Time Index）通常基于响应时间分布，而不是所有语句的平均执行。
C（错误）：Query Analyzer 不能从异构数据源（如 CSV）导入查询数据，它只能分析监控到的数据库实例的实时 SQL 查询。
D（正确）：可以配置内置的 Query Analysis 顾问（advisor），在检测到慢查询等性能问题时自动通知用户。
E（正确）：可以在时序图表中自定义选择任意时间范围，对该范围内的 SQL 语句进行列表和分析。

MySQL Enterprise Monitor 将于 2025 年 1 月 1 日起停用并弃用

https://dev.mysql.com/doc/mysql-monitor/8.0/en/

第32章查询分析器视图

https://dev.mysql.com/doc/mysql-monitor/8.0/en/mem-qanal-using.html

MySQL 查询分析器（Query Analyzer）可以监控在 MySQL 服务器上执行的 SQL 语句，并显示每条查询的详细信息、执行次数及执行时间。
具有不同字面值但结构相似的查询会被归并为一条记录进行报告（即语句归一化）。
查询分析器通过 Performance Schema 的 statement digests（MySQL Server 5.6.14 及以上版本支持）收集来自 MySQL 客户端应用程序的 SQL 语句信息。
利用 MySQL Enterprise Monitor Agent，可以无须额外配置，直接从 MySQL 服务器收集数据。
查询分析器的界面允许用户浏览和监控查询、查看执行统计、过滤和深入分析详细信息。
通过将查询数据与服务器图表进行对比，用户可以将查询执行与服务器状态进行关联分析，从而获得更深入的洞察。
有关用户界面和数据报告的更多信息，请参见 32.3 节“Query Analyzer User Interface”。

重点知识点整理

查询分析器主要用于SQL性能监控和优化。
支持自动归一化相似查询，便于统计分析。
无需额外配置即可采集数据（需5.6.14+和 Enterprise Monitor Agent）。
支持多维度查询分析与可视化，能与服务器状态图表关联分析。

Q69

English:
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)
http://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) MySQL server was not started due to a problem while executing process 2732.
• B) systemd found the mysqld service disabled and failed to start it.
• C) MySQL server continued to start up even though another process existed.
• D) systemd waited for 30 seconds before timing out and start up failed.
• E) systemd attempted to start mysqld, found another systemd mysqld process running, and shut it down.

Answer: A

中文翻译：

你刚在 Oracle Linux 上安装了 MySQL，并调整了 /etc/my.cnf 参数以适应安装。
查看以下输出：

# 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)
http://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.

关于启动尝试，以下哪项描述正确？
• A）MySQL 服务器因执行进程 2732 时出现问题未能启动。
• B）systemd 发现 mysqld 服务被禁用，启动失败。
• C）即使存在其他进程，MySQL 服务器仍继续启动。
• D）systemd 等待了 30 秒后超时，启动失败。
• E）systemd 尝试启动 mysqld，发现另一个 systemd mysqld 进程并将其关闭。

解析：

A) MySQL server was not started due to a problem while executing process 2732.

（MySQL 服务器由于执行进程 2732 时出现问题而未能启动。）

解释：systemd 日志明确指出 mysqld 主进程（PID 2732）执行失败（code=exited, status=1/FAILURE），导致服务启动失败。
结论：这是正确答案，完全符合日志内容。

B) systemd found the mysqld service disabled and failed to start it.

（systemd 发现 mysqld 服务被禁用，所以启动失败。）

解释：日志显示 mysqld 服务为 enabled，即已启用（Loaded: loaded ... enabled），不是因为服务被禁用而无法启动。
结论：错误选项，与实际情况不符。

C) MySQL server continued to start up even though another process existed.

（即使存在另一个进程，MySQL 服务器仍然尝试启动。）

解释：日志未显示有其他 mysqld 进程存在或冲突。失败原因是主进程自身异常退出，而不是因为进程冲突。
结论：错误选项，无证据表明有其他进程导致本次失败。

D) systemd waited for 30 seconds before timing out and start up failed.

（systemd 等待了 30 秒后超时，导致启动失败。）

解释：日志未出现任何关于 30 秒超时的提示。错误发生在启动阶段，且很快就失败，而不是超时造成的失败。
结论：错误选项，日志无超时信息。

E) systemd attempted to start mysqld, found another systemd mysqld process running, and shut it down.

（systemd 尝试启动 mysqld，发现有另一个 systemd mysqld 进程在运行，于是将其关闭。）

解释：没有任何日志表明 systemd 检测到另一个 mysqld 进程或因此终止了其他进程。
结论：错误选项，日志无此类描述。

Q70

English:
Examine this query and its output:

select * from sys.user_summary_by_statement_type where statement in ('select','insert','Quit');

+-------+-----------+--------+--------------+------------+-------------+-------------+--------------+---------------+---------------+
| user  | statement | total  | total_latency| max_latency| lock_latency| row_sent    | rows_examined| rows_affected |
+-------+-----------+--------+--------------+------------+-------------+-------------+--------------+---------------+---------------+
| app   | select    | 919866 | 2.41 h       | 330.0 ms   | 1.52 m      | 542614816   | 542614816    | 0             |
| app   | insert    | 923070 | 1.66 h       | 287.41 ms  | 1.65 m      | 0           | 0            | 923026        |
| app   | Quit      | 679892 | 9.54 s       | 170.97 ms  | 0 ps        | 0           | 0            | 0             |
| app   | select    | 344964 | 53.61 h      | 328.42 ms  | 34.51 s     | 203509545   | 203509545    | 0             |
| app   | insert    | 346159 | 37.84 m      | 235.77 ms  | 36.94 s     | 0           | 0            | 346175        |
| bob   | Quit      | 254971 | 3.65 s       | 69.97 ms   | 0 ps        | 0           | 0            | 0             |
| root  | select    | 230621 | 36.88 m      | 21.47 s    | 23.81 s     | 135639074   | 135639074    | 0             |
| root  | Quit      | 170363 | 2.24 s       | 130.14 ms  | 0 ps        | 0           | 0            | 0             |
+-------+-----------+--------+--------------+------------+-------------+-------------+--------------+---------------+---------------+

Which two statements are true?
• A) The app user had the highest total number of rows read from storage engines.
• B) User bob had the largest total time waiting for locks.
• C) The root user had the largest number of modified rows for a select statement.
• D) The root user had the largest single wait time.
• E) User bob had a significantly higher ratio of SELECT + INSERT statements to QUIT than both app and root users.

Answer: A, D

中文翻译：

查看以下查询及其输出：

select * from sys.user_summary_by_statement_type where statement in ('select','insert','Quit');

+-------+-----------+--------+--------------+------------+-------------+-------------+--------------+---------------+---------------+
| user  | statement | total  | total_latency| max_latency| lock_latency| row_sent    | rows_examined| rows_affected |
+-------+-----------+--------+--------------+------------+-------------+-------------+--------------+---------------+---------------+
| app   | select    | 919866 | 2.41 h       | 330.0 ms   | 1.52 m      | 542614816   | 542614816    | 0             |
| app   | insert    | 923070 | 1.66 h       | 287.41 ms  | 1.65 m      | 0           | 0            | 923026        |
| app   | Quit      | 679892 | 9.54 s       | 170.97 ms  | 0 ps        | 0           | 0            | 0             |
| app   | select    | 344964 | 53.61 h      | 328.42 ms  | 34.51 s     | 203509545   | 203509545    | 0             |
| app   | insert    | 346159 | 37.84 m      | 235.77 ms  | 36.94 s     | 0           | 0            | 346175        |
| bob   | Quit      | 254971 | 3.65 s       | 69.97 ms   | 0 ps        | 0           | 0            | 0             |
| root  | select    | 230621 | 36.88 m      | 21.47 s    | 23.81 s     | 135639074   | 135639074    | 0             |
| root  | Quit      | 170363 | 2.24 s       | 130.14 ms  | 0 ps        | 0           | 0            | 0             |
+-------+-----------+--------+--------------+------------+-------------+-------------+--------------+---------------+---------------+

以下哪两项是正确的？
• A）app 用户读取存储引擎的总行数最高。
• B）bob 用户等待锁的总时间最长。
• C）root 用户 select 语句修改的行数最多。
• D）root 用户的单次最大等待时间最长。
• E）bob 用户的 SELECT + INSERT 与 QUIT 语句比率明显高于 app 和 root 用户。

解析：

A) The app user had the highest total number of rows read from storage engines.

分析：rows_examined 字段为“读出的行数”，app 用户 select 查询为 542,614,816，bob 为 203,509,542，root 为 135,639,074。
结论：正确，app 用户确实读出了最多的行。

B) User bob had the largest total time waiting for locks.

分析：lock_latency 字段，app select 1.52m、app insert 1.65m、bob select 34.51s、bob insert 36.94s、root select 23.81s、root insert 31.45s。app 用户总锁等待时间更长（1.52+1.65=3.17分钟），bob 总共 71.45 秒。
结论：错误，app 用户的锁等待总时间更高。

C) The root user had the largest number of modified rows for a select statement.

分析：select 语句 rows_affected 均为 0，没有被修改行，且 select 本应不修改行。
结论：错误。

D) The root user had the largest single wait time.

分析：max_latency 字段，root select 的最大值为 21.47s，其它用户最大为 app select 330.01ms、bob select 328.42ms。21.47s 明显最大。
结论：正确，root 用户确实有最大单次等待时间。

E) User bob had a significantly higher ratio of SELECT + INSERT statements to QUIT than both app and root users.

分析：bob select+insert=344,964+346,159=691,123，QUIT=254,971，比例约2.71。app select+insert=1,842,936，QUIT=679,892，比例约2.71。root select+insert=462,206，QUIT=170,363，比例约2.71。三者比例几乎相同。
结论：错误。

MySQL sys.user_summary_by_statement_type 相关知识点总结

https://dev.mysql.com/doc/refman/8.4/en/sys-user-summary-by-statement-type.html

1. sys.user_summary_by_statement_type 视图简介

该视图属于 MySQL sys 库（性能_schema 的易用封装）。
用于统计每个用户、每种语句类型（如 SELECT、INSERT、QUIT）下的各种执行指标。
常用于分析数据库用户行为、SQL 负载、性能瓶颈和资源消耗。

2. 主要字段说明

user：执行语句的数据库用户。
statement：SQL 语句类型（如 select、insert、Quit）。
total：该用户该类型语句的总执行次数。
total_latency：所有语句累计执行总耗时。
max_latency：单次语句最大耗时（单条语句的极值）。
lock_latency：所有语句累计等待锁的总时长。
rows_sent：select 等语句返回给客户端的行数。
rows_examined：select 语句实际读取的行数（存储引擎层）。
rows_affected：insert/update/delete 语句实际影响（插入/修改/删除）的行数。
full_scans：全表扫描的次数。

3. 典型分析方法

高 rows_examined：说明某用户的查询可能没有利用好索引，存在大量全表扫描，需优化 SQL 或加索引。
高 lock_latency：锁等待时间高，可能有并发冲突或大事务，需优化事务粒度或隔离级别。
高 total_latency/max_latency：累计或单次执行慢，可能有 SQL 复杂、数据量大、硬件瓶颈等问题。
rows_affected 异常：如 select 语句 rows_affected 应为 0，若不为 0 需关注业务逻辑或统计准确性。
QUIT 语句统计：反映连接断开的次数，可辅助分析连接池、应用行为。

4. 性能优化与安全运维应用

通过 sys 视图快速定位“慢用户”、“慢语句”与全表扫描等性能隐患。
结合 rows_examined、lock_latency、total_latency 等指标可有针对性地做 SQL 优化、加索引、调整并发控制等。
按用户分析 SQL 行为，有助于权限收敛、异常行为监控和安全合规。

结论

sys.user_summary_by_statement_type 是 MySQL 性能分析和用户行为洞察的强大工具。掌握其各字段含义和典型用法，有助于数据库性能优化、故障排查和安全运维。

Q71

English:
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) Set validate-user-plugins=caching_sha2_password in the configuration file.
• B) Add default_authentication_plugin=sha256_password in the configuration file.
• C) Add default_authentication_plugin=mysql_native_password in the configuration file.
• D) Define CREATE USER ''@'%' IDENTIFIED WITH sha256_password in the MySQL instance.

Answer: B

中文翻译：

MySQL 安装在 Linux 服务器上，配置如下：

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

哪种方法设置默认认证为 SHA-256 哈希进行用户密码认证？
• A）在配置文件中设置 validate-user-plugins=caching_sha2_password。
• B）在配置文件中添加 default_authentication_plugin=sha256_password。
• C）在配置文件中添加 default_authentication_plugin=mysql_native_password。
• D）在 MySQL 实例中定义 CREATE USER ''@'%' IDENTIFIED WITH sha256_password。

解析：

A（错误）：validate-user-plugins 不是用于设置默认认证插件的参数。
B（正确）：default_authentication_plugin=sha256_password 可以在 MySQL 配置文件（如 /etc/my.cnf）中设置，将所有新用户的默认认证插件设为 sha256_password，即 SHA-256 哈希认证。
C（错误）：mysql_native_password 是 MySQL 传统的认证方式，不是 SHA-256 哈希。
D（部分对，但不是全局默认）：CREATE USER ... IDENTIFIED WITH sha256_password 只会为单个用户设置认证插件，不会更改全局默认认证方式。

总结

设置 MySQL 用户认证方式为 SHA-256 的推荐方法是：
在配置文件中新增 default_authentication_plugin=sha256_password。
这样，所有新建用户默认都会使用 sha256_password 插件，即 SHA-256 哈希进行密码认证。

Q72

English:
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) BLACKHOLE
• B) MEMORY
• C) MyISAM
• D) InnoDB
• E) NDB
• F) ARCHIVE

Answer: B, C, F

中文翻译：

查看以下成功执行的语句：

TRUNCATE test;  
BEGIN;  
INSERT INTO test(id, name) VALUES(1, "HELLO");  
ROLLBACK;  
SELECT id FROM test;

执行这些语句后，哪三个存储引擎会返回非空记录集？
• A）BLACKHOLE
• B）MEMORY
• C）MyISAM
• D）InnoDB
• E）NDB
• F）ARCHIVE

解析：

关键知识点

TRUNCATE 通常是 DDL 操作，不可回滚。对于不支持事务的引擎（如 MyISAM、MEMORY、ARCHIVE），TRUNCATE 立即生效，且后续的 ROLLBACK 不会恢复表内容。
对于支持事务的引擎（如 InnoDB），TRUNCATE 也是隐式提交的 DDL，前面的事务会被强制提交，无法用 ROLLBACK 恢复。
INSERT 后的 ROLLBACK 只会影响支持事务的引擎，但由于 TRUNCATE 已清空表，所以最终表仍为空。
但部分引擎（如 MEMORY、MyISAM、ARCHIVE）不支持事务，ROLLBACK 无效，INSERT 后表有数据。

各存储引擎行为

A) BLACKHOLE：所有数据写入都会被丢弃，表始终为空。不会返回非空结果
B) MEMORY：不支持事务。TRUNCATE 清空表，INSERT 插入数据，ROLLBACK 无效，SELECT 有数据。返回非空结果
C) MyISAM：不支持事务。TRUNCATE 清空表，INSERT 插入数据，ROLLBACK 无效，SELECT 有数据。返回非空结果
D) InnoDB：支持事务，但 TRUNCATE 为隐式提交，无法回滚，INSERT 被回滚，表为空。不会返回非空结果
E) NDB：NDBCluster 支持事务，但 TRUNCATE 也是隐式提交，ROLLBACK 无法恢复，表为空。不会返回非空结果
F) ARCHIVE：不支持事务。TRUNCATE 清空表，INSERT 插入数据，ROLLBACK 无效，SELECT 有数据。返回非空结果

MySQL TRUNCATE TABLE 相关知识点总结

1. 基本作用

TRUNCATE TABLE 用于彻底清空表，而不仅仅是删除部分数据。
需要 DROP 权限。

2. 与 DELETE 的区别

TRUNCATE 是 DDL（数据定义语言），而 DELETE 是 DML（数据操作语言）。
TRUNCATE 实际上是“DROP+CREATE”操作，速度更快，不逐行删除数据。
TRUNCATE 不会触发 ON DELETE 触发器。
TRUNCATE 不返回被删除行的具体数量，通常为“0 rows affected”。

3. 事务与原子性

TRUNCATE 会导致隐式提交（implicit commit），即使在事务中也无法回滚。
对于支持原子 DDL 的存储引擎（如 InnoDB），在 TRUNCATE 过程中如果服务器崩溃，操作要么完全生效，要么完全不生效。
对于不支持事务的引擎（如 MyISAM、MEMORY、ARCHIVE），TRUNCATE 立即生效，ROLLBACK 无效。

4. 外键限制

如果有其他表通过外键引用当前表，InnoDB 和 NDB 不允许 TRUNCATE。
表内自引用外键允许。

5. 其他行为

会重置 AUTO_INCREMENT 计数器。
保留分区定义，仅重建数据和索引文件。
可以用于修复损坏的表（只要表结构有效）。
在二进制日志和主从复制中作为 DDL 处理。
会关闭所有用 HANDLER OPEN 打开的表句柄。
对 Performance Schema 的 summary 表，仅将统计值重置为 0 或 NULL，不删除行。

6. 存储引擎相关

InnoDB 表在 file-per-table 表空间下，会删除旧表空间并新建一个。
目录位置未被系统识别时，新表空间会放在默认数据目录下，并写入警告日志。

结论

TRUNCATE TABLE 是一种高效、不可回滚的清空表操作，属于 DDL，会隐式提交事务。
适用于快速清空大表，但要注意与事务、外键、触发器等特性的兼容性和影响。

Q73

English:
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) Index statistics are calculated from pages buffered in the buffer pool for tables with InnoDB storage engine.
• C) Updating index statistics is an I/O expensive operation.
• D) Execution plans based on transient index statistics improve precision when innodb_stats_persistent_sample_pages is increased.
• E) Setting innodb_stats_auto_recalc=ON causes statistics to be updated automatically when a new index is created.

Answer: C

中文翻译：

关于 InnoDB 持久化索引统计，哪项陈述正确？
• A）增加 innodb_stats_persistent_sample_pages 会提高页面扫描速度，但增加内存使用。
• B）索引统计基于缓冲池中 InnoDB 表的页面计算。
• C）更新索引统计是一个 I/O 密集操作。
• D）基于临时索引统计的执行计划在增加 innodb_stats_persistent_sample_pages 时精度提高。
• E）将 innodb_stats_auto_recalc 设置为 ON 时，在新索引创建后，统计信息会被自动更新。

解析：

A)

此选项不准确。`innodb_stats_persistent_sample_pages` 控制采样页数，数值越大采样越充分，统计信息更精确，但主要影响的是 I/O 消耗和统计精度，而不是页面扫描速度或内存使用。

B) 此选项不正确。统计信息采样通常直接从磁盘读取数据页，而不是仅仅依赖缓冲池中的页面。

D) 此说法容易误导。该参数影响的是持久化统计信息的采样精度，而不是“临时”统计信息。临时统计信息是非持久化的，与该参数关系不大。

E) 此选项不完全准确。当向已有表添加索引，或添加/删除列时，无论 innodb_stats_auto_recalc 的取值如何，索引统计信息都会被计算并添加到 innodb_index_stats 表中。

InnoDB 持久化优化器统计信息知识点总结

https://dev.mysql.com/doc/refman/8.0/en/innodb-persistent-stats.html

1. 持久化统计信息的作用与原理

作用：将表和索引统计信息持久化存储到磁盘（mysql.innodb_table_stats 和 mysql.innodb_index_stats），即使 MySQL 重启后也不会丢失，提升优化器计划的稳定性和查询性能一致性。
启用方式：
- 全局参数：innodb_stats_persistent=ON（默认开启）。
- 单表设置：STATS_PERSISTENT=1。
作用机制：
- 以前统计信息在重启后丢失，需重新采样，导致执行计划可能变化。
- 持久化后，优化器每次选择更稳定。

2. 自动与手动统计信息更新

自动更新：
- 参数：innodb_stats_auto_recalc=ON（默认开启）。
- 触发条件：当表有超过10%行发生变化时，后台自动异步更新统计信息。
- 单表可用 STATS_AUTO_RECALC=1 控制。
- 自动更新有延迟（几秒内完成），如需立刻更新需手动执行。
手动更新：
- 使用 ANALYZE TABLE 命令可强制同步更新统计信息，推荐在大批量数据变更后或性能调优时使用。

3. 采样页数与统计精度

innodb_stats_persistent_sample_pages：
- 控制采样页数，默认 20。
- 采样页数越大，统计越精确，但 ANALYZE TABLE 等操作耗时和 I/O 开销越大。
- 可通过 ALTER/CREATE TABLE 的 STATS_SAMPLE_PAGES 覆盖单表设置。
- 采样太少可能导致执行计划不准确，采样太多会拖慢统计更新。

4. 统计信息底层表结构

mysql.innodb_table_stats：
- 记录数据库、表、最后更新时间、行数、主索引页数、其他索引页数。
mysql.innodb_index_stats：
- 记录数据库、表、索引、统计项目名（如 size、n_leaf_pages、n_diff_pfxNN）、对应值、采样页数、统计描述。
- n_diff_pfxNN 反映索引前 N 个列的基数，有助于优化器判断索引选择性。

5. 统计信息的局部性和复制

持久化统计信息为本地信息，不会在主从之间自动复制。
手动运行 ANALYZE TABLE 时，SQL 会同步到从库，触发从库各自重新统计。

6. 统计参数表的维护与应用

可以手动更新 innodb_table_stats 和 innodb_index_stats，用于测试或强制特定优化计划，但需 FLUSH TABLE 让 MySQL 重新加载。
查询这些表可获知表/索引的实际统计信息和最后更新时间。

7. 特殊说明

新建索引或表结构变更后，无论 innodb_stats_auto_recalc 状态如何，都会自动采样更新统计信息。
可以为单表在 CREATE/ALTER TABLE 时指定三大统计参数（持久化、自动重算、采样页数）。

总结

InnoDB 持久化优化器统计信息提升了查询计划的稳定性和一致性，是大规模数据库系统性能调优的重要基础。
合理调整采样页数和自动更新策略，可兼顾统计精度和系统性能。
相关底层表（innodb_table_stats 和 innodb_index_stats）可为高级优化和故障分析提供依据。

Q74

English:
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 written to the relay log on the slave.
• B) It is the time between the most recent transaction applied by a SQL thread and the time it was committed on the master.
• C) It is the time between the most recent transaction written to the relay logs and the time it was committed on the master.
• D) 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.

Answer: B

中文翻译：

你执行了以下命令：
SHOW SLAVE STATUS;
输出中有 Seconds_behind_master 字段。该时间是如何计算的？
• A）I/O 线程收到主服务器最后事务详情与写入从服务器 relay log 之间的时间。
• B）SQL 线程应用最近事务与该事务在主服务器提交时间的差值。
• C）最近事务写入 relay log 与其在主服务器提交时间的差值。
• D）I/O 线程收到主服务器最后事务详情与 SQL 线程应用该事务的时间差。

解析：

题干含义：
在 MySQL 复制架构中，执行 SHOW SLAVE STATUS; 命令时，输出中会出现 Seconds_behind_master 字段。此字段代表从服务器（slave）滞后于主服务器（master）的秒数。题目问，这个时间是如何计算的？
选项分析
- A: 它是 I/O 线程接收到主库最后一个事务详情，并写入到从库中继日志（relay log）之间的时间差。
  - 解释：此描述只涉及 relay log 的写入，并没有涉及 SQL 线程的应用。
- B: 它是 SQL 线程应用的最新事务，与该事务在主库提交时间的差值。
  - 解释：这一项直接将 slave 上应用的最后的事务和 master 上该事务提交的时间进行对比，正好符合 Seconds_behind_master 的实际含义（正确答案）。
- C: 它是 relay log 最新写入的事务，与该事务在主库提交时间的差值。
  - 解释：此选项关注 relay log，而实际 Seconds_behind_master 更关注事务已被应用的程度（即 SQL 线程）。
- D: 它是 I/O 线程接收到主库最后一个事务详情，并被 SQL 线程应用之间的时间差。
  - 解释：此选项描述不是 Seconds_behind_master 字段的计算方式。

正确答案：B

Seconds_Behind_Master

字段含义
- “Seconds_Behind_Master”表示当前从库正在处理的事件，与该事件在主库上被记录下来的时间戳之间的差异（以秒为单位）。
- 如果从库没在处理事件，这个值就是0。
工作原理与适用条件
- 理论上，这个字段反映的是从库SQL线程与I/O线程时间上的落后情况。
- 仅在网络较快的环境中能准确表示从库“落后”主库的时间。
  如果网络慢，则该值经常为0，但I/O线程实际上可能已严重落后主库。
受系统时间影响
- 只要主库和从库之间相对时间差保持恒定（如NTP同步未改变），该值有效。
- 如果有系统时间校正（如NTP自动对时），可能导致该值不准确。
值为NULL的情况
- MySQL 5.7及以后的版本：如果从库SQL线程没运行，或SQL线程已处理完全部relay log且I/O线程也没运行，则该值为NULL。
- 旧版本：只要SQL线程/I/O线程没运行或断连就为NULL。
- 如果I/O线程在运行但relay log已用尽，“Seconds_Behind_Master”显示为0。
特殊情况与局限性
- 该值依赖于binlog中保存的事件时间戳。
- 如果主机M1自己是另一个主库M0的从库，并且有直接写入，则其“Seconds_Behind_Master”数值会随机波动——有时反映M0，有时反映M1本地的直接操作。
- 在多线程复制（多SQL线程）时，这个值基于Exec_Master_Log_Pos，并不代表最新已提交的事务的延迟。

中文翻译：

你的 MySQL 实例每天在 finance 数据库中捕获大量财务交易。
公司政策是每天创建备份。
主要更新的表以 transactions- 为前缀。
这些表每月归档到以 archives- 为前缀的表。
执行命令：

mysqlbackup --optimistic-busy-tables="^finance\.transactions.*" backup
哪种优化过程最能描述 redo 日志的处理方式？
• A）只有当 transactions 表有变更时才备份 redo 日志。
• B）先备份 transaction 表，再备份 archive 表和 redo 日志。
• C）先备份 redo 日志，再备份 transaction 和 archive 表。
• D）不备份 redo 日志。
• E）先备份 archive 表，再备份 transaction 表和 redo 日志。

解析：

• 选项 E 正确，--optimistic-busy-tables用正则表达式指定“活跃表”（常写入，推迟备份），transactions被推迟备份

MySQL Enterprise Backup 性能/扩展性/容量相关选项

1. 主要选项摘要及作用说明

--number-of-buffers=NUM
- 指定多线程操作时使用的缓冲区数量，每个缓冲区16MB。
- 默认14个，需≥读/写/处理线程的总数，压缩、单文件备份等还会增加1-2个缓冲区。
- 压缩、增量备份时单位缓冲区稍大以存储头信息。
- 若要提高并发和性能（如压缩场景），可适度增大。受--limit-memory限制。
--read-threads=NUM
- 备份、恢复等操作时从磁盘读取数据的线程数。
- 默认1，最大15。0或负数都会被自动调整。
- 特别说明：单文件恢复、apply-log等操作时总是1。
- 多线程读适用于RAID、高I/O性能设备。
--process-threads=NUM
- 负责数据处理（压缩/解压、加解密、apply-log、打包等）的线程数。
- 默认6，最大15。0或负数将被自动调整。
- 增量应用/日志恢复等操作以此设置Apply log的worker数。
--write-threads=NUM
- 用于写盘的数据写线程数。
- 默认1，最大15。非seekable目标或单文件备份始终使用1。
- 复制/恢复大数据可提升写入性能，适合RAID、高速SSD。
--limit-memory=MB
- 限制mysqlbackup进程最大可用内存（单位MB）。
- 影响总能分配的16MB缓冲区数，例如400MB约支持25个buffer（实际视操作类型）。
- 若增大线程或buffer需同步增大此值避免因内存不足报错。
- apply-log（非解压场景）默认100，其它操作400。
--sleep=MS
- 在每处理完16MB数据后睡眠指定毫秒数，用来降低对生产数据库的I/O和CPU压力。
- 默认0（不主动sleep），适用于需限制备份带宽的场景。
--no-locking
- 备份期间完全不加锁，极少干扰业务，但会导致InnoDB和非InnoDB数据可能不一致。
--page-reread-time=MS 和 --page-reread-count=NUM
- 在读取页面（比如页校验错误）时重读时长与次数，增加可应对Io忙碌时数据页写入并发的情况。
- 默认100ms/次与500次，防止偶发IO异常导致备份失败。
--on-disk-full={abort|abort_and_remove|warn}
- 遇到磁盘空间不足时的处理行为：仅中止（并保留目录）、中止并删除目录、持续警告+等待。
--skip-unused-pages
- 备份时跳过InnoDB未使用的页面（如TRUNCATE或大量DELETE后）。能缩小备份包，但恢复时需重填这些空间，会更慢。
--skip-binlog --skip-relaylog
- 跳过二进制日志或复制中继日志，仅在你不需要Point-in-Time恢复或Binlog同步时使用，以节省空间和I/O。
--no-redo-log-archive
- 跳过执行备份时的redo log归档（8.0.17+适用）。
--optimistic-time, --optimistic-busy-tables
- --optimistic-time指定某时间点前未改动的表作为“非活跃表”最早备份。
- --optimistic-busy-tables用正则表达式指定“活跃表”（常写入，推迟备份），两者冲突时以busy-tables为准。
--free-os-buffers[=NUMBER]
- 通知系统（Linux下的posix_fadvise等）释放部分文件系统缓存，有助减少备份对数据库主机其它进程的影响。

2. 使用建议

RAIDS/SSD场景、超大数据库、线上不停服建议：
[多线程+大缓冲]+[合理memory限制]+[适当sleep/释放OS缓存]。
普通SATA机械硬盘、内存较小的节点：
维持默认缓冲数和线程数，避免过多并发导致I/O打满。
需要备份一致性的情况下不要使用--no-locking。

3. 综合结论

调优这些参数可以极大提升MySQL Enterprise Backup在不同硬件环境下的效率和对业务的影响控制。
务必结合自身硬件容量和备份时段业务压力作动态调整。
避免使用--skip-unused-pages与--no-locking等仅适合特殊需求的选项，常规备份应优先保证一致性与完整性。

高亮提示：

多线程和大内存buffer需成正比调整，且受总内存限制。
跳过日志和锁机制只适合极端“只做物理冷备份、数据不变”场景，否则请慎用。
优化选项在大表/高并发/数据量极大/压缩场景尤为重要。

4.3.6 Making an Optimistic Backup

一、乐观备份（Optimistic Backup）的背景和用途

乐观备份是一种提升超大数据库（TB级别）备份与恢复性能的技术，适用于仅少数表频繁变更而大部分表很少修改的场景。
问题背景：普通热备份大库时会产生大量 redo 日志，mysqbackup 处理速度赶不上日志写入速度，可能导致备份失败或日志应用（apply-log）极慢，尤其在 I/O 资源有限时问题更突出。

二、乐观备份的工作流程

乐观阶段（Optimistic phase）：
- 用户指定“不太可能被修改”的表（inactive tables），这些表直接被无锁备份。
- 在此阶段，mysqlbackup 不备份 redo log、undo log、系统表空间，因假设这些表在备份期间不会被更改。
普通阶段（Normal phase）：
- 剩余（频繁变更）的表（busy tables）采用常规热备份方式（含加锁、复制 redo log/undo log/表空间等）。

三、乐观备份命令示例

按变更时间选择 busy/inactive tables（optimistic-time）：

mysqlbackup --defaults-file=/xxx/my.cnf --optimistic-time=110516120000 --backup-image=xxx --backup-dir=xxx backup-to-image

含义：2011年5月16日中午后被修改的表视为 busy 采用普通备份，其余表视为 inactive 走乐观备份。

全部视为 inactive（optimistic-time=now）：
mysqlbackup --defaults-file=/xxx/my.cnf --optimistic-time=now --backup-image=xxx --backup-dir=xxx backup-to-image
明确按表名正则指定 busy tables（optimistic-busy-tables）：
mysqlbackup --defaults-file=/xxx/my.cnf --optimistic-busy-tables="^mydatabase\.mytables-.*" --backup-image=xxx --backup-dir=xxx backup
两者同时用时，optimistic-busy-tables 优先生效。

四、效果与注意事项

若 inactive tables 在备份期间确实无变更，多数用户可大幅缩短备份和恢复时长（redo log 较小，apply-log 极快）。
若实际 inactive tables 变更较多，乐观备份优势变小，甚至不如普通备份。
限制：
不支持增量/可运输表空间（TTS）备份。
备份期间禁并行执行 DDL，否则失败。

五、乐观备份与增量乐观备份结合使用

通过每周全备+每日乐观增量备的方案，显著提升大库备份效率。
还原时先还原全备，再依序恢复相应日期的增量备。

六、知识点总结

乐观备份能极大提升大库恢复/备份效率（假设活跃表很少）
inactive table 识别准确为关键
不支持与增量/可运输表空间一起用
备份期间严禁 DDL
乐观备份+乐观增量备份可灵活配合做高频高效备份策略

Q76

English:
You are considering using file-system snapshots to back up MySQL.
Which three statements are true?
• A) They take roughly twice as long as logical backups.
• B) They allow direct copying of table rows with operating system copy commands.
• C) They work best for transaction storage engines that can perform their own recovery when restored.
• D) The backup window is almost zero from the perspective of the application.
• E) They do not use additional disk space.
• F) They do not back up views, stored procedures, or configuration files.
• G) There is a slight performance cost while the snapshot is active.

Answer: C, D, G

中文翻译：

你考虑使用文件系统快照备份 MySQL。
哪三项陈述是正确的？
• A）它们大约比逻辑备份耗时两倍。
• B）允许使用操作系统复制命令直接复制表行。
• C）对能执行自身恢复的事务存储引擎效果最好。
• D）从应用角度看备份窗口几乎为零。
• E）不使用额外磁盘空间。
• F）不备份视图、存储过程或配置文件。
• G）快照活动期间存在轻微性能开销。

解析：

A: 需要的时间比逻辑备份多一倍 —— 错误。文件系统快照几乎是瞬时的，备份窗口远短于逻辑备份。
B: 允许直接使用操作系统命令复制表行 —— 错误。文件级别快照实际上是拷贝整个数据文件，而不是单个表行，不是直接复制表数据。
C: 对能够自恢复的事务型存储引擎（如 InnoDB）效果最好 —— 正确答案。因为这类引擎在恢复时能自动处理崩溃恢复（如回滚/重做日志），保证数据一致性。
D: 从应用程序角度看，备份窗口几乎为零 —— 正确答案。快照创建几乎不影响正常业务，新快照产生的“冻结数据”后可以慢慢拷贝。
E: 不会占用额外磁盘空间 —— 错误。快照本身不立即占空间，但快照期间新增或修改的数据会占用额外空间；所以“不会占用”说法错误。
F: 不会备份视图、存储过程或配置文件 —— 错误。文件系统快照会把所有物理文件（包括表、视图定义、存储过程、配置文件）都备份，除非这些项存储于外部或独立文件。
G: 快照激活期间有一点性能开销 —— 正确答案。快照机制会引入少量性能损耗（如写时复制带来一定额外 I/O 和管理开销）。

文件系统快照详细介绍

1. 定义与基本原理

文件系统快照（Filesystem Snapshot）是一种在特定时刻“冻结”整个文件系统状态的技术。它可以在几乎瞬间创建一个文件系统的只读或读写副本，这个副本反映了快照生成瞬间的数据内容。

核心机制：大多数快照实现采用“写时复制”（Copy-on-Write, COW）或“重定向写入”（Redirect-on-Write），即：
- 创建快照时，原始数据块不会复制。只有在快照后发生写操作时，原始数据块才会被复制到快照区域，保证快照内容保持原样。

2. 常见快照类型和主流平台

LVM 快照（Linux Logical Volume Manager）
ZFS 快照（常用于 Solaris、FreeBSD、Linux）
Btrfs 快照（Linux）
Windows VSS（卷影复制服务，Volume Shadow Copy Service）

3. 典型应用场景

数据库物理备份（如 MySQL、PostgreSQL、Oracle 等大型数据库应用）
文件服务器的高频定期备份／数据回滚点
保障数据一致性（如结合应用锁定、一致性暂停点）

4. 优势

极快的备份窗口：快照操作几乎瞬间完成，能最大程度减少对业务的影响。
一致性保障：配合事务型存储引擎（如 InnoDB），快照可以获得崩溃恢复级别的数据一致性。
高效还原：恢复速度快，尤其可直接将快照挂载或回滚。
节省空间：仅对快照后被修改的数据块生成额外存储（增量存储），初始占用空间极小。

5. 局限与注意事项

非零存储成本：随着原文件不断变更，快照会占用越来越多的存储空间。
不适合无事务型引擎：如 MyISAM 存储引擎等非事务型表，快照无法保证写一致性，可能导致还原后数据损坏。
元数据或外部资源不能快照：比如数据库配置文件、外部依赖项（如独立配置目录）可能需要单独备份。
激活期间有性能开销：部分平台下，快照存在额外的管理负担和写放大效应，影响 I/O 性能。

6. 使用建议与最佳实践

对于数据库，建议在创建快照前：
- 配合数据库进行表锁定或 flush tables with read lock，或使用类似“FLUSH TABLES WITH READ LOCK”保证一致性（尤其是混合引擎情况）。
- 清除未提交事务，针对事务型引擎，可以直接利用快照的崩溃恢复能力。
监控快照磁盘空间，及时清理过期快照，避免空间爆满。
日常定期测试快照恢复流程，确保数据可靠性和操作可行性。

7. 常见命令举例（以 LVM 为例）

创建快照：
lvcreate -L 5G -s -n my_snapshot /dev/vg_data/my_volume
挂载快照：
mount /dev/vg_data/my_snapshot /mnt/snapshot
删除快照：
lvremove /dev/vg_data/my_snapshot

Q77

English:
Which two methods allow a DBA to reset a user's password?
• A) mysql_secure_installation utility
• B) mysqladmin client program
• C) GRANT statement
• D) ALTER USER statement
• E) SET PASSWORD statement

Answer: D, E

中文翻译：

哪两种方法允许 DBA 重置用户密码？
• A）mysql_secure_installation 工具
• B）mysqladmin 客户端程序
• C）GRANT 语句
• D）ALTER USER 语句
• E）SET PASSWORD 语句

解析：

A: mysql_secure_installation 工具
该工具用于初始化数据库安装后的安全加固，如设置 root 密码、移除匿名用户、禁止远程 root 登录等。虽然能初始化 root 密码，但不是通常意义下的重置任意用户密码工具，通常仅用于初始安全配置，不能随时用来重置所有普通用户密码。因此一般认为不是通用密码重置方法。
B: mysqladmin 客户端程序
只能改自己的
C: GRANT 语句
主要用于授权，不用于直接设置密码。MySQL 5.7 之前可以通过 GRANT USAGE ON *.* TO 'user'@'host' IDENTIFIED BY 'pwd' 间接重置，但新版本已废弃这种方式，且官方不推荐。目前不推荐用 GRANT 直接重置密码。
D: ALTER USER 语句
用于更改用户属性，包括密码重置，例如：
ALTER USER 'user'@'host' IDENTIFIED BY 'new_password';

是标准、推荐的密码重置命令。正确。

E: SET PASSWORD 语句
该语句直接用于设置用户密码。正确。

MySQL 密码修改相关内容总结

1. 密码修改的前置要求

密码到期：当账户的密码被设为过期（手动或自动），用户必须修改密码后，才可以进行其他操作。
- 手动过期示例：ALTER USER 'username'@'host' PASSWORD EXPIRE;
- 达到全局或账户级到期策略时客户端连接会收到要求重设密码的提示。
- 修改密码后账户恢复正常访问权限。
密码重用限制：防止用户将新密码设置为最近用过的旧密码。
- 可以全局设定或单独为账户设定“历史长度”和“最短重用间隔天数”。
- 示例（最近6次不可重用、365天内不可重用）：
```
[mysqld]
password_history=6
password_reuse_interval=365
```

2. 密码修改的具体政策

密码验证要求（验证当前密码）
- 可配置要求用户在修改密码时必须提供当前旧密码，防止他人盗用已登录会话修改密码。
- 用法举例：
  - 要求新密码必须验证当前密码：
```
ALTER USER 'jeffrey'@'localhost'
  IDENTIFIED BY 'new_auth_string'
  REPLACE 'current_auth_string';
```
  - 相关系统变量: password_require_current
    - ON：必须提供当前密码
    - OFF：可选提供
  - 针对单个账户可用 PASSWORD REQUIRE CURRENT|CURRENT OPTIONAL|CURRENT DEFAULT 控制。
- 管理员有 CREATE USER 或 UPDATE mysql 数据库权限时，可直接重设任意账户密码，无需提供旧密码。

3. 密码修改常用操作举例

普通修改密码

ALTER USER 'username'@'host' IDENTIFIED BY 'new_password';

带旧密码验证修改密码
```
ALTER USER 'username'@'host'
  IDENTIFIED BY 'new_password'
  REPLACE 'old_password';
```
- 只有开启了"当前密码验证"策略时REPLACE子句为必需。
退出密码过期状态
- 需先修改密码，否则只能执行有限命令。
- 如：ALTER USER USER() IDENTIFIED BY 'new_password';
管理员重置其他账号密码
- 管理员可为其他用户账户直接设置新密码，无需旧密码。例如：
```
ALTER USER 'jeffrey'@'localhost' IDENTIFIED BY 'password123';
```
- 但被强制密码验证的普通用户自助修改必须验证当前密码。

4. 双密码变更过程配合

无中断平滑修改密码（双密码机制）
- 第一步：将新密码设为主密码，旧密码保留为次密码
```
ALTER USER 'appuser1'@'host' IDENTIFIED BY 'new_password' RETAIN CURRENT PASSWORD;
```
- 第二步：应用程序逐步切换到新密码登录
- 第三步：彻底弃用旧密码
```
ALTER USER 'appuser1'@'host' DISCARD OLD PASSWORD;
```

5. 随机密码生成

自动生成随机密码（适用于新建/修改）
- 语法示例：
```
ALTER USER 'username'@'host' IDENTIFIED BY RANDOM PASSWORD;
```
- 系统会返回明文随机密码给执行者，建议立即保存。

6. 密码失败追踪与临时锁定解锁

因多次失败尝试被锁定时，修改密码可解锁
- 参数示例：
```
ALTER USER 'u1'@'localhost' IDENTIFIED BY 'password' 
  FAILED_LOGIN_ATTEMPTS 3 PASSWORD_LOCK_TIME 3;
```
- 当达到设定失败次数，账户会被临时锁定，期间无法通过密码重试登录；可由管理员手动修改密码或等待LOCK_TIME到期后解锁。

Q78

English:
Which two statements are true about the binary log encryption feature?
• A) It requires a keyring plugin.
• B) It can be set at run time.
• C) It can be activated per session.
• D) It encrypts any connecting slaves connection thread.
• E) When enabled it encrypts existing binary logs.
• F) It requires binary logging to be enabled.

Answer: A, B

中文翻译：

关于二进制日志加密功能，以下哪两项是正确的？
• A）需要 keyring 插件。
• B）可以在运行时设置。
• C）可以按会话激活。
• D）加密所有连接的从服务器连接线程。
• E）启用后加密已有的二进制日志。
• F）需要启用二进制日志功能。

解析：

选项分析

A: 它需要一个密钥环(keyring)插件。
- 解释：正确答案。无论是否开启 binary log，都必须配置 keyring（密钥环）插件或组件，否则无法为 binlog/relay log 加密生成密钥（如 keyring_file plugin、keyring_component 等）。
B: 它可以在运行时设置。
- 解释：正确答案。binlog_encryption 变量可以在服务器运行时通过特权账户开启或关闭（需要 BINLOG_ENCRYPTION_ADMIN 权限），对应为动态系统变量（Dynamic）。
C: 它可以按会话激活。
- 解释：错误。binlog 加密是实例级的全局参数，不能 per session 设置。
D: 它会加密任何连接的从库线程。
- 解释：错误。加密的是本地 binlog 和 relay log 文件，与主从网络传输无关，并不会加密连接线程流量。
E: 启用时会加密现有的二进制日志。
- 解释：错误。已存在的 binlog 文件不会被自动加密。变更加密配置后，只用于新生成的日志文件；已有文件需自己手工清理。
F: 它要求启用二进制日志功能。
- 解释：错误。开启 binlog_encryption 即使二进制日志功能未开启也可以生效于 relay log。例如仅做中继的从库可开启此加密不需 binlog。

MySQL 二进制日志与中继日志加密

https://dev.mysql.com/doc/refman/8.0/en/replication-binlog-encryption.html

1. 功能简介与作用范围

从 MySQL 8.0.14 起，二进制日志（binary log）和中继日志（relay log）均可加密存储，防止文件被系统其他用户或外部攻击者窃取、滥用或查看敏感数据。
加密算法为内置的 AES，加密方式不可更换。
开启加密方法：设置系统变量 binlog_encryption=ON，默认是 OFF。
此变量影响所有二进制日志和所有中继日志（包括新建复制通道产生的 relay log）；binlog_encryption 是全局作用，不能针对 session。
即使未启用 binary log，仅作为复制中继的 MySQL 服务器也可加密 relay log，二进制日志本身不是加密前提。
必须先安装并配置 keyring 插件（如 keyring_file 等），数据库加密密钥通过该插件安全存储和管理。

2. 加密密钥管理与主密钥轮换

首次启用二进制日志加密时，服务器会生成新的“二进制日志加密密钥”（binary log encryption key），优先于二进制日志和中继日志的初始化。
每个 binlog/relay log 文件使用该密钥对“文件密码”加密，再衍生进一步的密钥对文件数据本身加密。
当前 server 正在用的称为“二进制日志主密钥”（binary log master key）。主密钥支持定期轮换，轮换时只需重新加密每个文件的文件密码，而不需重新加密日志内容本身。
中继日志所有通道均加密，binlog/relay log 的 index 文件永远不会被加密。

3. 动态加解密与权限控制

运行时设置 binlog_encryption 为 ON 时，立刻生成新的加密密钥，立即轮换日志文件。只有新生成的 binlog/relay log 才会被加密。
先前已存在的 binlog/relay log 文件不会自动加密（如有需要可手动清理）。
动态关闭加密（binlog_encryption=OFF）也会立即轮换日志，新文件为明文，已加密文件继续保留，加密文件不会自动解密，但服务器仍能读取它们。
运行时激活/关闭加密需有 BINLOG_ENCRYPTION_ADMIN 特权权限。

4. 文件区分与兼容性

加密与未加密 binlog 有不同的文件头魔数字，方便识别文件状态（加密为 0xFD62696E，未加密为 0xFE62696E）。
SHOW BINARY LOGS 可以列出各 binlog 文件的加密状态。

5. binlog 工具兼容性与数据迁移

加密后的 binlog 文件无法被 mysqlbinlog 工具直接读取，需加 --read-from-remote-server 选项在线读取。
直接读取会报错，旧版 mysqlbinlog 甚至无法识别为 binlog 格式。
使用 mysqlbinlog 备份出的 binlog 文件，导出的副本是明文保存（即导出过程解密），需注意二次保护。
日志加密与事务压缩功能可以联合使用。

核心要点结构化总结

加密范围：所有 binlog 和 relay log 文件；影响复制与本地存储。
前置条件：须安装配置 keyring 组件/插件用于密钥管理。
配置方式：binlog_encryption 可运行时开启/关闭（全局作用）。
作用时机：仅新生成日志文件会被加密，历史文件不自动加密或解密。
权限要求：需有 BINLOG_ENCRYPTION_ADMIN 权限修改加密状态。
识别区分：加密状态可通过文件魔数字或 SQL 查看。
与备份导出结合：加密文件经 mysqlbinlog 备份后为明文。

Q79

English:
Which three actions are effective in capacity planning?
• A) Monitoring OS resources for patterns
• B) Buying more RAM
• C) Consulting the application team about any future projects and use
• D) Upgrading to the latest application version
• E) Buying more disk
• F) Buying more CPU
• G) Adding circular replication nodes for increased DML capability
• H) Basing expected growth on an average of the last 3 years

Answer: A, C, H

中文翻译：

下列哪三项是有效的容量规划措施？
• A）监控操作系统资源使用模式
• B）购买更多内存
• C）与应用团队沟通未来项目和使用情况
• D）升级到最新应用版本
• E）购买更多磁盘
• F）购买更多 CPU
• G）添加循环复制节点以提高 DML 能力
• H）基于过去三年的平均增长预估未来需求

解析：

A: 监控操作系统资源的使用模式
- 解释： 这是评估目前资源瓶颈与趋势、辅助预测的核心方法。属于有效的容量规划行动。(正确答案)
B: 购买更多内存
- 解释： 只是一个直接扩容行为，并非容量规划本身。容量规划强调预测和策略而不是直接采购。
C: 咨询应用团队未来项目和用途
- 解释： 了解未来需求，有助于科学预测资源增长、变化，对容量规划十分关键。(正确答案)
D: 升级到最新版本的应用
- 解释： 和容量规划关系不大，除非已知新版本显著影响资源消耗，但本身并不是规划动作。
E: 购买更多磁盘
- 解释： 同B，是直接扩容行为，不属于规划动作。
F: 购买更多CPU
- 解释： 同B/E，是执行结果或解决短期问题的手段，不是规划本身。
G: 增加循环复制节点以增强DML能力
- 解释： 属于具体架构实施，而非容量规划的通用做法，仅在某种场景下有用。
H: 以过去三年的平均值预测预期增长
- 解释： 以数据趋势为基础预测未来增长，这是标准、有效的容量规划方法。(正确答案)

1. Capacity Planning

The system must have the capacity to handle any projected usage growth and any transient spikes in activity.
- Consider changes in baseline resource usage due to user activity and data growth.
- Consider upcoming campaigns or other predicted busy times.
Do not add too many resources at one time.
- To add servers (or other hardware) that you do not need is wasteful and does not provide a worthwhile return on investment.
Graph key elements in your baseline to monitor changes in resources that grow in usage as your data or application functionality grows:
- Memory
- Hard disk space

2. 中文

容量规划的核心原则：

系统必须有能力应对预计的使用增长和突发的活动高峰。
- 需考虑由于用户活动与数据增长引起的基线资源使用量变化。
- 需提前考虑即将到来的营销活动或其他已知的繁忙时期。
不要一次性增加过多资源。
- 增加并不需要的服务器（或其他硬件）会造成浪费，投资回报低下。
建议对基线中的关键资源要素进行持续监测（绘图/数据分析），以追踪数据或应用功能增长带来的资源使用变化，重点关注：
- 内存
- 硬盘空间

总结：

容量规划需以业务数据和活动趋势为基础，科学预测资源峰值与增长，动态、按需扩展。
不建议"一次投入过量硬件"，而应结合监控与历史趋势分析，灵活调整硬件资源，避免浪费。
持续监控关键指标（如内存、硬盘）是容量规划的重要工作，可及时发现资源瓶颈并主动应对。

Q80

English:
Which condition is true about the use of the hash join algorithm?
• A) 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.
• C) The query must access no more than two tables.
• D) At least one of the tables in the join must have a hash index.

Answer: B

中文翻译：

关于哈希连接算法，哪项条件正确？
• A）连接中的最小表必须能装入由 join_buffer_size 设置的内存。
• B）连接中不能使用索引。
• C）查询最多访问两个表。
• D）连接中至少有一个表必须有哈希索引。

解析：

• A 错误，使用的内存大小由 join_buffer_size 控制，超出则溢写磁盘，影响性能，并非必须能装入由 join_buffer_size 设置的内存
• B 正确，哈希连接不使用索引，故选 B。
• C 错误，支持多表联接
• D 错误，Hash Join 与表的物理哈希索引无关，是纯粹的执行引擎算法

Hash Join Optimization

1. 什么是 Hash Join？

Hash Join 是 MySQL 8.0.18 及以后版本引入的高效连接算法，用于提升特定 Join 查询的执行性能。
优化器会尽可能选择 Hash Join（默认行为），以替代传统的块嵌套循环（Block Nested Loop）算法。

2. 适用场景与条件

主场景：每组连接有等值条件（equi-join），且这些连接条件上没有合适的索引可用时，优化器会采用 Hash Join。
MySQL 8.0.20+：即使存在非等值条件或无连接条件（如笛卡尔积），都可能使用 Hash Join。
支持多表联接：不仅仅局限于两表，多个 Join 也可递归使用 Hash Join。

3. 控制与可见性

早期（8.0.18）：可通过 optimizer_switch 变量或优化器 hint（HASH_JOIN、NO_HASH_JOIN）控制。8.0.19 起这些控制方式已无效，系统自动决策。
可通过 EXPLAIN 或 EXPLAIN FORMAT=TREE、EXPLAIN ANALYZE 查看具体某条 SQL 是否用到了 Hash Join。

4. 算法实现要点

先对一个表（一般为较小的表）进行全表扫描、在内存中构建哈希表（哈希 bucket）；使用的内存大小由 join_buffer_size 控制，超出则溢写磁盘，影响性能。
然后顺序扫描第二张表，针对每条记录用哈希表做 "等值匹配" 或后续过滤。
对于复杂 Join，只要任何一组表对有等值条件且无合适索引，即可用 Hash Join；非等值条件则会作为 where 过滤后置。

5. 内存与性能说明

Hash Join 消耗的内存由 join_buffer_size 限定。若所需内存超过上限，哈希表写磁盘，性能大降甚至 join 失败（依赖 open_files_limit）。
可以适当增大 join_buffer_size 提高 Hash Join 成功率与速度，但小表查询也会用到，需权衡配置。
8.0.18+ 实现了 join_buffer 的渐进分配，避免小查询一次性耗尽大内存。

6. 实战用例与特性

Hash Join 可用于：
- 多表 join（包括多层内外连接）
- 等值 join、非等值 join（如 t1.c1 < t2.c1）
- 子查询（半连接、反连接：IN、NOT EXISTS）
- 外连接（LEFT/RIGHT JOIN，内部重写为左连接逻辑）
- 无连接条件的笛卡尔积
查询执行计划会显示如："Using join buffer (hash join)"

7. 其他注意点

优化器判断索引可用，则优先采用索引驱动 join（如 Index Nested Loop），而不是 hash join。
Hash Join 与表的物理哈希索引无关，是纯粹的执行引擎算法。
提高 join_buffer_size、合理设置 open_files_limit，可显著提升 hash join 能力。

总结要点

Hash Join 是 MySQL 8.0.18+ 的默认高性能 Join 算法，适用于复杂 join、无合适索引或等值/非等值场景。
核心依赖 join_buffer_size 的内存配置，小表需能装入 buffer 才高效。
优化器自动决定何时采用 hash join，管理者无需手动干预。

Q81

English:
Replication for master and slave MySQL Server is 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.

Answer: C, E

中文翻译：

主从复制运行中，二进制日志文件占用的磁盘空间不断增长。
哪两种方法可以管理此问题？
• A）执行 FLUSH LOGS 语句。
• B）在文件系统上手动删除所有二进制日志文件以释放空间。
• C）执行 PURGE BINARY LOGS 语句。
• D）在主服务器上移除 --log-bin 选项禁用二进制日志。
• E）设置 binlog_expire_logs_seconds 变量。

解析：

A: 执行 FLUSH LOGS 语句。
- 解释：FLUSH LOGS 只是轮转（生成新日志文件），不会删除旧日志文件，空间不会明显减少，不是解决空间增长的办法。
B: 手动删除所有 binlog 文件。
- 解释：危险做法，会导致主从复制出错，不可取；MySQL 不建议直接从文件系统删除 binlog。
C: 执行 PURGE BINARY LOGS 语句。
- 解释：正确答案。
  该命令会安全地删除指定点之前的 binlog 文件，并确保主从同步安全，不会导致复制出错。
D: 在主库移除 --log-bin 禁用 binlog。
- 解释：虽然可彻底解决，但会导致复制不可用，不符合“复制正在运行”的场景，破坏主从结构，不推荐。
E: 设置 binlog_expire_logs_seconds 变量。
- 解释：正确答案。
  该参数允许自动定期清理（过期） binlog，防止空间无限增长，是推荐的自动管理方式。

15.4.1.1 PURGE BINARY LOGS 语句

1. 二进制日志简介

二进制日志（binary log）：MySQL 用于记录服务器上发生的所有数据更改（如增删改）的日志文件集合。包括一组二进制日志文件和一个索引文件。

2. PURGE BINARY LOGS 的作用与用法

作用：用于手动删除已经不再需要的历史二进制日志，释放磁盘空间，防止日志堆积。
基本语法：
- PURGE { BINARY | MASTER } LOGS TO 'log_name';
- PURGE { BINARY | MASTER } LOGS BEFORE 'YYYY-MM-DD hh:mm:ss';
  - 这两个用法分别以具体文件名或时间点为基准，删除该日志之前的所有二进制日志。

3. 使用说明和注意事项

权限要求：需要 BINLOG_ADMIN 权限。
前提条件：服务器必须使用 --log-bin 启动参数开启了二进制日志功能，否则命令无效。
BINARY 和 MASTER：二者表示同一含义，可以互换。

4. 运行时行为和安全性

支持在线清理日志，无需停止主从复制，不会删除任何正在被从库读取的日志文件（及其之后的所有日志）。若尝试删除正在使用的日志，MySQL 只删除更早的日志，并提示警告。
如果某个从库未连接且你清除了它尚未同步的日志，该从库将无法继续同步。
与备份锁冲突：8.0.28 起，不能在 LOCK INSTANCE FOR BACKUP 状态下 purge 二进制日志，否则违反备份锁规则。

5. 日志安全清理建议流程

在所有从库上执行 SHOW REPLICA STATUS，确认各自正在读取的二进制日志文件名。
在主库上执行 SHOW BINARY LOGS，查看所有日志文件及其排序。
找出所有从库里最靠前的（最早的）尚在读取的日志作为“目标文件”。
建议将要删除的日志先备份。
执行：PURGE BINARY LOGS TO '目标文件名';，只会保留目标及其后的所有日志。

6. 特殊说明

如果二进制日志文件被手动从系统删除（如 Linux 下使用 rm），但 .index 仍记录了该文件，PURGE 操作将报错。此时需手动维护 .index 文件，确保只列出现存日志，再重试 purge 命令。

7. 自动清理机制

默认情况下，MySQL 会自动根据“二进制日志过期时间”（默认30天，由 binlog_expire_logs_seconds 控制）定期清理日志。自动清理发生在服务器启动和主动刷新二进制日志时。
对于复制环境，日志过期时间应大于“最大复制延迟”，以防从库未能及时同步需要的日志就被删除。

点总结

二进制日志是 MySQL 复制和数据恢复的基础。
非常重要：不得随意手动删除日志文件（不要直接用rm等文件系统命令删除），务必使用 PURGE BINARY LOGS 管理，防止数据不一致或复制断链。
定期查看主从同步状态，检查日志自动清理配置，合理制定保留策略，是数据库运维的基本功。

Q82

English:
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. (Does not back up sys, information_schema, performance_schema)
• B) All details regarding deleted logs and master metadata are captured in the output file. (Does not capture deleted logs)
• C) All binary logs are backed up and then deleted. (Does not back up binlogs)
• D) All databases, excluding master metadata, are backed up to the output file.
• E) All binary logs are deleted from the master. (A new binlog is generated)
• F) All non-active binary logs are removed from the master.

Answer: D, F

中文翻译：

查看以下 MySQL 数据目录中的二进制日志列表：

Binlog.000001  
Binlog.000002  
........  
Binlog.000289  
Binlog.000300  
Binlog.000301  
Binlog.index

执行以下命令成功：

mysqldump --delete-master-logs --all-databases > /backup/db_backup.sql
以下哪两项是正确的？
• A）所有数据库备份到输出文件。（不备份 sys、information_schema、performance_schema）
• B）所有删除的日志和主服务器元数据详情都记录在输出文件中。（不记录删除日志）
• C）所有二进制日志先备份再删除。（不备份 binlog）
• D）除了主服务器元数据外，所有数据库备份到输出文件。
• E）所有二进制日志从主服务器删除。（会生成新的 binlog）
• F）所有非活动的二进制日志从主服务器移除。

解析：

A: 所有数据库都被备份到了输出文件。（不备份 sys、information_schema、performance_schema）
- 解析： mysqldump --all-databases 会备份所有“用户数据库”以及 mysql 系统数据库，但不会备份 sys, information_schema, performance_schema（这些是虚拟库，mysqldump 默认不会导出）。
- 错误。
B: 所有关于已删除日志和主服务器元数据的详细信息都被捕获到了输出文件中。
- 解析： mysqldump 只是导出表结构和数据，不会导出任何二进制日志或其元数据信息。
- 错误选项。
C: 所有二进制日志都被备份然后删除。
- 解析： mysqldump 并不会导出 binlog 文件本身，只是备份数据库。
- 错误选项。
D: 所有数据库（不包含主服务器元数据）被备份到了输出文件。
- 解析： mysqldump --all-databases 导出所有数据库的数据和结构，不包含 binlog 或“主服务器元数据”（像二进制日志内容）。
- 正确。
E: 所有二进制日志都被从主服务器上删除。（会生成一个新的 binlog）
- 解析：--delete-master-logs 在备份后，自动删除所有“当前活跃二进制日志之前的所有 binlog 文件”，仍然存在二进制日志。
- 错误选项。
F: 所有非活动状态的二进制日志都被从主服务器删除。
- 解析：--delete-master-logs的功能。
- 正确。

--delete-master-logs

--delete-master-logs 是 mysqldump 命令的选项之一。在 MySQL 8.0.26 之前用于自动删除主库的二进制日志文件，从 MySQL 8.0.26 开始被 --delete-source-logs 取代，但两者功能完全一致。

一、功能说明

--delete-master-logs 作用是：
当用 mysqldump 备份数据库并指定此参数时，mysqldump 会在备份操作完成后，自动删除所有“当前活跃二进制日志之前的所有 binlog 文件”。
“Deprecated（弃用）”：
从 MySQL 8.0.26 起，官方建议用 --delete-source-logs 替代此选项，功能相同，仅是名称变更，更符合 MySQL 术语体系（从 master/slave 变为 source/replica）。

二、版本兼容

MySQL 8.0.26 之前：推荐用 --delete-master-logs
MySQL 8.0.26 及之后：推荐用 --delete-source-logs

Q83

English:
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 relay logs from the master should be used to replace the corrupted relay logs.
• B) The slave relay logs should be deleted; then execute START SLAVE;
• C) The slave needs to be restored from backup.
• D) The slave relay logs should be deleted; execute CHANGE MASTER to adjust the replication relay log file name, then issue START SLAVE;

Answer: D

中文翻译：

你的 MySQL 环境采用异步基于位置的主从复制。
从服务器出现磁盘 I/O 问题，已停止。
确定从服务器的 relay log 文件损坏不可用，其他文件未损坏。
重启 MySQL 服务器后，如何恢复复制？
• A）用主服务器的 relay log 替换损坏的 relay log。
• B）删除从服务器 relay log，然后执行 START SLAVE。
• C）从备份恢复从服务器。
• D）删除从服务器 relay log，执行 CHANGE MASTER 调整 relay log 文件名，然后执行 START SLAVE。
解析：

A: 应该从主库导出 relay log，用以替换损坏的从库 relay log。
- 解析：relay log 是主库 binlog 在从库的拷贝和本地重写，只能由从库自动生成，不能直接从主库复制 relay log 文件。因此此说法错误。
- 错误。
B: 应删除从库 relay log，然后执行 START SLAVE;
- 解析：如果直接这样操作，从库会尝试根据原有状态拉取，但不会重置主库同步点，很容易出现同步混乱或起始点错位。因此此方法不完整，容易导致数据不一致。
- 错误。
C: 需要从备份中还原从库。
- 解析：本题条件下“只有 relay log 损坏，其它都没坏”，并不需要做全备恢复，这样做过于极端。应优先用更简便的方法。
- 错误。
D: 应删除从库 relay log；执行 CHANGE MASTER 以调整复制 relay log 文件名，然后再执行 START SLAVE;
- 解析：正确做法。relay log 损坏但主 binlog 仍在，因此应：
  1. 停止从库复制。
  2. 删除损坏的 relay log。
  3. 用 CHANGE MASTER TO 指定（通常是原来中继日志 SOURCE_LOG_FILE 与 SOURCE_LOG_POS，那就是上一次同步点），同步主库的二进制日志及位点。
  4. 执行 START SLAVE。这样从库会按主库的 binlog 重新生成 relay log 并恢复同步。
- 正确答案。

relay log（中继日志）

结构与功能
- Relay log 与 binary log 类似，通常由一组带编号的日志文件和一个索引文件组成。
- 每个 relay log 文件都包含“数据库变更事件”，索引文件（如 host_name-relay-bin.index）记录所有 relay log 文件名。
- 默认位置为数据目录。
- relay log 文件和 binary log 格式一致，可用 mysqlbinlog 工具读取和分析。
命名规则
- 默认通道的 relay log 文件格式为：host_name-relay-bin.nnnnnn，编号从 000001 开始递增。
- 非默认通道格式：host_name-relay-bin-channel。
- 可用 relay_log 和 relay_log_index 变量自定义文件名和存储路径。
特殊注意（与主机名变更有关）
- 使用默认 host_name 作为前缀时，如果以后修改了从库主机名，可能导致复制失败（找不到 relay log 文件）。
- 建议：提前用 relay_log 和 relay_log_index 参数自定义名字，避免受主机名影响。
- 如果已出错，可停库，将旧索引文件内容合并至新索引文件，再重启服务以恢复。
创建与删除机制
- 新的 relay log 文件在以下情况下生成：
  - I/O 线程启动时
  - 执行 FLUSH LOGS 命令或 mysqladmin flush-logs 时
  - 当前 relay log 达到最大设定（max_relay_log_size 或 max_binlog_size）
- relay log 自动删除：SQL 应用线程处理完所有事件后，会自行删除已用完的 relay log 文件（无需手动删）；FLUSH LOGS 也可触发轮转，影响删除时机。

总结

relay log 是从库用于缓存并“重放”主库二进制日志事件的本地副本，不可跨主机直接替换互用。
永远不要因从库 relay log 损坏而尝试拿主库 binlog 直接覆盖；应重新按同步点生成。
relay log 的自动删除和轮转机制决定了其通常不需要人工干预。
本地 relay log 索引文件与物理文件一致性非常重要，如遇主机名等变更需谨慎调整。

A: 监控并调度针对中继日志的 I/O 子系统操作
- 解析：slave I/O 线程的主要职责并非处理本地的 relay log 的 I/O 调度，这通常由操作系统和 SQL 线程负责。
- 错误。
B: 连接主库并请求主库发送其二进制日志中记录的更新
- 解析：slave I/O thread 的标准职责正是与主库建立连接，并请求主库传送其 binlog 文件的内容，然后将收到的内容写成本地 relay log。所以这是准确描述。
- 正确答案。
C: 为读取并发送每个事件到从库而获取二进制日志锁
- 解析：其实是主库自身负责 binlog 的读写锁管理，从库的 I/O 线程不直接参与锁管理，仅是基于协议请求和接收数据。
- 错误。
D: 读取中继日志并执行其中的事件
- 解析：这个工作是 SQL 线程（slave SQL thread）的职责，不是 I/O 线程的任务。
- 错误。

I/O 线程

I/O 线程负责与主库（source）通信、拉取 binlog 并写入本地 relay log；所有同步状态可通过 SHOW REPLICA STATUS 查询，有助于复制故障分析。
主要同步瓶颈与故障点：网络连接、主库响应、relay log 空间限制、二进制日志读取/推送、线程之间的同步与排队等流程。
8.0.26 之后，所有“master/slave”相关状态名均更换为“source/replica”等，监控诊断时需注意版本差异。

SQL 线程

SQL 线程职责：读取 relay log 并按顺序重放、执行主库 binlog 已同步到本地的事件，是主从延迟的关键入口。
常见等待/空闲状态：当 SQL 线程赶上 IO 线程进度后，会“等待更多更新”；并行复制时经常有 Coordinator/Worker 等待事件或等待资源释放的状态。
特殊场景：临时表/文件、并行复制、延迟复制、LOAD DATA INFILE等会出现相关状态提示。
诊断用途：SQL线程的 State/Info 能直观反映复制是否卡在某步骤，有无延迟/压力瓶颈/异常等待等，是 DB 运维排查复制问题的重要依据。

Q87

English:
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, countries has none.

Answer: D

中文翻译：

languages 表使用 MyISAM，countries 表使用 InnoDB，两表均为空。执行以下语句：

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

执行后两表内容如何？
• A）countries 有一行，languages 没有。
• B）两表均有一行。
• C）两表均为空。
• D）languages 有一行，countries 没有。

解析：

• MyISAM 不支持事务回滚，插入仍存在；InnoDB 回滚成功，插入被撤销，选 D。

总结：

MyISAM 不支持事务操作，所有 DML 语句一旦执行即永久生效，不可被回滚。
InnoDB 支持事务控制，通过 BEGIN/COMMIT/ROLLBACK 可以保证 ACID 特性。
在一个事务中同时对 MyISAM 和 InnoDB 表进行操作时，ROLLBACK 只能回滚 InnoDB 的变更，MyISAM 的操作不会被撤销。

MySQL 服务器关闭（关机）流程

https://dev.mysql.com/doc/refman/8.0/en/server-shutdown.html

1. 关闭流程总览

当 MySQL 服务器需要关闭时，可通过多种方式发起：

用有 SHUTDOWN 权限的账号执行 mysqladmin shutdown
其它系统特定方法（如 Linux 接收 SIGTERM 信号，Windows 服务管理器命令）

2. 具体步骤分解

1. 启动关闭流程

关机指令被触发（如用户命令、服务关闭、系统信号）
服务器根据来源决定是否创建关机线程，充分利用多线程安全性（如内存耗尽创建失败则会记录日志）

2. 拒绝新连接

服务器停止接受新客户端连接（关闭 TCP、socket、命名管道、共享内存端口等）

3. 终止当前活动

所有客户端线程被标记为“Killed”，断开连接
空闲线程很快结束；正在处理中的线程检测自己是否被杀死，状态检查周期决定关闭所需时间
对于打开事务的线程会自动回滚，对非事务表（如 MyISAM）的多行操作可能出现部分完成的问题

4. 复制相关线程（如适用）

主服务器连接的从库线程亦被标记为 Killed
从库自己关闭时，会优先关闭复制 I/O 线程和 SQL 线程
- SQL 线程会先完成当前语句或事务，再安全退出，避免数据不一致

5. 关闭存储引擎

刷新表缓存、关闭所有已打开的表
各引擎执行最终的数据安全操作：
- InnoDB 刷新 Buffer Pool 到磁盘，记录 LSN，并注销内部线程
- MyISAM 完成所有索引和数据的写入

6. 服务进程退出

MySQL 服务进程退出并返回标准 exit code：
- 0：正常关闭，无需重启
- 1：异常关闭
- 2：异常且系统管理器将尝试重启服务

3. 相关知识点总结

无论如何关机（命令、SIGTERM、服务工具），最终都会严格按照此流程保障数据一致性、安全性
事务表（如 InnoDB）能自动回滚未提交事务，非事务表（如 MyISAM）不能回滚未完成操作
复制环境下关闭，须正确终止相关复制线程和检查事务原子性，以防数据不一致
日志文件会详细记录关机相关的诊断和异常信息

Q91
English:
Which three statements are true about MySQL Enterprise Firewall?
• A) It is available only in MySQL Enterprise versions.
• B) On Windows systems, it is controlled and managed using the Windows Internet Connection Firewall control panel.
• C) It provides INFORMATION_SCHEMA tables that enable views into firewall data.
• D) System tables named firewall_users and firewall_whitelist in the mysql database provide persistent storage of firewall data.
• E) It shows only notifications for blocked connections, which originated outside of your network’s primary domain.
• F) Firewall functionality is dependent on SHA-256 and ANSI-specific functions built to the mysql.firewall table.

Answer: A, C, D

中文翻译：

关于 MySQL Enterprise Firewall，以下哪三项是正确的？
• A）仅在 MySQL Enterprise 版本中提供。
• B）在 Windows 系统上通过 Windows Internet Connection Firewall 控制面板管理。
• C）提供 INFORMATION_SCHEMA 表以查看防火墙数据。
• D）mysql 数据库中的 firewall_users 和 firewall_whitelist 系统表用于持久存储防火墙数据。
• E）只显示来自网络主域外部的阻止连接通知。
• F）防火墙功能依赖于基于 mysql.firewall 表的 SHA-256 和 ANSI 特定函数。

解析：

• MySQL Enterprise Firewall 特性包括企业版本专属、INFORMATION_SCHEMA 支持和系统表存储。

MySQL Enterprise Firewall 元素说明

https://dev.mysql.com/doc/refman/8.0/en/firewall-elements.html

1. 功能组成结构

MySQL Enterprise Firewall 以插件（plugin）方式实现，主要包括：
- MYSQL_FIREWALL：服务器端主插件，拦截所有 SQL 语句，并根据安全配置文件判断是否放行或拒绝执行。
- MYSQL_FIREWALL_USERS、MYSQL_FIREWALL_WHITELIST：额外的插件组件。

2. 数据及管理视图

Enterprise Firewall 除了在 mysql 库存储核心表外，还通过 Performance Schema 和 INFORMATION_SCHEMA 提供只读视图（可查看已注册配置、操作日志等）。
mysql 系统数据库表（如 firewall_users, firewall_whitelist）用于持久化存储所有配置规则，保证服务器重启后策略不丢失。

3. 运行效率和管理机制

所有配置 profile 会缓存于内存加速决策。
提供存储过程，支持 profile 注册、模式切换、在缓存/持久化之间同步数据。
管理员通过 API 可控制缓存和持久化数据同步。

4. 控制与安全参数

系统变量：支持运行时管理防火墙的启用、模式、状态监控等。
安全权限设计：
- FIREWALL_ADMIN 可管理任意用户的防火墙规则；
- FIREWALL_USER 可管理本人规则；
- FIREWALL_EXEMPT（8.0.27+）可豁免用户不受防火墙约束（如防止管理员被配置锁死）。

Q92

English:
Which two statements are true about the mysql_config_editor program?
• A) It provides an interface to change my.cnf files.
• B) It manages the configuration of client programs. (only works for mysql client)
• C) It can move datadir to a new location.
• D) It manages the configuration of user privileges for accessing the server.
• E) It will use [client] options by default unless you provide –login-path. (mysql = mysql –login-path=client)
• F) It manages the configuration of the MySQL Firewall feature.
• G) It can be used to create and edit SSL certificates and log locations.

Answer: B, E

中文翻译：

关于 mysql_config_editor 程序，以下哪两项是正确的？
• A）提供修改 my.cnf 文件的界面。
• B）管理客户端程序配置。（仅适用于 mysql 客户端）
• C）可以将 datadir 移动到新位置。
• D）管理访问服务器的用户权限配置。
• E）默认使用 [client] 选项，除非提供 --login-path。（mysql = mysql --login-path=client）
• F）管理 MySQL 防火墙功能配置。
• G）可用于创建和编辑 SSL 证书及日志位置。

解析：

A) 修改 my.cnf 文件接口
- mysql_config_editor 不会操作 my.cnf，仅管理加密的认证连接信息。
- 错误。
B) 管理客户端程序配置（仅 mysql 客户端有效）
- mysql_config_editor 生成的认证路径主要被 mysql 命令行客户端用来自动连接；其他如 mysqldump 等部分工具也可用，但并非“所有”客户端适配。
- 正确。
C) 可以移动数据目录
- 无此功能，仅做客户端连接认证管理。
- 错误。
D) 管理访问权限
- 不负责权限分配，仅保存/读取认证信息。
- 错误。
E) 默认使用 [client] 配置组，除非用 --login-path
- 默认情况下，如果不加 --login-path 参数，则自动使用 [client] 组。
- 正确。
F) 管理 MySQL Firewall 配置
- 无关，仅处理客户端认证。
- 错误。
G) 创建或编辑 SSL证书/日志文件位置
- 不涉及这些内容。
- 错误。

mysql_config_editor — MySQL 配置工具

1. 作用与功能

mysql_config_editor 用于管理客户端连接 MySQL 所需的认证信息（主机、用户名、密码、端口、socket）。
主要通过加密/混淆方式，将这些信息存储在用户主目录下的 .mylogin.cnf 文件（或 Windows 的 %APPDATA%\MySQL 目录）中。
该工具不会修改 my.cnf 配置文件，且与服务器权限、数据目录等无关。

2. 认证凭据的保存与读取原理

.mylogin.cnf 文件内的每个“组”被称为login path，可自定义多个，比如 [client]、[remote] 等，每组存储一套认证参数。
mysql、mysqldump 等 MySQL 客户端会按照正常配置文件的优先级，自动从 .mylogin.cnf 中读取认证信息，优先级高于 my.cnf 的明文配置。
默认情况下，如果不加 --login-path 参数，则自动使用 [client] 组。

3. 常用命令与选项

可以通过 set、remove、reset、print 等命令管理 .mylogin.cnf 中的条目。
set 用于新建或调整 login path（如 --login-path=remote）。
remove、reset 可移除或清空条目。
print --all 可显示所有 login path，但不会泄漏明文密码，仅显示为 ***** 。
部分命令支持通用参数如 --help、--verbose、--version 等。

4. 重要安全说明

该工具通过简单混淆存储密码，提高了安全性，但混淆不可防止有权限的系统用户暴力还原内容。
.mylogin.cnf 必须对当前用户只读写，否则会被忽略。
该工具不涉及任何服务器端权限数据（如用户授权）、SSL设置、防火墙等内容。

5. 应用示例

mysql_config_editor set --login-path=remote --user=user --host=host --password
按提示输入密码后，会为 [remote] 组设置对应参数。
客户端登录时用 mysql --login-path=remote 自动使用此认证信息，无需明文密码。

Q93

English:
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 [mysqld 8.0.18-commercial 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 path specified.  
2019-12-12T22:21:40:459423z 1 [ERROR] [DCY-012594] [InnoDB] If you are installing InnoDB, remember that you must create directories yourself; InnoDB does not create them.  
2019-12-12T22:21:40:459606z 1 [ERROR] [DCY-012646] [InnoDB] File ./ibdata1 ‘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

Answer: A, E

中文翻译：

你尝试启动 mysqld。
查看以下日志输出：

2019-12-12T22:21:40:353800z 0 [系统] [DCY-010116] [服务器] /mysql/bin/mysqld [mysqld 8.0.18-commercial 作为进程 29740 启动  
2019-12-12T22:21:40:458802z 1 [错误] [DCY-012592] [InnoDB] 文件操作中出现操作系统错误号 2。  
2019-12-12T22:21:40:459259z 1 [错误] [DCY-012593] [InnoDB] 该错误表示系统找不到指定路径。  
2019-12-12T22:21:40:459423z 1 [错误] [DCY-012594] [InnoDB] 如果正在安装 InnoDB，记住必须自己创建目录，InnoDB 不会自动创建。  
2019-12-12T22:21:40:459606z 1 [错误] [DCY-012646] [InnoDB] 文件 ./ibdata1 ‘open’ 返回操作系统错误 71，无法继续操作。  
2019-12-12T22:21:40:459891z 1 [错误] [DCY-012981] [InnoDB] 无法继续操作。

你必须检查哪两项？
• A）配置文件中的 datadir 设置是否正确
• B）是否使用了正确版本的 MySQL
• C）TLS/SSL 证书是否仍有效
• D）文件是否被其他进程锁定的可能性
• E）缺失文件是否存在于其他位置
• F）尝试连接数据库的用户是否使用了正确的用户名和密码

解析：

日志明确指出：文件系统找不到指定路径（如 ibdata1），提示你需检查目录和文件本身，并确认 InnoDB 所需的目录/文件是否提前创建。

A) 配置文件中 datadir 设置是否正确
- 正确。如果 datadir 配置错误，系统无法定位到 InnoDB 的文件目录，自然报“找不到路径”或“找不到文件”。
- 正确答案。
B) 使用正确的 MySQL 版本
- 这个错误不涉及版本兼容问题，而是文件/路径不存在，版本不对不会出现此错误。
- 错误。
C) TLS/SSL 证书有效性
- 跟数据文件加载无关。这类问题不会导致无法找到数据文件路径报错。
- 错误。
D) 文件是否被其他进程锁定
- 理论上出现“文件被占用”会给出不同的操作系统错误号，如 error 13（权限）或 error 11（资源占用），但 error 2 是“文件/目录未找到”。
- 不是主要排查方向。
E) 缺失的文件是否存在于其他位置
- 正确。有时候文件被错误移动或误删，可以在其他目录、备份中找回补齐所需文件。
- 正确答案。
F) 连接用户和密码
- 这是客户端连接而非数据库进程自身启动时关心的问题，也与数据文件找不到无关。
- 错误。

Q94

English:
Examine these two reports taken 100 seconds apart (partial GLOBAL STATUS variables):
• Normal concurrent connections: 50-75
• Observations include high Opened_tables count increasing over time, Open_tables at 1024, and Opened_files increasing significantly.
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

Answer: C

中文翻译：
查看两份相隔 100 秒的状态报告（部分 GLOBAL STATUS 变量）：
• 系统通常支持 50-75 个并发连接
• 观察到 Opened_tables 数量持续增加，Open_tables 为 1024，Opened_files 显著增加
哪个配置更改将改善性能？
• A）减少 table_definition_cache
• B）减少 open_files_limit
• C）增加 table_open_cache
• D）增加 max_connections

解析：

这个题目描述了数据库服务器在短时间内 opened_tables、opened_files 指标连续上升，说明数据库频繁打开新表或文件、没有足够的缓存来保存已打开的表，导致资源不断被消耗。

选项分析
- A: 减少 table_definition_cache
  解释：table_definition_cache 是缓存表定义的参数，减少它会更频繁载入表定义，反而可能让 opened_tables 增长更快，加重数据库负担。
- B: 减少 open_files_limit
  解释：open_files_limit 控制 MySQL 能打开文件的总数，减少它只会限制资源，出现“Too many open files”错误，对性能有害。
- C: 增加 table_open_cache （正确答案）
  解释：table_open_cache 用于缓存已打开的表的数量。Open_tables 达到1024（可能是该参数的上限）且 opened_tables 持续上涨（代表老的表不停被淘汰、不得不反复打开新表），说明缓存太小。加大 table_open_cache 可减少频繁表打开/关闭，提升性能。
- D: 增加 max_connections
  解释：max_connections 影响并发连接上限，但根据题目描述目前并发（50-75）远没达到瓶颈，增大没有帮助。
相关知识点总结

table_open_cache 指定 MySQL 能够缓存多少个已打开的表。若频繁看到 opened_tables 增长，且 Open_tables 达到上限，表示缓存不足，引发频繁的表打开/关闭，影响性能。适当调大 table_open_cache 能显著改善这种情况。
opened_tables 不断上升说明缓存不足；Open_tables 如果接近 table_open_cache 说明缓存已满。
配置调优经验：table_open_cache 太小，表现为 opened_tables 很快累计增加；合适的设置应让 opened_tables 增长非常缓慢甚至基本不变。

Q95

English:
Examine this partial InnoDB Cluster status output showing three hosts:
• host1:3377 mode R/W, status ONLINE
• host2:3377 mode R/O, status MISSING
• host3:3377 mode R/O, status ONLINE
Which statement explains the state of the instance on host2?
• A) It can rejoin the cluster by using dba.rebootClusterFromCompleteOutage()
• B) It has been expelled from the cluster because of a transaction error
• C) It can rejoin using cluster.addInstance('@host3:3377')
• D) It has been removed using STOP GROUP_REPLICATION;
• E) It can be recovered from host3 using cluster.rejoinInstance('@host3:3377')

Answer: E

中文翻译：

查看部分 InnoDB 集群状态输出，三台主机状态如下：
• host1:3377 模式 R/W，状态 ONLINE
• host2:3377 模式 R/O，状态 MISSING
• host3:3377 模式 R/O，状态 ONLINE
以下哪项解释了 host2 实例的状态？
• A）可通过 dba.rebootClusterFromCompleteOutage() 重新加入集群
• B）因事务错误被逐出集群
• C）可通过 cluster.addInstance('@host3:3377') 重新加入
• D）已通过 STOP GROUP_REPLICATION; 移除
• E）可通过 cluster.rejoinInstance('@host3:3377') 从 host3 恢复

解析：

A: 可以通过 dba.rebootClusterFromCompleteOutage() 重新加入集群
解释：该命令用于整个集群完全崩溃且无法正常启动时的紧急恢复，不是单个节点重加方案。
- B: 因事务错误已被踢出集群
  解释："STATUS": "MISSING" → 意味着它暂时无法访问或不属于多数派，但未被驱逐。
- C: 可以用 cluster.addInstance('@host3:3377') 重新加入
  解释：addInstance 只用于向集群新增节点，不适用于已加入但临时掉线、失联、被驱逐等情况。
- D: 已通过 STOP GROUP_REPLICATION; 被移除
  解释：STOP GROUP_REPLICATION; 会让该实例主动断开 group replication 活动，但节点数据仍在，需要适当操作才能重新加入。
- E: 可以通过 cluster.rejoinInstance('@host3:3377') 从 host3 恢复（正确答案）
  解释：rejoinInstance 通常应用于因短暂失联、临时漂移而被踢出的节点，能让节点带着原 group_id 和配置快速回归到集群，无需全新数据同步或初始化。

InnoDB Cluster 状态状态释义

https://dev.mysql.com/doc/mysql-shell/8.4/en/monitoring-innodb-cluster.html

1. ONLINE

含义：实例处于在线状态，正常参与集群相关操作。

2. OFFLINE

含义：该实例已和其他实例失去连接，不参与集群操作。

3. RECOVERING

含义：该实例正在尝试与集群同步，获取所需事务并准备恢复为在线成员。

4. UNREACHABLE

含义：实例已与集群通信中断，暂时不可达。

5. ERROR

含义：实例在恢复阶段或应用事务时遇到错误。
重要说明：实例进入 ERROR 状态后，会自动开启 super_read_only=ON，需手动将 super_read_only=OFF 后才能离开该状态。

6. MISSING

含义：实例已被配置为集群成员，但当前不可用。
- 此状态为 InnoDB Cluster 特有，不属于 Group Replication 的状态。
- MySQL Shell 用此状态标记在集群元数据已注册但当前集群视图中“找不到”的实例。

用法注释

“MISSING”：表现为已登记但暂时失联，适用于网络隔离、宕机或下线未被删除场景。
“ERROR” 需手动操作从错误状态恢复。

Q96

English:
Which three methods display the complete table definition of an InnoDB table?
• A) PRPAIR TABLE table USE_FRM
• B) SHOW CREATE TABLE
• C) hexdump -v -c table.frm
• D) mysqldump --no-data schema table
• E) SELECT * FROM table \G
• F) Query the Information Schema

Answer: B, D, F

中文翻译：

以下哪三种方法可以显示 InnoDB 表的完整定义？
• A）PRPAIR TABLE table USE_FRM
• B）SHOW CREATE TABLE
• C）hexdump -v -c table.frm
• D）mysqldump --no-data schema table
• E）SELECT * FROM table \G
• F）查询 Information Schema

解析：

A: PRPAIR TABLE table USE_FRM
解释：应为 "REPAIR TABLE"，且 USE_FRM 用于在表损坏时修复，不是用于显示表定义的方法。拼写错误。
B: SHOW CREATE TABLE （正确答案）
解释：可以显示创建表的完整 SQL 语句，包括所有字段、类型、索引等信息。
C: hexdump -v -c table.frm
解释：hexdump 只是以十六进制原始模式查看 .frm 文件，需人工分析，不是标准的查表结构方式。
D: mysqldump --no-data schema table （正确答案）
解释：使用 mysqldump 工具加上 --no-data 参数会导出表结构 SQL 定义，不包含数据，可完整展现表定义。
E: SELECT * FROM table \G
解释：只是查询表数据（竖行显示方式），不能显示表结构。
F: Query the Information Schema （正确答案）
解释：通过查询 information_schema 数据库中的 COLUMNS、TABLES、KEY_COLUMN_USAGE 等表，可获得字段、索引、外键等结构信息，属于标准方法。

Q97

English:
A scientific data gathering application uses a MySQL instance backend with high concurrency (thousands of transactions per second) of volatile data.
A restore from binary logs is planned:

mysqlbinlog --start-datetime='2019-08-01 11:00:00' --stop-datetime='2019-08-10 08:30:25' binlog.000238 binlog.000239 binlog.000240 | mys

Which two characteristics cause the restore to be inconsistent with the original data?
• A) Temporary tables cannot persist across binary logs.
• B) Multiple binary logs cannot be specified on the command line.
• C) The temporal values do not offer high enough precision.
• D) The time span of binary logs is too long to restore.
• E) Transaction rate is too high to get a consistent restore.

Answer: C，E

中文翻译：

一个科学数据采集应用使用 MySQL 实例作为后端，具有高并发（每秒数千事务）的易失性数据。
计划从二进制日志恢复：

mysqlbinlog --start-datetime='2019-08-01 11:00:00' --stop-datetime='2019-08-10 08:30:25' binlog.000238 binlog.000239 binlog.000240 | mysql
以下哪两项会导致恢复与原始数据不一致？
• A）临时表不能跨二进制日志持久化。
• B）命令行不能指定多个二进制日志。
• C）时间戳值精度不足。
• D）二进制日志的时间跨度过长。
• E）事务率过高导致无法获得一致恢复。

解析：

A: 临时表无法在多个 binlog 之间持久存在
解释：临时表只在会话中存在，binlog 恢复时如果会话被拆断，临时表无法正确重建，数据不一致。
B: 命令行不能指定多个二进制日志
解释：实际可以在命令行一次性恢复多个 binlog 文件（如题目的命令），此项错误。
C: 时间值精度不够高（正确答案）
解释：造成主数据不一致的主要原因。
D: binlog 跨度太久无法恢复
解释：时间跨度长会影响恢复速度，但并不是导致数据恢复不一致的根本原因，只是效率问题。
E: 高事务速率导致无法一致恢复（正确答案）
解释：高并发环境，如果不是基于一致性快照或点恢复，二进制日志中不同事务并发混合，恢复时无法精确还原到某一瞬间的一致状态，特别是在恢复到某个时间点时容易出错。

Q98

English:
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.

Answer: A, D

中文翻译：

创建用户账户时，以下哪两项可以最小化安全风险？
• A）避免在主机名中使用通配符。
• B）避免在用户名中使用通配符。
• C）要求使用大小写混合的用户名。
• D）不允许无密码账户。
• E）要求用户拥有 FIREWALL USER 权限。
解析：

A: 避免在主机名中使用通配符（正确答案）
解释：如 user@'%' 表示任何主机都可以登录，带来极大风险。应精确指定可信主机来源。
B: 避免在用户名中使用通配符
解释：MySQL 实际上不允许用户名里直接用通配符（用户名不是 host 部分），所以这一项意义不大。
C: 要求用户名混合大小写
解释：虽然可以增加用户名复杂度，但与安全风险关联不大，且 MySQL user 通常大小写敏感性主要取决于设置，不是标准安全建议。
D: 不允许无密码账户（正确答案）
解释：无密码账户极易被恶意利用，是非常严重的安全漏洞。强制要求密码是基础安全措施。
E: 要求有 FIREWALL USER 权限
解释：FIREWALL USER 是企业版防火墙功能相关权限，不属于创建用户的基础最小安全标准。

Q99

English:
There are five MySQL instances configured with group replication. Examine the output of the group members:

mysq1> SELECT MEMBER_ID, MEMBER_STATE FROM performance_schema.replication_group_members;

+--------------------------------------+--------------------+
| MEMBER_ID                            | MEMBER_STATE       |
+--------------------------------------+--------------------+
| 1999b9fb-4aaf-11e6-bb54-28b2bd168d0 | UNREACHABLE        |
| 199b2df7-4aaf-11e6-bb16-28b2bd168d0 | ONLINE             |
| 199bb88e-4aaf-11e6-babe-28b2bd168d07 | ONLINE             |
| 19ab72fc-4aaf-11e6-b51-28b2bd168d07 | UNREACHABLE        |
| 19b33846-4aaf-11e6-ba81-28b2bd168d071 | UNREACHABLE        |
+--------------------------------------+--------------------+

Which two statements are true about network partitioning in the cluster?
• A) The group replication will buffer transactions on online nodes until unreachable nodes return online.
• B) Manual intervention is required to force group members to be only the working two instances.
• 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; shutting down group replication and diagnosing is recommended.
• E) The cluster has built-in high availability and updates group_replication_ip_whitelist to remove unreachable nodes.

Answer: B, D

中文翻译：

有五个 MySQL 实例配置了组复制。查看组成员状态输出：

mysq1> SELECT MEMBER_ID, MEMBER_STATE FROM performance_schema.replication_group_members;

+--------------------------------------+--------------------+
| MEMBER_ID                            | MEMBER_STATE       |
+--------------------------------------+--------------------+
| 1999b9fb-4aaf-11e6-bb54-28b2bd168d0 | UNREACHABLE        |
| 199b2df7-4aaf-11e6-bb16-28b2bd168d0 | ONLINE             |
| 199bb88e-4aaf-11e6-babe-28b2bd168d07 | ONLINE             |
| 19ab72fc-4aaf-11e6-b51-28b2bd168d07 | UNREACHABLE        |
| 19b33846-4aaf-11e6-ba81-28b2bd168d071 | UNREACHABLE        |
+--------------------------------------+--------------------+

关于集群中的网络分区，以下哪两项正确？
• A）组复制将在在线节点缓冲事务，直到不可达节点恢复上线。
• B）需要人工干预以强制只保留两个正常实例作为组成员。
• C）集群会关闭以保持数据一致性。
• D）可能存在 2 节点和 3 节点的组复制同时运行，建议关闭组复制并排查问题。
• E）集群具有内建高可用性，会更新组复制 IP 白名单移除不可达节点。

解析：

A: Group Replication 会在在线节点缓冲事务，直到不可达节点重新上线
解释：错误。在网络分区情况下，Group Replication不会缓冲事务等待离线节点，多数派节点会继续推进， minority 自动阻塞。
B: 需要人工干预，强制操作组成员（正确答案）
解释：出现脑裂或分区状况后，常常需要手工介入，判定哪些节点应继续服务、哪些需重新加入，防止数据不一致。
C: 集群会自动 shutdown 保证一致性
解释：错误。只有当丢失法定多数节点时，Group Replication 会自动停止写入（只读），但不会自动完全关机。
D: 可能有2节点和3节点的group replication同时在跑，建议停掉同步并诊断（正确答案）
解释：网络分区后，有可能出现分裂（split-brain），多个子集群都认为自己是主群，需要人工停用所有复制进程并诊断，防止产生数据冲突和不一致。
E: 集群会自动高可用，并自动更新ip_whitelist
解释：错误。白名单配置需要人为运维，不会自动移除不可达节点。

Q100

English:
Which three are types of information stored in the MySQL data dictionary?
• A) InnoDB buffer pool LRU management data
• B) Performance metrics
• C) Access control lists
• D) Server runtime configuration
• E) Server configuration rollback
• F) View definitions
• G) Stored procedure definitions

Answer: C, F, G

中文翻译：

MySQL 数据字典存储哪三类信息？
• A）InnoDB 缓冲池 LRU 管理数据
• B）性能指标
• C）访问控制列表
• D）服务器运行时配置
• E）服务器配置回滚
• F）视图定义
• G）存储过程定义

解析：

A: InnoDB buffer pool LRU management data
解释：LRU 管理数据属于内存运行时缓存控制信息，不是元数据，不存储于数据字典。
B: Performance metrics
解释：性能指标是动态统计数据，不存储在数据字典。
C: Access control lists (正确答案)
解释：访问控制列表（如用户、权限等）属于元数据，存储于数据字典。
D: Server runtime configuration
解释：运行时配置如变量值一般在配置文件或动态内存中，不属于数据字典。
E: Server configuration rollback
解释：配置回滚功能并非数据字典内容。
F: View definitions (正确答案)
解释：视图的定义即结构和背后SQL语句，作为元数据存储于数据字典。
G: Stored procedure definitions (正确答案)
解释：存储过程定义属于结构化元数据，数据字典永久保存。

Q101

English:
Which two queries are examples of successful SQL injection attacks?
• A) SELECT user, phone FROM customers WHERE name='; DROP TABLE users; --';
• B) SELECT id, name FROM user WHERE id=23 OR id=32 OR 1=1;
• C) SELECT id, name FROM user WHERE user.id= (SELECT members.id FROM members);
• D) SELECT email, passwd FROM members WHERE email= 'INSERT INTO members ('email', 'passwd') VALUES ('bob@example.com', 'secret');--';
• E) SELECT user, passwd FROM members WHERE user='?'; INSERT INTO members ('user', 'passwd') VALUES ('bob@example.com', 'secret');--';
• F) SELECT id, name FROM user WHERE id=23 OR id=32 AND 1=1;

Answer: B, E

中文翻译：

以下哪两个查询是成功的 SQL 注入攻击示例？
• A）SELECT user, phone FROM customers WHERE name='; DROP TABLE users; --';
• B）SELECT id, name FROM user WHERE id=23 OR id=32 OR 1=1;
• C）SELECT id, name FROM user WHERE user.id= (SELECT members.id FROM members);
• D）SELECT email, passwd FROM members WHERE email= 'INSERT INTO members ('email', 'passwd') VALUES ('bob@example.com', 'secret');--';
• E）SELECT user, passwd FROM members WHERE user='?'; INSERT INTO members ('user', 'passwd') VALUES ('bob@example.com', 'secret');--';
• F）SELECT id, name FROM user WHERE id=23 OR id=32 AND 1=1;

解析：

A:
解释：字符串整体被当作参数，未真正达到注入效果（被当作普通字符串解释），不是有效的注入。
B: （正确答案）
解释：WHERE 后存在 "OR 1=1"，可通过注入使查询匹配全部行，获取大量数据，属经典的SQL注入绕过。
C:
解释：合法的子查询，不存在SQL注入迹象。
D:
解释：字符串并未被直接当作SQL执行，而是被当作普通字符串处理，无法实际执行插入，并不是成功的注入。
E: （正确答案）
解释：拼接了多条SQL，并插入了新数据，是典型的多语句注入攻击示例。
F:
解释：虽然有 AND 1=1，但因为 1=1 恒真，不会改变原意（等同于无该条件）；也未绕过限制或注入其他语句。

Q103

English:
Which statement enables all roles granted to all users automatically?
• A) SET ROLE ALL;
• B) SET DEFAULT ROLE ALL TO '*'@'%';
• C) SET PERSIST activate_all_roles_on_login=ON;
• D) SET PERSIST mandatory_roles=ALL;

Answer: C

中文翻译：

哪个语句能自动启用所有用户授予的所有角色？
• A）SET ROLE ALL;
• B）SET DEFAULT ROLE ALL TO '*'@'%';
• C）SET PERSIST activate_all_roles_on_login=ON;
• D）SET PERSIST mandatory_roles=ALL;

解析：

A: SET ROLE ALL;
解释：该命令用于当前会话，手动激活所有分配给当前用户的角色，而不是登录时自动全局生效。
B: SET DEFAULT ROLE ALL TO '*'@'%';
解释：将所有角色定义为所有用户的“默认角色”，但每次登录仍需手动激活，不代表自动生效。
C: SET PERSIST activate_all_roles_on_login=ON; （正确答案）
解释：将全局参数 activate_all_roles_on_login=ON（可用 SET PERSIST 持久化），这样所有用户登录时将自动获得所有分配的角色，无需手动 SET ROLE。
D: SET PERSIST mandatory_roles=ALL;
解释：mandatory_roles 仅用于要求系统强制分配某一指定角色，值为ALL非法，不是官方用法。

Q104

English:
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

Answer: B, F

中文翻译：

以下哪两种情况会导致二进制日志切换？
• A）执行 FLUSH HOSTS
• B）超过 max_binlog_size
• C）超过 max_binlog_cache_size
• D）执行 SET sql_log_bin=1
• E）执行 SET sync_binlog=1
• F）执行 FLUSH LOGS

解析：

A: FLUSH HOSTS 只会刷新 host 缓存，与 binlog 无关。
B: max_binlog_size 超出后会触发 binlog 文件轮换。（正确答案）
C: max_binlog_cache_size 只是限制临时缓存区大小，不会直接影响 binlog 文件轮换。
D: SET sql_log_bin=1 只是动态开启/关闭 binlog，不触发日志轮换。
E: SET sync_binlog=1 是日志同步方式，与轮换无关。
F: FLUSH LOGS 会让所有日志文件（包括 binlog）轮换。（正确答案）

Log File Rotation

1. 日志文件轮换的必要性

日志文件会随着时间推移占用大量磁盘空间。
建议定期备份并删除旧日志文件，同时让新日志文件继续记录。
注意：如果启用了二进制日志用于主从复制，删除日志时需小心避免数据丢失。

2. FLUSH LOGS 的作用

备份后，应执行“flush logs”命令。
该操作会：
- 创建新的二进制日志文件（binary log）。
- 关闭并重新打开错误日志、通用查询日志、慢查询日志等。
流程提示：如需生成新日志，应先重命名当前日志文件，再执行 flush logs。

3. 定期轮转日志文件的建议

应安排日志文件定期轮换（如通过计划任务）。
可自定义脚本实现轮转，或使用 MySQL 自带的 mysql-log-rotate 脚本。

知识点总结：

定期轮换和备份日志文件有助于数据库系统健康、高效运行。
flush logs 命令是触发新日志生成的关键操作。
二进制日志涉及到数据恢复与复制，应谨慎处理不要轻易删除仍在使用的部分。

Q105

English:
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 SPATIAL INDEX (Population);
• E) ALTER TABLE world.city ADD INDEX (Population);
• F) ALTER TABLE world.city ADD FULLTEXT INDEX (Population);

Answer: E

中文翻译：

查看以下成功执行的建表语句：

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;

你想提升以下查询的性能：
SELECT Name FROM world.city WHERE Population BETWEEN 1000000 AND 2000000;
哪个更改可以使查询访问更少的行并成功执行？
• 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 SPATIAL INDEX (Population);
• E）ALTER TABLE world.city ADD INDEX (Population);
• F）ALTER TABLE world.city ADD FULLTEXT INDEX (Population);
解析：

A: ALTER TABLE world.city ADD INDEX (Name);
给Name字段加普通索引。对查询WHERE Population BETWEEN ...无意义，无帮助。
B: ALTER TABLE world.city ADD SPATIAL INDEX (Name);
给Name加空间索引，Name字段不是空间数据类型，不适用，且对数值范围无帮助。
C: ALTER TABLE world.city ADD FULLTEXT INDEX (Name);
给Name字段加全文索引，只适用于文本全文检索，而不是范围查找。
D: ALTER TABLE world.city ADD SPATIAL INDEX (Population);
给Population字段加空间索引，Population是整数类型，不能建空间索引且无意义。
E: ALTER TABLE world.city ADD INDEX (Population); （正确答案）
给Population加普通二级索引，这样WHERE Population BETWEEN ...会用上索引进行范围查找，极大提升了性能，能只访问符合条件的行。
F: ALTER TABLE world.city ADD FULLTEXT INDEX (Population);
给Population字段加全文索引，Population是int类型，不支持全文索引，也无意义。

Q106

English:

快照型备份可生成数据在某一时间点的副本（point-in-time copy）。
通常会对快照副本执行物理备份操作，而不是直接在生产数据上操作。

2. 提供“逻辑冻结”的文件系统

快照会为你提供一个逻辑上冻结（即不变）的文件系统副本，可用来进行MySQL备份。
需要注意：这个冻结的文件系统并不一定保证数据库镜像绝对一致（即一致性快照需要额外操作）。
当从这些快照恢复数据时，InnoDB需要执行自有的恢复流程（crash recovery），以防存在未完成事务。

3. 数据一致性要求

为了确保数据完全一致（特别是InnoDB表），可能需要在创建快照时关闭MySQL服务，或者对于MyISAM表加锁。
若数据文件分布于多个卷，通常需要对所有卷同时做快照，才能保证一致性。

4. 快照优势：极大缩短停机时间

快照型备份的最大优势在于极大减少数据库和业务系统的不可用（停机）时间。
拷贝/备份主数据时可以保持主业务环境正常运行，减少对应用的影响。

Q109

English:
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 adds more temporary workspace in addition to the innodb_tmpdir location.
• C) It moves all InnoDB tablespaces to the innodb_extras directory to enable a new innodb_data_home_dir to be defined.
• D) It is not necessary because innodb_data_home_dir is already defined.
• E) It allows scanning of other locations to discover more InnoDB tablespaces.

Answer: E

中文翻译：

查看以下输出：

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            |
+-----------------------------+------------------------+

你计划添加配置参数：
innodb_directories='/innodb_extras'
以下哪项正确？
• A）定义所有 InnoDB 表空间选项的起始父目录。
• B）在 innodb_tmpdir 位置之外添加更多临时工作空间。
• C）将所有 InnoDB 表空间移动到 innodb_extras 目录以允许定义新的 innodb_data_home_dir。
• D）不必要，因为已定义 innodb_data_home_dir。
• E）允许扫描其他位置以发现更多 InnoDB 表空间。

解析：

A: 这会将所有InnoDB表空间选项定义为相对于一个父目录。
- 解释：错误。该参数并不是改变路径引用的方式，而是作为扫描表空间的目录列表。
- B: 这会为innodb_tmpdir位置之外添加更多临时工作区。
  - 解释：错误。临时工作区由innodb_tmpdir控制，innodb_directories与之无关。
- C: 这会将所有InnoDB表空间移动到innodb_extras目录，以启用新的innodb_data_home_dir定义。
  - 解释：错误。该参数不会移动表空间，也不会替代innodb_data_home_dir。
- D: 这不是必需的，因为已经定义了innodb_data_home_dir。
  - 解释：错误。二者用途不同：一个用于主数据文件存储（innodb_data_home_dir），一个用于表空间自动发现（innodb_directories）。
- E: 这允许扫描其他位置，以发现更多InnoDB表空间。 （正确答案）
  - 解释：innodb_directories 控制InnoDB在自动发现“.ibd”等独立表空间文件时会在哪些目录下查找，无需都在数据目录或innodb_data_home_dir下，可以定义额外目录支持更灵活的数据文件位置。

Snapshot-Based Backups — innodb_directories

1. 参数功能简述

innodb_directories 用于定义MySQL在启动时，要扫描哪些目录来查找InnoDB表空间文件（如.ibd）。
主要用途：
- 当需要将表空间文件移入新位置或离线恢复时，告诉服务器在哪些地方查找表空间。
- 指定数据目录（datadir）以外的表空间目录（如通过绝对路径或自己分配的外部路径）。

2. 启动和恢复的应用场景

服务“离线”情况下，表空间文件被迁移或恢复到新位置时，需通过本参数指定所有需要扫描的目录。
崩溃恢复时（crash recovery），MySQL会根据redo日志中的引用，利用innodb_directories扫描所有相关路径来发现表空间文件。

3. 默认行为与参数叠加关系

默认值为NULL，但无论是否手动设置，该参数最终都包含：
- innodb_data_home_dir
- innodb_undo_directory
- datadir
即使未设置，也能自动扫描上述三个路径。
添加新路径时（如innodb_directories='/innodb_extras'），实际上是扩展扫描目录的范围，不会替换默认目录，而是叠加所有指定和默认项。

4. 参数格式与配置细节

可在启动命令行或配置文件中指定。
- 格式示例（多目录用分号分隔）：innodb_directories="dir1;dir2"
遍历子目录，去重后扫描。
不能用通配符（*、?等），只支持目录绝对路径或具体目录名。

5. 结论

关键作用：用于MySQL在启动及恢复时自动发现指定目录下的各类InnoDB表空间文件，此功能尤为重要于表空间跨目录迁移和恢复。
并不是所有InnoDB表空间都必须存放于innodb_data_home_dir；通过本参数可实现表空间灵活分布。

总结定位知识点：

innodb_directories 的正确理解与作用就是：“允许扫描其他位置，发现更多InnoDB表空间”。
**再次确认上一题答案：

E) It allows scanning of other locations to discover more InnoDB tablespaces.**

Q110

English:
Examine this command, which executes successfully:
mysqlpump --user=root --password > full_backup.sql
Which two databases will be excluded from this dump?
• A) world
• B) employee
• C) information_schema
• D) mysql
• E) sys

Answer: C, E

中文翻译：
查看以下成功执行的命令：
mysqlpump --user=root --password > full_backup.sql
以下哪两个数据库会被排除在此导出之外？
• A）world
• B）employee
• C）information_schema
• D）mysql
• E）sys
解析：
• mysqlpump 默认排除 information_schema 和 sys 系统数据库。

Q111

English:
You recently upgraded 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=caching_sha2_password
• B) ALTER USER user IDENTIFIED WITH mysql_native_password BY 'password';
• C) ALTER USER user IDENTIFIED WITH caching_sha2_password BY 'password';
• D) [mysqld] Default_authentication_plugin=sha256_password;
• E) ALTER USER user IDENTIFIED WITH sha256_password BY 'password';
• F) [mysqld] Default_authentication_plugin=mysql_native_password

Answer: B

中文翻译：

你最近升级到 MySQL 8.0，出现客户端错误：

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

必须在单主机上运行多个 MySQL 实例，以下哪三种方法支持？
• A）使用系统工具将实例绑定到独立 CPU。
• B）使用资源组将实例绑定到不同 CPU。
• C）使用不同 --datadir 启动 mysqld。
• D）运行 MySQL 容器。
• E）为每个实例使用不同选项文件启动 mysqld 或 mysqld_safe。
• F）使用 systemd 为每个实例配置不同设置。

解析：

A: 使用系统工具将每个实例锁定到专属CPU上。
- 解释：通过taskset、cgroups等可以约束CPU归属，但这只是资源限制手段，不是MySQL本身支持的多实例官方管理方式。
B: 使用MySQL资源组锁定每个实例到不同CPU。
- 解释：资源组是MySQL 8新功能，但它作用于“同一实例”内的线程分组，不能用于管理多个mysqld进程。
C: 启动mysqld时为每个实例设定不同的--datadir参数。 （正确答案）
- 解释：多实例运行时必须为每个实例分配独立的数据目录。
D: 运行多个MySQL Server的docker容器。
E: 使用不同的配置文件分别启动mysqld或mysqld_safe。 （正确答案）
- 解释：MySQL支持通过不同配置文件参数（端口、datadir、socket等）多开实例。
F: 使用systemd为每个实例指定不同配置启动。 （正确答案）
- 解释：systemd可以管理多服务

MySQL 官方文档多实例运行

1. 应用场景

在同一台主机上运行多个 MySQL 实例可以用于测试新版本、为不同用户（如ISP客户）提供独立服务等需求。
每个实例可以共用同一个 mysqld 二进制文件，也可以用不同版本的二进制程序，完全独立。

2. 实现多实例的核心要求

每个实例须有唯一的数据目录 datadir（--datadir=dir_name），这是最基本的资源隔离要求，否则文件和表结构会冲突。
每个实例须指定不同的端口号（--port），防止网络冲突。
每个实例须指定不同的 socket 路径（--socket），系统级通讯不冲突。
如果是 Windows，还需指定不同的命名管道和共享内存名。
每个实例的各类日志文件（如 general log、binlog、slow log、error log）都应指定不同文件名。
可以为每个实例分配独立的临时目录（--tmpdir），方便管理。
如果用不同版本，可以各自有自己的 basedir（--basedir）。

3. 配置方法

命令行参数：直接为每个 mysqld 进程指定不同参数
不同 option file（配置文件）：推荐做法，利用 --defaults-file=xxx，每个实例一个配置文件，里面写独有路径与设置
启动管理工具：如 mysqld_safe、systemd（自定义 unit）、docker/container 实现更强封装部署

Q117

English:
An attempt to recover an InnoDB Cluster fails with messages:

host3:3377 ssl JS > dba.rebootClusterFromCompleteOutage()  
Reconfiguring the default cluster from complete outage.  
The instance 'host1:3377' was part of the cluster configuration. Rejoin? [y/N]: y  
The instance 'host2:3377' was part of the cluster configuration. Rejoin? [y/N]: y  
Dba.rebootClusterFromCompleteOutage: The active session instance isn't the most updated compared to ONLINE instances.  
Please use the most up to date instance: 'host1:3377'. (RuntimeError)

Which statement is true?
• A) The cluster is running and has at least one ONLINE instance.
• B) The instance on host3 must be synchronized from host1 using cluster.addInstance('host1:3377').
• C) The most up-to-date instance can be determined by comparing GTID sets with GTID_SUBSET(set1, set2).
• D) The active session instance is invalid and must be recreated using shell.connect('host3:3377').
• E) The instance on host3 must be rebuilt from a backup of the primary.

Answer: C

中文翻译：

尝试恢复 InnoDB 集群失败，提示：

host3:3377 ssl JS > dba.rebootClusterFromCompleteOutage()  
重配置默认集群…  
实例 'host1:3377' 是集群成员，是否重新加入？  
实例 'host2:3377' 是集群成员，是否重新加入？  
当前会话实例不是最新，请使用最新实例 'host1:3377'。

以下哪项正确？
• A）集群运行中，至少有一个 ONLINE 实例。
• B）host3 实例需用 cluster.addInstance('host1:3377') 从 host1 同步。
• C）可通过比较 GTID 集合 GTID_SUBSET(set1, set2) 判断最新实例。
• D）当前会话实例无效，需用 shell.connect('host3:3377') 重建。
• E）host3 实例必须用主节点备份重建。

解析：

A) 集群正在运行且至少有一个 ONLINE 实例。
错误。既然执行了 "rebootClusterFromCompleteOutage" 说明整个集群已完全不可用，才需要用这个救援命令。
B) host3 上的实例必须通过 cluster.addInstance('host1:3377') 从 host1 同步。
错误。这里的恢复不是通过 addInstance 实现的，而是要直接在数据最新的 host1 节点上重启整个集群。
C) 通过 GTID_SUBSET(set1, set2) 比较 GTID 集可以确定最“新”的实例。
正确！MySQL InnoDB Cluster 判定哪个节点最先进，就是根据 GTID 集。GTID_SUBSET 可用于判断事务集包含关系和节点“新旧”。
（正确答案）
D) 当前会话实例无效，必须通过 shell.connect('host3:3377') 重新连接。
错误。连接本身没问题，只是数据不够新，用这个节点会导致事务丢失。
E) host3 上的实例必须通过主库备份重建。
错误。恢复集群时无需强制用备份，只需用事务最完整的节点恢复即可，其它节点稍后可以补同步。

Q118

English:
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

Answer: A

中文翻译：

查看部分进程列表：

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

查看查询：

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;

该查询提供了什么信息？
• A）连接号为 10 的连接使用的总内存
• B）连接号 10 用户所有连接使用的总内存
• C）前 10 个线程使用的总内存
• D）线程号为 10 的线程使用的总内存
• E）线程号 10 用户所有连接使用的总内存
• F）前 10 个连接使用的总内存

解析：

A) 由连接编号10使用的内存总量
- 正确。
  - processlist 的 Id=10，代表第10号连接（通常是当前活跃连接的唯一标识），SQL 只统计 WHERE t.PROCESSLIST_ID=10 的线程对象。
  - 查询统计的是属于该连接的所有事件分配之内存。
B) 属于连接10所用用户的所有连接的内存总量
- 错误。SQL 只限定一个特定的 processlist Id，而不是所有用户的连接。
C) 前10个线程使用的内存总量
- 错误。并未按线程号排序或前十，仅仅只关注 processlist_id = 10.
D) 线程编号为10使用的内存总量
- 错误。线程编号不等于 processlist_id，且数据是按 processlist_id 过滤的。
E) 属于线程10所用用户的所有连接的内存总量
- 错误。同理只查一个连接，不是所有相关连接。
F) 前10个连接使用的内存总量
- 错误。只关注 Id=10，不包括前十个。

Q119

English:
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

Answer: B, C, E

中文翻译：

以下哪三项设置控制 MySQL 服务器上所有线程共享的全局缓冲区？
• A）tmp_table_size
• B）innodb_buffer_pool_size
• C）table_open_cache
• D）sort_buffer_size
• E）key_buffer_size

解析：

A) tmp_table_size
- 不是全局缓冲区。该参数定义单次内部临时表的最大大小，是每个线程/查询级别的局部缓冲，不是全局共享。
B) innodb_buffer_pool_size
- 全局缓冲区。它是 InnoDB 存储引擎的核心缓存（用于缓冲数据页、索引页等），整个实例共享，一次性全局分配。
- 正确答案
C) table_open_cache
- 全局缓冲区。它决定了服务器同时可以缓存多少已打开的表描述符，所有线程共享。
- 正确答案
D) sort_buffer_size
- 不是全局缓冲区。它是线程级（每个会话、每个连接分配一次），为排序操作单独分配。
E) key_buffer_size
- 全局缓冲区。MyISAM 存储引擎的主索引缓存区，整个服务器实例共享。
- 正确答案

Q120

English:
You plan to take daily full backups, including 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

Answer: B

中文翻译：

计划每天做全备份，包括 ndbinfo 和 sys（内部）数据库，以下哪个命令能并行备份数据库？
• 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

解析：

• mysqlpump 支持并行备份,默认不导出 performance_schema、ndbinfo、sys、INFORMATION_SCHEMA，--include-databases=% 表示包含所有数据库。

Q121

English:
Examine these statements and output:

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

Which statement is true?
• A) The user failed to define a username; connecting username defaulted to ''@'%'.
• B) The user is authorized as rsmith@localhost.
• C) The user is authenticated as the anonymous proxy user ''@'%'.
• D) The user is logged in with --user=accounting option.
• E) The user is authorized as accounting@localhost.

Answer: E

中文翻译：

查看以下语句和输出：

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

以下哪项正确？
• A）用户未定义用户名，连接用户名默认为 ''@'%'.
• B）用户授权为 rsmith@localhost。
• C）用户认证为匿名代理用户 ''@'%'。
• D）用户以 --user=accounting 选项登录。
• E）用户授权为 accounting@localhost。

解析：

• CURRENT_USER 显示代理用户，授权用户是 accounting@localhost。

Q122

English:
Which two actions can obtain information about deadlocks?
• A) Run SHOW ENGINE INNODB MUTEX from MySQL client.
• B) Enable the innodb_status_output_locks global parameter.
• C) Enable the innodb_print_all_deadlocks global parameter.
• D) Run SHOW ENGINE INNODB STATUS from MySQL client.
• E) Use the sys.innodb_lock_waits view.

Answer: C, D

中文翻译：

以下哪两项操作可以获取死锁信息？
• A）从 MySQL 客户端运行 SHOW ENGINE INNODB MUTEX。
• B）启用全局参数 innodb_status_output_locks。
• C）启用全局参数 innodb_print_all_deadlocks。
• D）从 MySQL 客户端运行 SHOW ENGINE INNODB STATUS。
• E）使用 sys.innodb_lock_waits 视图。

解析：

A) SHOW ENGINE INNODB MUTEX
- 只显示互斥量等待（mutex），不包含死锁诊断信息。
- 错误。
B) innodb_status_output_locks
- 控制 SHOW ENGINE INNODB STATUS 和 error log 中锁的详细内容，但并不会专门记录死锁细节。
- 常用于锁等待监控，而不是死锁专门信息，部分版本有帮助但不是主用。
- 不是最佳答案。
C) innodb_print_all_deadlocks
- 启用后，每当发生死锁时，信息会写入 error log，可持续收集历史死锁情况。
- 正确答案。
D) SHOW ENGINE INNODB STATUS
- 此命令可以直接获取到最后一次死锁的详细信息（包括涉及的 SQL 和锁信息），查询时直接显示，非常常用。
- 正确答案。
E) sys.innodb_lock_waits
- 展示当前锁等待，但无法获得死锁历史或死锁事件具体详情，只能查看活跃的锁等待。
- 错误。

Q123

English:
Examine this statement, which executes successfully:

CREATE TABLE world.city (
  ID int NOT NULL AUTO_INCREMENT,
  Name char(35) NOT NULL DEFAULT '',
  CountryCode char(35) 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);
Answer: F
中文翻译：
以下建表语句成功执行，想提升查询以下语句的性能：
sql
SELECT Name FROM world.city WHERE Population BETWEEN 1000000 AND 2000000;
哪项更改能减少扫描行数并加速查询？
• A）添加 Name 字段索引
• B）添加 Name 字段空间索引
• C）添加 Name 字段全文索引
• D）添加 Population 字段全文索引
• E）添加 Population 字段空间索引
• F）添加 Population 字段索引
解析：
• 查询条件是 Population 范围查询，添加普通索引 (Population) 可减少访问行数。

Q124
English:
User fwuser@localhost registered with MySQL Enterprise Firewall, granted privileges on SAKILA database.
Given commands and output:
sql
SELECT MODE FROM INFORMATION_SCHEMA.MYSQL_FIREWALL_USERS WHERE USERHOST='fwuser@localhost';
+----------+
| MODE |
+----------+
| PROTECTING |
+----------+

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 execute:

CALL mysql.sp_set_firewall_mode('fwuser@localhost', 'RESET');

Which two are true?
• A) The fwuser@localhost account is removed from mysql.user.
• B) The INFORMATION_SCHEMA.MYSQL_FIREWALL_WHITELIST table is truncated.
• C) The whitelist for fwuser@localhost is truncated.
• D) The mysql.firewall_users table is truncated.
• E) The firewall resets all options to default values.
• F) The fwuser@localhost mode is set to DETECTING.
• G) The fwuser@localhost mode is set to OFF.
Answer: C, G
中文翻译：
用户 fwuser@localhost 注册了 MySQL Enterprise Firewall，拥有 SAKILA 数据库权限。执行命令查看模式和白名单后，执行：

CALL mysql.sp_set_firewall_mode('fwuser@localhost', 'RESET');
以下哪两项正确？
• A）fwuser@localhost 账号从 mysql.user 表删除。
• B）INFORMATION_SCHEMA.MYSQL_FIREWALL_WHITELIST 表被清空。
• C）fwuser@localhost 的白名单被清空。
• D）mysql.firewall_users 表被清空。
• E）防火墙所有选项重置为默认值。
• F）fwuser@localhost 模式设置为 DETECTING。
• G）fwuser@localhost 模式设置为 OFF

解析：

A) The fwuser@localhost account is removed from mysql.user.
- 错误。防火墙 RESET 操作仅影响 Enterprise Firewall 的规则，不删除用户账号本身。
B) The INFORMATION_SCHEMA.MYSQL_FIREWALL_WHITELIST table is truncated.
- 错误。RESET 只影响指定用户对应的规则，不会全表清空。
C) The whitelist for fwuser@localhost is truncated.
- 正确。RESET 会移除该用户对应的所有白名单（SQL 规则）条目。
D) The mysql.firewall_users table is truncated.
- 错误。只移除对应用户行，不会清空整个表。
E) The firewall resets all options to default values.
- 错误。只是指定用户的规则和模式被重置，不是全局选项。
F) The fwuser@localhost mode is set to DETECTING.
- 错误。RESET 会把该用户的 firewall MODE 状态设置为 OFF。
G) The fwuser@localhost mode is set to OFF.
- 正确。OFF 是 RESET 的目标状态。

防火墙配置档案（profile）运行模式

每个注册到 MySQL Enterprise Firewall 的配置档案（profile）可设置下列运行模式之一：

OFF（关闭）
禁用该 profile，防火墙不对该 profile 的连接做任何防护或审计，即完全忽略。
RECORDING（录制/训练）
防火墙训练模式。所有该 profile 对应客户端发来的 SQL 都会被记录为“指纹”（标准化语句，与参数无关），这些指纹规则构成该 profile 的白名单。
组 profile（绑定到一组用户）训练时，还可限定只通过“训练成员”用户采集语句。
PROTECTING（防护）
白名单保护模式。仅允许已录制为规则的 SQL 执行，未录入的语句会被拒绝（如果 mysql_firewall_trace 开启，则拒绝语句写入 error log）。RECORDING 模式训练完成后，常需切换到 PROTECTING 模式以提升安全性。
DETECTING（检测）
检测但不拦截。所有与白名单不匹配的 SQL 会被记录进 error log，但实际不会阻止其执行，仅用于审计/预警。

2. RESET 模式特殊说明

RESET 并非真实存储的模式值。
- 执行“RESET”时，防火墙会删除该 profile 现有所有规则（白名单），并将其模式置为 OFF（关闭）。
- 所以，RESET 后的状态是 OFF，而不是 DETECTING 或其它。

Q125

English:
A newly deployed replication master has a 10/90 read/write ratio, dataset ~28G ±10%. Storage consists of two local PCI-E enterprise disks /data1 and /data2. Server dedicated to MySQL instance with 64G RAM. my.cnf excerpt:

[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

Answer: B, C, E, H

中文翻译：

新部署的主库，读写比 10/90，数据集约 28G，存储为本地两块 PCI-E 企业级盘 /data1 和 /data2，服务器专用，内存 64G，my.cnf 内容：

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

以下哪四项调整可最大提升性能且不牺牲数据完整性？
• A）关闭 innodb doublewrite
• B）将 innodb 日志组目录设置到 /data2/
• C）将 innodb 日志文件大小改为 1G
• D）将 undo 目录设置到 /dev/shm
• E）将 binlog 日志目录设置到 /data2/
• F）innodb_flush_log_at_trx_commit=0
• G）sync_binlog=0
• H）innodb_buffer_pool_size 增加到 32G
• I）禁用 binlog
解析：

A) innodb_doublewrite=off
- 不推荐！关闭双写可提升性能但丢失数据完整性，crash时有脏页风险。
B) innodb_log_group_home_dir=/data2/
- 正确。将 redo log 和数据放在不同的物理盘，可极大降低 IO 冲突，提高并发写入能力。
C) innodb_log_file_size=1G
- 正确。增大 redo log 文件，可减少 checkpoint 频率，降低写 IO 放大和潜在 stall，对大量写入场景提升明显。
D) innodb_undo_directory=/dev/shm
- 不推荐！如果将 undo 放内存盘，断电丢数据，损害数据完整性。
E) log-bin=/data2/
- 正确。binlog 写入单独磁盘——主库写性能受益，并且复制主须开启 binlog，不能关闭。
F) innodb_flush_log_at_trx_commit=0
- 不推荐。此选项虽提高写并发但丢失崩溃后已提交事务，牺牲了事务持久性。
G) sync_binlog=0
- 不推荐。binlog 不同步，对主库宕机时保证复制一致性有风险。
H) innodb_buffer_pool_size=32G
- 正确。内存充裕时，适当提升 buffer_pool 可缓解 IO，尤其满载28G数据后，还可缓冲增长量或索引页。
I) disable-log-bin
- 不推荐。主库不能关闭 binlog，否则无法用于主从复制。

Q126

English:
You have a MySQL instance with GTIDs enabled running more than 100 transactions per second. You discover some data was deleted at a particular time. You decide to recover from binary logs.
Which two commands can restore the database to the point right before the deletion?
• A) mysqlbinlog --skip-gtids ...
• B) mysqlbinlog --stop-position ...
• C) START SLAVE SQL_THREAD UNTIL SQL_BEFORE_GTIDS=...
• D) mysqlbinlog --stop-datetime ...
• E) START SLAVE IO_THREAD UNTIL SQL_BEFORE_GTIDS=...

Answer: A, C

中文翻译：
开启 GTID 的 MySQL 实例每秒处理 100+ 事务，发现某时点数据被删除，决定用二进制日志恢复。
哪两个命令能恢复到删除前？
• A）mysqlbinlog --skip-gtids ...
• B）mysqlbinlog --stop-position ...
• C）START SLAVE SQL_THREAD UNTIL SQL_BEFORE_GTIDS=...
• D）mysqlbinlog --stop-datetime ...
• E）START SLAVE IO_THREAD UNTIL SQL_BEFORE_GTIDS=...

解析：

• 通过 mysqlbinlog --skip-gtids 过滤 GTID，结合 START SLAVE SQL_THREAD UNTIL SQL_BEFORE_GTIDS 可精准恢复。

Q127

English:
You want to find the number of examined rows for completed queries with all relevant monitoring enabled.
Which three sources contain the number of examined rows?
• A) Performance Schema
• B) Information Schema
• C) Error log
• D) General query log
• E) sys schema
• F) Slow query log

Answer: A, E, F

中文翻译：
查询已完成 SQL 的扫描行数，相关监控已开启。
以下哪三个来源包含扫描行数信息？
• A）Performance Schema
• B）Information Schema
• C）错误日志
• D）通用查询日志
• E）sys schema
• F）慢查询日志
解析：

A) Performance Schema
- 正确。 Performance Schema 可跟踪查询事件细节，包含“扫描行数”（例如 events_statements_history 表的 rows_examined 字段）。
B) Information Schema
- 错误。 Information Schema 展示表/库结构和实时运行状态，但不记录每条SQL的已扫描行数（一般仅有表、索引、视图元信息）。
C) Error log
- 错误。 Error log 仅针对严重错误/警告，不包含 SQL 查询和扫描行信息。
D) General query log
- 错误。 General log 只记录语句本身，不会记录被扫描的行数，仅供审计。
E) sys schema
- 正确。 sys 库是基于 performance_schema/information_schema 的综合视图，部分视图（如 sys.statements_with_runtimes_history）直接显示 rows_examined 字段。
F) Slow query log
- 正确。 启用慢日志且记录所有语句时，slow log 记录每条慢查询的“扫描行数”（Rows_examined 字段）。

Q128

English:
Identify two ways to significantly improve data security.
• A) Run mysqld as system admin account (e.g. root)
• B) Use a private network behind a firewall
• C) Use only networked disks for mysqld
• D) Configure MySQL with only one admin account
• E) Use only local or attached disks and dedicated OS account for mysqld

Answer: B, E

中文翻译：
以下哪两项显著提升数据安全？
• A）mysqld 以系统管理员账号运行（如 root）
• B）使用防火墙后的私有网络
• C）mysqld 只用网络磁盘
• D）MySQL 只配置一个管理员账户
• E）mysqld 只用本地或附加磁盘，且有独立系统账号

解析：

A) 以系统管理员账号（如 root）身份运行 mysqld
- 错误。这是最不安全的做法，若 mysqld 漏洞被利用，入侵者可直接控制整个操作系统。
B) 在防火墙后的专用网络中运行
- 正确。私有网络+防火墙能隔绝非授权外部访问，大幅提升防护等级。
C) 仅使用网络存储部署 mysqld
- 错误。网络存储一般增加攻击面和复杂度，且性能和可靠性也可能受网络影响，不算安全措施。
D) 只设置一个管理员账号
- 错误。管理员账号越少越好，但唯一账号危及审计（无多账号溯源），且若泄露威胁更大，不是安全最佳实践。
E) 仅用本地/直连磁盘，并为 mysqld 使用专用操作系统账号
- 正确。物理本地盘可防止远端窃取和篡改，专用账号隔离可降低权限被滥用风险，遵循最小权限原则。

Q129

English:
Which characters are most commonly used in SQL injection attacks?
• A) < and >
• B) null (\0) and newline (\n)
• C) ^ and $
• D) + and -
• E) ' and "

Answer: E

中文翻译：
SQL 注入攻击最常用哪些字符？
• A）< 和 >
• B）null (\0) 和换行符 (\n)
• C）^ 和 $
• D）+ 和 -
• E）单引号 ' 和双引号 "
解析：
• 注入常用引号以结束字符串或注释。

Q130

English:
Given these commands executed on host ic1:

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})

All nodes have:
group_replication_consistency=BEFORE_ON_PRIMARY_FAILOVER
Which statement is true if primary node ic1 fails?
• A) ic2 becomes primary; existing transactions are stale and rolled back
• B) ic3 becomes primary; existing transactions are stale and rolled back
• C) ic3 becomes primary and is ignored until backlog completes
• D) Only two nodes remain; election uncertain and manual
• E) ic2 becomes primary and is ignored until backlog completes

Answer: C

中文翻译：

ic1 主机执行以下命令创建集群和添加节点，所有节点配置为：
group_replication_consistency=BEFORE_ON_PRIMARY_FAILOVER
若主节点 ic1 故障，以下哪项正确？
• A）ic2 成为新主，现有事务视为过时回滚
• B）ic3 成为新主，现有事务视为过时回滚
• C）ic3 成为新主，直到事务积压完成前被忽略
• D）只剩两节点，选举不确定需人工处理
• E）ic2 成为新主，直到事务积压完成前被忽略

解析：

构建 InnoDB Cluster，三节点设有不同 memberWeight：
- ic1: 35
- ic2: 25
- ic3: 50
配置 group_replication_consistency=BEFORE_ON_PRIMARY_FAILOVER，表明自动主节点切换前需保证一致性

选项分析

选举规则：MySQL Group Replication/InnoDB Cluster 故障切换时，新的主节点被自动选为权重最高且与集群状态一致的成员。
ic1 挂掉后，剩下 ic2(25) 和 ic3(50)，ic3 权重最高，优先成为新的 primary（主节点）。
group_replication_consistency=BEFORE_ON_PRIMARY_FAILOVER 要求 failover 前确保所有写在旧主上的事务都提交并同步，因此不会出现“事务变成 stale/回滚”。
如果新主节点有 backlog（滞后），系统会等待 backlog 日志全部追上才真正启用。期间请求会挂起，但不会被忽略。
带 backlog 时不会“忽略”新主，仅是应用 backlog 完成前不能服务写入请求。

具体分析选项：

A) ic2 权重低，不会成为主
B) ic3 权重高，会成为主，但事务不会因为 stale 回滚（BEFORE_ON_PRIMARY_FAILOVER 会等待一致性）
C) ic3 成为主，可能有 backlog（日志滞后），系统会等 backlog 应用完才正式切换主节点——正确
D) 剩下两节点，不会影响主选举，因为 quorum/自动选主机制成立，人工不需要介入
E) ic2 权重低，不会成为主

Q131

English:
You upgraded MySQL binaries from 5.7.28 to 8.0.18 in-place. On first start of 8.0.18, you see errors like:

[ERROR] Table upgrade required. Please do "REPAIR TABLE 'columns_priv'" or dump/reload to fix it!  
[ERROR] Failed to open mysql.event Table.  
[ERROR] Failed to Populate DD tables.  
[ERROR] Aborting

Which step(s) will resolve the errors?
• A) Start mysqld again using --upgrade=FORCE option.
• B) Run myisamchk --update-state on system tables.
• C) Run mysqlcheck --repair on system tables.
• D) Remove redo logs, revert binaries to 5.7.28, prepare tables, then upgrade again.
• E) Run mysqlcheck --check-upgrade on system tables.

Answer: A

中文翻译：
将 MySQL 从 5.7.28 原地升级到 8.0.18，首次启动出现表升级错误。
如何解决？
A) 用 --upgrade=FORCE 参数重新启动 mysqld
B) 对系统表运行 myisamchk --update-state
C) 对系统表运行 mysqlcheck --repair
D) 删除 redo 日志并回退到 5.7.28，处理表后再升级
E) 对系统表运行 mysqlcheck --check-upgrade

解析：

A) Start mysqld again using --upgrade=FORCE option.
- 正确。
  - MySQL 8.0+ 启动参数 --upgrade=FORCE 会强制重建系统表且自动进行必要修复，是官方推荐的修正办法之一。例如，对于已损坏的 mysql.* 系统表，自动升级并修复。
B) Run myisamchk --update-state on system tables.
- 错误。
  - 8.0 所有系统表均已转为 InnoDB，不再适用 myisamchk 工具（myisamchk 仅用于 MyISAM引擎）。
C) Run mysqlcheck --repair on system tables.
- 错误。
  - mysqlcheck --repair 无法修复 InnoDB 表。
D) Remove redo logs, revert binaries to 5.7.28, prepare tables, then upgrade again.
- 不推荐（极端情况可选，但不是官方建议且有数据丢失风险）。
E) Run mysqlcheck --check-upgrade on system tables.
- 错误。
  - --check-upgrade 主要用于检查 schema 兼容性（列类型、关键字等），无法自动修复报错的系统表结构。

5. 相关知识点总结

官方推荐：升级 8.0 后如遇 “Table upgrade required” 等系统表兼容问题，首选 --upgrade=FORCE
8.0 以后不再用 myisamchk 检查或修复系统表（系统表已经转 InnoDB）。
回退方案 D 为最后选项，涉及大量人工及风险，通常不用。
check-upgrade 只能做 schema 检查，不作修复。

Q132

English:
You plan to upgrade MySQL 5.7 to 8. You installed MySQL Shell 8. The following command is executed from OS shell:

mysqlsh --uri root@localhost:3306 --util check-for-server-upgrade

Which statement is true?
• A) It documents any problems with 5.7 tables to prepare upgrade to 8.
• B) It fails because operation name must be camelCase.
• C) It fixes problems with 5.7 tables for upgrade.
• D) Clearing prior result history is mandatory before rerunning.
• E) It fails because checkForServerUpgrade must be run inside active shell session as util method.
• F) Running it is mandatory for 8.0 auto-upgrade to work properly.

Answer: A

中文翻译：
计划升级 MySQL 5.7 到 8，已安装 MySQL Shell 8，执行命令：

mysqlsh --uri root@localhost:3306 --util check-for-server-upgrade
以下哪项正确？
• A）文档记录 5.7 表问题，准备升级到 8
• B）失败，操作名必须驼峰式
• C）修复 5.7 表问题
• D）必须清空历史结果后才能重跑
• E）失败，必须在 shell 会话内以 util 方法执行
• F）必须运行才能保证自动升级正常

解析：

A) 它会记录所有不兼容 8.0 的 5.7 表问题，升级前准备。
- 正确。 该命令会扫描老版本实例（如5.7）并分析不支持、待重命名等兼容性问题，输出升级风险报告，但不做修改。
B) 必须驼峰命名，否则命令失败。
- 错误。 工具支持用连字符/下划线或驼峰（兼容多种写法，不会因非驼峰失败）。
C) 它自动修正表，这是升级修复命令。
- 错误。 工具只检查、不修正，只输出兼容建议。
D) 必须清历史结果再运行。
- 错误。 可以多次运行，不需特殊清理。
E) 只能在 mysqlsh 交互式 util 下运行，不能直接命令行用。
- 错误。 mysqlsh 支持命令行 --util 直接运行，并输出结果到终端。
F) 8.0 “自动升级”必须先运行它。
- 错误。 虽然建议先跑，但不是升级8.0自动机制的强制条件。

5. 相关知识点总结

mysqlsh --util check-for-server-upgrade 是官方建议的 MySQL 5.7→8.0 升级前风险分析工具。
它检查表名、关键字、charsets、分区、系统表等各类兼容性问题，但只输出报告，不做修正。
运行方式灵活可在 shell 或交互端运行，不改动原数据库，仅供评估和手动修正用。

Q133

English:
Database test contains InnoDB table city:

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 files exist in the test folder in the data directory?
• A) city.MYD, city.MYI, city.sdi
• B) city.ibd
• C) city.ibd, city.sdi
• D) city.ibd, city.frm
• E) city.ibd, city.frm, city.sdi

Answer: B

中文翻译：
数据库 test 中 InnoDB 表 city，表空间为 innodb_file_per_table，数据目录下 test 文件夹包含什么文件？
• A）city.MYD、city.MYI、city.sdi
• B）city.ibd
• C）city.ibd、city.sdi
• D）city.ibd、city.frm
• E）city.ibd、city.frm、city.sdi
解析：
• InnoDB 表开启独立表空间时，只有 .ibd 文件。.sdi在用户表空间不在数据目录

Q134

English:
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()

Answer: D, G

中文翻译：
以下哪两个 MySQL Shell 命令不包含在 InnoDB Cluster 创建过程中？
• A）cluster.addInstance()
• B）dba.configureLocalInstance()
• C）dba.checkInstanceConfiguration()
• D）cluster.setPrimaryInstance()
• E）dba.configureInstance()
• F）dba.createCluster()
• G）cluster.forceQuorumUsingPartitionOf()
解析：

A) cluster.addInstance()
- 创建集群后添加新实例，是标准集群部署步骤，需要用到。
B) dba.configureLocalInstance()
- 用于本机（local）实例自动配置，属于辅助工具。不是标准创建流程，常用于沙箱或特殊本地实验环境。
C) dba.checkInstanceConfiguration()
- 安装预检测，判断实例设置是否符合集群要求，通常在建集群前手动运行。不是集群创建必备步骤，只是建议辅助手段。
D) cluster.setPrimaryInstance()
- 设置当前主节点，仅用于集群已存在且需手动主切换，不是正常建集群步骤。（排除）
E) dba.configureInstance()
- 辅助配置节点（端口、防火墙、GTID等）。
F) dba.createCluster()
- 集群创建的核心命令，必须使用。
G) cluster.forceQuorumUsingPartitionOf()
- 强制分区恢复法定人数(quorum)，仅用于分区损坏/脑裂修复场景，不在集群正常创建流程。（排除）

需要选两项“不包含在 InnoDB Cluster 创建过程”的命令，结合标准官方流程，最典型的排除选项是 D（主切换）和 G（分区恢复），因为它们为集群运维/管理中的特殊操作

Q135

English:
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

Answer: B, C, D, G

中文翻译：
MySQL 客户端通过 --protocol 选项连接服务器时，可指定哪四种连接方式？
• A）IPv4
• B）SOCKET
• C）MEMORY
• D）PIPE
• E）IPv6
• F）FILE
• G）TCP
• H）DIRECT
解析：
• 支持的协议包括 SOCKET（Unix socket）、MEMORY（内存共享）、PIPE（Windows 命名管道）、TCP。

Q136

English:
Which two authentication plugins require the plaintext 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

Answer: A, D

中文翻译：
哪两个认证插件需要明文客户端插件支持认证？
• A）LDAP 认证
• B）SHA256 认证
• C）Windows 本地认证
• D）PAM 认证
• E）MySQL 原生密码认证
• F）LDAP SASL 认证
解析：
• LDAP 和 PAM 认证依赖明文客户端插件。

Q137

English:
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

Answer: D

中文翻译：
Oracle Linux 7 上通过 RPM 安装 MySQL 后，默认数据目录在哪里？
• A）/usr
• B）/usr/mysql
• C）/etc/my.cnf
• D）/var/lib/mysql
• E）/usr/bin

解析：

A) /usr
- 该目录用于存储二进制程序和共享只读数据，不用于数据库文件。错误
B) /usr/mysql
- 不是 MySQL 在 Linux 下的标准数据目录，RPM版不会使用该路径。错误
C) /etc/my.cnf
- 这是配置文件位置，不是数据目录。错误
D) /var/lib/mysql
- 正确。在 RHEL/CentOS/Oracle Linux 等 RPM 系发行版下，MySQL 默认数据目录均为 /var/lib/mysql（存储所有数据库的表、文件等实际数据）。
E) /usr/bin
- 存放可执行文件（如mysqld、mysql等），不是数据目录。错误

Q138

English:
You must store connection parameters for connecting a Linux MySQL client to a remote Windows MySQL server on port 3309.
Which four methods can be used to configure user, host, and database parameters?
• A) Execute command in a bash script
• B) Embed login info in SSH tunnel definition
• C) Define a UNIX socket
• D) Execute mysql_config_editor to configure user connection
• E) Configure ~/.ssh/config for public key authentication
• F) Use usermod to store static user info
• G) Execute mysqladmin to configure user connection
• H) Configure ~/.my.cnf
• I) Configure environment variables

Answer: A, D, H, I

中文翻译：
Linux MySQL 客户端连接远程 Windows MySQL 服务器（端口 3309），以下哪四种方式可配置用户、主机和数据库参数？
• A）在 bash 脚本中执行命令
• B）在 SSH 隧道定义中嵌入登录信息
• C）定义 Unix socket
• D）执行 mysql_config_editor 配置连接
• E）配置 ~/.ssh/config 公钥认证
• F）用 usermod 存储用户信息
• G）执行 mysqladmin 配置连接
• H）配置 ~/.my.cnf
• I）配置环境变量

解析：

A) Execute command in a bash script (脚本内写参数)
- 正确。可以写入连接参数到 bash 脚本（如 mysql -uuser -hhost -p dbname），作为一种参数保存/自动化方式。
B) Embed login info in SSH tunnel definition
- 错误。SSH 隧道只负责加密转发，不存储数据库 user/host/db 参数信息。
C) Define a UNIX socket
- 错误。UNIX socket 仅指定本地连接方式，不涉及“远程连接”及主机/用户/库参数。
D) Execute mysql_config_editor to configure user connection
- 正确。mysql_config_editor 可加密保存用户主机端口等信息，客户端读取 login path 自动填充参数。
E) Configure ~/.ssh/config for public key authentication
- 错误。只涉及 SSH 登录（远程 shell），不存储 MySQL 具体连接参数。
F) Use usermod to store static user info
- 错误。usermod 是 Linux 用户管理命令，和 MySQL 无关。
G) Execute mysqladmin to configure user connection
- 错误。mysqladmin 用于管理服务器本身，不用于保存客户端连接配置。
H) Configure ~/.my.cnf
- 正确。该文件可写入 [client] user/host/database 等配置，mysql 客户端自动读取。
I) Configure environment variables
- 正确。可用如 MYSQL_USER、MYSQL_PWD、MYSQL_DATABASE、MYSQL_HOST 等环境变量，自动传递给 MySQL 客户端。

5. 相关知识点总结

MySQL 客户端连接参数可配置在：
- .my.cnf（明文保存参数）
- mysql_config_editor（安全加密保存 login path）
- 环境变量（如 MYSQL_USER/ MYSQL_HOST/ MYSQL_PWD/ MYSQL_DATABASE）
- 自动化脚本硬编码参数或通过变量传递

Q139

English:
You plan to install MySQL Server using RPM download. Which two statements are true?
• A) You must manually initialize the data directory
• B) You can provide root password interactively
• C) RPM supports deploying multiple MySQL versions on same host
• D) MySQL uses RPM relocatable installation target feature
• E) You can find root password in error log after first start
• F) Functionality is split among several RPM package files

Answer: E, F

中文翻译：
计划用 RPM 安装 MySQL Server，以下哪两项正确？
• A）必须手动初始化数据目录
• B）可以交互式设置 root 密码
• C）RPM 支持同主机多版本部署
• D）MySQL 使用 RPM 可重定位安装特性
• E）首次启动后可在错误日志找到 root 密码
• F）功能分布在多个 RPM 包文件中
解析：

A) 必须手动初始化数据目录
- 错误。从 MySQL 5.7+ 起，RPM 包首次启动 mysqld 时会自动初始化数据目录（自动生成临时 root 密码、系统表等），无需手动初始化。
B) 可以交互式设置 root 密码
- 错误。RPM 及主流 MySQL 安装不会在安装过程中弹出命令行交互让你指定 root 密码，而是生成一个临时随机密码。
C) RPM 支持多版本 MySQL 并存
- 错误。标准 MySQL 社区、官方 RPM不支持多版本并存在系统默认目录（/usr/bin,/var/lib/mysql等），因为 rpm 包名及文件位置会冲突。只有用“多实例”或部分特殊安装包（如 MySQL Sandbox、源码或 tar 包）才能多版本共存。
D) MySQL 用 RPM 可重定位特性
- 错误。MySQL 官方 RPM 禁止“--prefix=/new/path”这样的 RPM 安装目录重定位，只能部署到标准目录。
E) 首次启动后可从错误日志中找到 root 密码
- 正确。RPM 安装首次启动，会自动初始化，root 密码会被临时写入 mysql error log，可查找获取。
F) 功能分布在多个 RPM 包中
- 正确。MySQL 官方 RPM 会拆分为 mysql-community-server、mysql-community-client、mysql-community-common、mysql-community-libs 等。安装全功能需安装多个包。

Q140

English:
Examine MySQL Shell command:

dba.rebootClusterFromCompleteOutage()
Which two statements are true?
• A) It reconfigures InnoDB Cluster if cluster was stopped
• B) It performs rolling restart of InnoDB Cluster instances
• C) It only starts all InnoDB Cluster instances
• D) It is not mandatory that all instances are running and reachable before running the command
• E) It stops and restarts all instances and initializes metadata
• F) It only stops and restarts all instances
• G) It picks minimum instances to rebuild quorum and reconfigures cluster

Answer: A, D

中文翻译：
MySQL Shell 命令：

dba.rebootClusterFromCompleteOutage()
以下哪两项正确？
• A）如果集群停止，重新配置 InnoDB 集群
• B）执行实例滚动重启
• C）仅启动所有实例
• D）不要求所有实例运行且可达后才能执行
• E）停止重启所有实例并初始化元数据
• F）仅停止重启所有实例
• G）选最少实例重建仲裁并重新配置

解析：
dba.rebootClusterFromCompleteOutage() 主要用于因全部 InnoDB Cluster 实例宕机的极端灾难恢复场景。该工具会扫描所有实例，选择最完整的一组，恢复法定人数(quorum)，重建通讯、元数据和集群状态。

选项分析

A) Reconfigures InnoDB Cluster if cluster was stopped
- 正确。 主要场景就是突然所有实例都宕机，然后由最完整的成员恢复集群并同步元数据，重建 Group Replication 配置信息。
B) Performs rolling restart
- 错误。 并非滚动重启（不是按顺序一个个重启实例），而是用于所有实例都不能通讯、需要完全集体恢复时用。
C) Only starts all instances
- 错误。 功能不仅仅是“启动所有实例”，更复杂，涉及同步并恢复一致性。
D) Not mandatory that all instances are running/reachable
- 正确。 官方文档明确：不是所有实例都需在线，只要能联系到能“恢复出法定人数(quorum)”的最全数据组即可，其它实例可以之后补加。
E) Stops and restarts all instances and initializes metadata
- 错误。 并不会自动停止实例，更不是 stop/start all，主要是让你指定一组存活的（大多要你自己先启动）然后恢复主配置。
F) Only stops and restarts all instances
- 错误。 功能远不止 stop/start。
G) Picks minimum instances to rebuild quorum and reconfigures cluster
- 错误。

5. 相关知识点总结

dba.rebootClusterFromCompleteOutage() 用于 InnoDB Cluster 所有成员都不可用、全停后人工恢复
- 选择最“新”的成员组成基本集群
- 只需能形成法定人数的最小组，其它成员可稍后加入
- 重建 Group Replication 配置与元数据
不是滚动重启，不需要所有实例都在线，侧重“最优恢复”

https://dev.mysql.com/doc/mysql-shell/8.0/en/reboot-outage.html

重启指南：从主要中断恢复集群

当集群经历全面停机时，可以使用 dba.rebootClusterFromCompleteOutage() 重新配置集群。此操作允许连接到集群的某一个 MySQL 实例，并使用其元数据恢复集群。

什么是完全停机？

完全停机（Complete Outage）意味着组复制在所有成员实例上已经停止。

操作步骤

检查集群成员启动状态：
- 确保所有成员处于在线状态，否则命令将会失败。

连接至最新的实例并运行命令：

JS> var cluster = dba.rebootClusterFromCompleteOutage()

选择主节点：
- 如果所有成员具有相同 GTID 集，当前连接的成员成为主节点。
大纲流程：
- 检索集群元数据和当前实例的拓扑。
- 若某成员处于 RECOVERING 或 ERROR 状态，而其他成员为 OFFLINE 或 ERROR，尝试停止该成员的组复制。
- 检查连接实例中是否包含 GTID 超集合。
- 检测当前可达状态的实例。
选项详解：
- force选项: 允许忽略无法访问的成员或 GTID 集差异来重启。
- dryRun选项: 测试更改而不进行实际应用。
- primary选项: 指定主实例。
- switchCommunicationStack选项: 更改组复制协议。

GTID 超集合

确定具有 GTID 超集合的成员。
使用 SHOW VARIABLES LIKE 'gtid_executed'; 查看哪个实例应用了最大的 GTID 集。

注意事项

可以使用 force 忽略集群成员的可达性或 GTID 集差异。
无法添加或删除前成员作为 dba.rebootClusterFromCompleteOutage() 命令的一部分。
应谨慎使用 dba.dropMetadataSchema() 以防无法恢复。

Force Option 限制

ClusterSet 属无效或主集群状态不是 OK 时，禁止使用 force。
不能添加或重新加入实例如访问不可达。

选择主实例

通过 primary 指定主实例。
采用 force 指定 GTID 集较小的成员作为主节点。

切换通信栈

可以改变组复制协议栈 (mysql 或 xcom) 在重启期间。

此指南涵盖了从完全停机到恢复 MySQL 集群的系统步骤，确保在关键中断情况下能够进行有效恢复和重新配置。

Q141

English:
Which two are features of MySQL Enterprise Firewall? (Choose two.)
• A) Recording incoming SQL statements to facilitate creating a whitelist of permitted commands
• B) Blocking potential threats by configuring pre-approved whitelists
• C) Modifying SQL statements dynamically with substitutions
• D) Automatic locking of user accounts who break your firewall
• E) Provides stateless firewall access to TCP/3306

Answer: A, B

中文翻译：
MySQL 企业防火墙的两个功能是？
• A）记录传入 SQL 语句，方便创建允许命令白名单
• B）通过配置预批准白名单阻止潜在威胁
• C）动态修改 SQL 语句
• D）自动锁定违反防火墙的用户账户
• E）提供无状态防火墙访问 TCP/3306

解析：

• 企业防火墙主要通过记录和白名单策略防护。

Q142

English:
Given this SHOW SLAVE STATUS\G output:

Slave_IO_Running: Yes  
Slave_SQL_Running: Yes  
Seconds_Behind_Master: 1612

Seconds_Behind_Master value is steadily growing.
What are two possible causes? (Choose two.)
• A) Master is too busy transmitting data; slave waits for more data
• B) One or more large tables lack primary keys
• C) Value shows only I/O latency, not transaction queue size
• D) Master produces many events in parallel but slave processes serially
• E) Parallel slave threads experience lock contention

Answer: DE

中文翻译：

SHOW SLAVE STATUS\G 输出显示从库延迟不断增长，可能原因？
• A）主库忙于传输数据，从库等待更多数据
• B）部分大表无主键
• C）该值仅反映 I/O 延迟，不代表事务队列大小
• D）主库并行生成大量事件，从库串行处理
• E）并行线程锁竞争

解析：

D) Master produces many events in parallel but slave processes serially (主库并行产生大量事件，但从库串行处理)

主从复制瓶颈: 这是最常见的导致 Seconds_Behind_Master 增长的原因之一。主库可能拥有多核 CPU 和高性能存储，可以并行地处理大量事务。然而，如果从库的 SQL 线程仍然是单线程（在 MySQL 5.6 之前是默认情况，或在未正确配置并行复制时），它将无法以主库生成事件的速度来应用这些事务。这就导致了从库日志文件（relay log）的堆积，从而使 Seconds_Behind_Master 持续增加。

E) Parallel slave threads experience lock contention (并行从库线程遇到锁竞争)

并行复制的挑战: 即使从库配置了并行复制（MySQL 5.6 及更高版本），如果并行线程在应用事务时频繁地竞争相同的行或表锁，也会导致性能下降。例如，如果多个并行事务修改了相同的数据行，或者在从库上执行了 DDL 操作（如 ALTER TABLE），这些操作会阻塞其他线程，从而导致复制延迟。锁竞争会使部分线程空闲等待，降低整体应用效率。

A) Master is too busy transmitting data; slave waits for more data (主库忙于传输数据；从库等待更多数据)

如果主库忙于传输数据导致从库等待，那么通常会导致 Slave_IO_Running 状态出现问题，或者 Master_Log_File 和 Read_Master_Log_Pos 不会持续更新。然而，Slave_IO_Running: Yes 表明 IO 线程是活动的，并且正在从主库接收事件。Seconds_Behind_Master 持续增长通常与从库应用事件的速度有关，而不是接收事件的速度。

B) One or more large tables lack primary keys (一个或多个大表缺少主键)

缺少主键的大表确实会影响性能，尤其是在 UPDATE 或 DELETE 操作时，因为 MySQL 需要执行全表扫描来定位行。在复制环境中，这会导致从库应用这些特定事务的速度变慢。然而，这通常会导致间歇性的延迟尖峰，而不是持续且稳定增长的 Seconds_Behind_Master。虽然它会加剧问题，但不太可能是导致持续增长的根本原因。

C) Value shows only I/O latency, not transaction queue size (值仅显示 I/O 延迟，而非事务队列大小)

这是对 Seconds_Behind_Master 的误解。Seconds_Behind_Master 实际上衡量的是从库 SQL 线程应用完最后一个事件的时间戳与主库生成该事件的时间戳之间的差值。它反映了从库的 SQL 线程滞后主库的程度，因此它有效地包含了事务队列（relay log 中待应用的事件）的大小对延迟的影响。IO 延迟是其中的一部分，但 Seconds_Behind_Master 更多地反映了整体复制应用滞后。

Q143

English:
You must configure MySQL command-line client for highest trust and security connecting to remote server.
Which --ssl-mode value achieves this?
• A) PREFERRED
• B) VERIFY_CA
• C) REQUIRED
• D) VERIFY_IDENTITY

Answer: D

中文翻译：
MySQL 客户端连接远程服务器时，使用哪个 --ssl-mode 可提供最高安全信任？
• A）PREFERRED
• B）VERIFY_CA
• C）REQUIRED
• D）VERIFY_IDENTITY

解析：

A) PREFERRED
- 最弱安全。支持SSL就用，加密不可用可降为明文。安全性不足
B) VERIFY_CA
- 主动要求 SSL 加密，且验证服务端证书必须为受信 CA 颁发。但不检查服务器名/主机名是否与证书一致，可能被冒充。高安全，但非最高
C) REQUIRED
- 必须加密，但不校验证书有效性。容易中间人攻击，不被信任。安全性较低
D) VERIFY_IDENTITY
- 必须加密、验证服务端证书为受信 CA 颁发，并且服务端主机名（identity）必须与证书一致，防止假冒，最严密的安全与信任。

Q144

English:
Given shell commands:

ps aux | grep mysqld  
kill -15 2076

Which statement about MySQL server shutdown is true?
• A) Avoid kill -15; use mysqladmin shutdown or systemctl stop mysqld
• B) kill -15 and kill -9 are both forced shutdown risking data loss
• C) kill -15 performs normal shutdown like mysqladmin shutdown
• D) mysqld_safe blocks harmful kill commands; kill returns error

Answer: C

中文翻译：
使用 kill -15 终止 mysqld 进程，以下哪项正确？
• A）应避免 kill -15，使用 mysqladmin shutdown 或 systemctl stop
• B）kill -15 和 kill -9 都是强制关闭，有数据风险
• C）kill -15 执行正常关闭，等同 mysqladmin shutdown
• D）mysqld_safe 禁止危险 kill 命令，会报错

解析：

A) 避免 kill -15，应该用 mysqladmin/systemctl
- 不完全正确/非唯一选择。官方推荐使用 mysqladmin/systemctl，但 kill -15（SIGTERM）本质也是“正常关闭”而非危险操作。使用 kill -15 不会突然杀死 mysqld，只会触发正常的关闭流程。
B) kill -15 和 kill -9 都是强制关闭，有丢失风险
- 错误。kill -9 (SIGKILL) 是强制不安全关闭，kill -15 (SIGTERM) 是优雅关闭，服务器会安全写盘等并正常退出，不会导致数据丢失。
C) kill -15 正常关闭，与 mysqladmin shutdown 类似
- 正确。kill -15 (SIGTERM) 触发 mysqld 的优雅关闭（graceful shutdown）流程，和调用 mysqladmin shutdown 或 systemctl stop mysqld 本质执行同一关机机制。
D) mysqld_safe 阻止 kill，kill 会报错
- 错误。mysqld_safe 不会阻止 kill -15，其职责是自动重启和日志管理，kill 目标进程权限正确即可正常生效。

Q145

English:
Binary log events for schema mydb1 must be copied to a different schema name mydb2.
Which command will do this?
• A) mysqlbinlog --rewrite-db='mydb1->mydb2' | mysql
• B) mysqlbinlog --database=mydb1 --database=mydb2 | mysql
• C) mysqlbinlog --rewrite-db='mydb1' --rewrite-db='mydb2' | mysql
• D) mysqlbinlog --read-from=remote-server --raw | sed 's/mydb1/mydb2/g' | mysql

Answer: A

中文翻译：

将 mydb1 的二进制日志事件复制到 mydb2，使用哪个命令？
• A）mysqlbinlog --rewrite-db='mydb1->mydb2' | mysql
• B）mysqlbinlog --database=mydb1 --database=mydb2 | mysql
• C）mysqlbinlog --rewrite-db='mydb1' --rewrite-db='mydb2' | mysql
• D）mysqlbinlog --read-from=remote-server --raw | sed 's/mydb1/mydb2/g' | mysql

解析：

A) mysqlbinlog --rewrite-db='mydb1->mydb2' | mysql
- 正确。
  - --rewrite-db='mydb1->mydb2' 会在解析二进制日志时，把所有 mydb1 下的操作动态改名到 mydb2，直接导入即可完成切换。
B) --database=mydb1 --database=mydb2
- 错误。
  - 这样只会读取属于 mydb1 和 mydb2 的事件，并不会做重命名/mapping转换。
C) --rewrite-db='mydb1' --rewrite-db='mydb2'
- 错误。
  - 没有转化语义，仅作为参数重复指定，且语法不支持，只有箭头式（from->to）才生效。
D) ... | sed 's/mydb1/mydb2/g' | ...
- 错误。
  - 用 sed 直接替换不安全，会误改字段名、内容等，而不是严格只改数据库名。

Q146

English:
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;

Answer: A

中文翻译：
启用基于规则的 MySQL 审计功能，使用哪个命令？
• A）执行 mysql < audit_log_filter_linux_install.sql 脚本
• B）mysqld --initialize --log-raw=audit.log
• C）INSTALL PLUGIN audit_log;
• D）INSTALL COMPONENT audit_log;

https://dev.mysql.com/doc/refman/8.0/en/audit-log-installation.html

Q147

English:
Examine this SQL statement:

GRANT r_read@localhost TO mark WITH ADMIN OPTION;

Which two are true? (Choose two.)
• A) Mark can grant privileges assigned to role r_read@localhost to another user.
• B) ADMIN OPTION causes the role to be activated by default.
• C) Mark can grant the r_read@localhost role to another user.
• D) Mark can revoke the r_read@localhost role from another role.
• E) ADMIN OPTION allows Mark to drop the role.
• F) Mark must connect from localhost to activate the r_read@localhost role.

Answer: C, D

中文翻译：
分析 SQL 语句：

GRANT r_read@localhost TO mark WITH ADMIN OPTION;
以下哪两项正确？
• A）Mark 可以将 r_read@localhost 角色赋予其他用户的权限
• B）ADMIN OPTION 会默认激活该角色
• C）Mark 可以将 r_read@localhost 角色授权给其他用户
• D）Mark 可以从其他角色撤销 r_read@localhost 角色
• E）ADMIN OPTION 允许 Mark 删除该角色
• F）Mark 必须从 localhost 连接才能激活该角色
解析：
相关语句表示将名为 r_read@localhost 的角色分配给用户 mark，并带有 ADMIN OPTION 权限。

选项分析

A) Mark 可以把 r_read@localhost 角色里的权限授予其他用户。
- 错误。
  - ADMIN OPTION 只允许 Mark 授予/撤销角色本身，而不是直接拆分角色内的具体权限去赋给别人。
B) ADMIN OPTION 导致角色默认激活。
- 错误。
  - 角色的默认激活需用 DEFAULT ROLE 指定，与 ADMIN OPTION 无直接关系。
C) Mark 可以将 r_read@localhost 这个角色授予其他用户。
- 正确。
  - ADMIN OPTION 允许 Mark 将 r_read@localhost 角色赋给其他用户（或撤销）。
D) Mark 可以把 r_read@localhost 这个角色从其他角色上撤销。
- 正确。
  - ADMIN OPTION 允许 Mark 赋予或者撤销该角色对其他用户或角色，不止赋予，还能撤销。
E) ADMIN OPTION 允许 Mark 删除角色。
- 错误。
  - 删除角色（DROP ROLE）需要该角色本身的 CREATE/ADMIN 权限或超级权限，不在 ADMIN OPTION 范围内。
F) Mark 必须从 localhost 连接才能激活该角色。
- 错误。
  - 授予角色时角色名是 r_read@localhost，但只要 Mark 被授予此角色，无论从哪里连入，只要有该角色就可 SET ROLE 激活，与客户端 host 无关。

Q148

English:
Which four are types of information stored in the MySQL data dictionary? (Choose four.)
• A) Performance metrics
• B) Table definitions
• C) Access control lists
• D) View definitions
• E) Server runtime configuration
• F) Server configuration rollback
• G) Stored procedure definitions
• H) InnoDB buffer pool LRU management data

Answer: B, C, D, G

中文翻译：
MySQL 数据字典存储哪四类信息？
• A）性能指标
• B）表定义
• C）访问控制列表
• D）视图定义
• E）服务器运行时配置
• F）服务器配置回滚
• G）存储过程定义
• H）InnoDB 缓冲池 LRU 管理数据

解析：
• 数据字典包含表、访问控制、视图和存储过程定义。

MySQL 8.0 Data Dictionary 介绍

1. 概述

MySQL 8.0 起对“数据字典（Data Dictionary）”进行了革命性重构，放弃了之前的“FRM 文件 + 各独立 storage engine 元信息”模式，转向统一的、事务型的数据字典（Data Dictionary, DD），极大提升了一致性、拓展性与管理便捷性。

2. 核心特性

集中化管理
所有库表、字段、索引、视图、存储过程、触发器、用户、权限等元数据统一存储在专用的 data dictionary 表（mysql 库下，部分 ibd 文件）中，由 InnoDB 储存及维护。
事务支持
Data Dictionary 信息完全由 InnoDB 引擎管理，所有元数据变更也拥有ACID 特性（事务隔离、一致性、崩溃恢复）。元数据“和数据本身一样安全可靠”。
文件结构简化
拥有统一数据字典后，数据表不再需要 .frm 等结构文件，实现物理文件精简。
- 常见文件：
  - .ibd：表及索引数据（独立表空间）
  - .sdi：元数据冗余备份（Serialized Dictionary Information，部分对象）
性能与一致性提升
- 元数据锁冲突减少
- 查询元信息不需要额外读取各独立文件，提升性能
- 在崩溃恢复等场景，库表对象与元数据始终一致
自省查询简易
重要元信息通过 INFORMATION_SCHEMA、PERFORMANCE_SCHEMA 及 mysql 系统库的数据字典表直接查询，便于自动化管理和监控。

3. Data Dictionary 相关表举例

所有数据字典表均以 mysql. 开头并存储于 InnoDB，常见如：

表名	作用说明
mysql.tables	所有表的元数据
mysql.columns	表的列结构信息
mysql.indexes	索引定义
mysql.tablespaces	表空间定义
mysql.view_table_usage	视图依赖
mysql.triggers	触发器定义
mysql.events	事件调度定义
mysql.routines	存储过程定义

部分表内容可通过视图（INFORMATION_SCHEMA/SHOW语句）访问。

4. 与旧版本的区别

MySQL 5.7 及以前每个表靠 .frm 文件存结构定义，.par/.trg/.TRN/.TRG 等辅助元文件，容易损坏且信息分散。
MySQL 8.0 所有表的元数据集中存储于 InnoDB 数据字典表，易于管控、备份、恢复，避免“表丢失元数据但数据还在”问题。

5. 管理和运维注意

大多数元数据变更如 DROP/RENAME/ALTER 等操作的可靠性大幅提升
升级到 8.0 时会自动将原有 .frm 信息迁移进集中数据字典
基于文件的手工修复不再适用，运维需基于 SQL/官方工具操作

Q149

English:
You have an InnoDB Cluster with three servers.
Running this command succeeds:

mysqldump -uroot -p -d mydatabase > mydatabase_backup.sql
After data loss, cluster initialization and restore attempt fail with error:

ERROR 13176(HY000) at line 23: Cannot update GTID_PURGED with the Group Replication plugin running

Which two actions can fix this and allow successful restore? (Choose two.)
• A) Stop all instances except primary read/write master and run restore.
• B) Remove @@GLOBAL.gtid_purged statement from dump file.
• C) Create backup with --set-gtid-purged=OFF option.
• D) Remove group replication plugin before restoring.
• E) Remove @@GLOBAL.gtid_executed statement from dump file.
• F) Restore using --set-gtid-purged=OFF option.

Answer: B, C

中文翻译：
InnoDB 集群三节点，执行命令成功导出结构。数据丢失后恢复时报错：

ERROR 13176(HY000) at line 23: Cannot update GTID_PURGED with Group Replication plugin running

以下哪两项操作能解决该问题？
• A）停止除主节点外所有实例后恢复
• B）删除转储文件中 @@GLOBAL.gtid_purged 语句
• C）备份时使用 --set-gtid-purged=OFF
• D）恢复前移除组复制插件
• E）删除转储文件中 @@GLOBAL.gtid_executed 语句
• F）恢复时使用 --set-gtid-purged=OFF

解析：

A) 除主节点外停掉其它所有节点再恢复
- 错误。 即使只剩一个节点，只要 group replication 插件开启，GTID_PURGED 仍不可设置。
B) 删除 dump 文件中的 @@GLOBAL.gtid_purged 语句
- 正确。 这样 restore 时不会尝试更改 GTID_PURGED，也就不会触发该报错。
C) 用 --set-gtid-purged=OFF 选项重新备份
- 正确。 如此 mysqldump 文件里就不会包含 SET @@GLOBAL.gtid_purged，避免该错误。
D) 恢复前移除 group replication 插件
- 可行，但不推荐。安全性/一致性受影响，且操作繁琐，实际 Restore 通常不会建议直接卸载插件。
E) 删除 @@GLOBAL.gtid_executed 语句
- 错误。 dump 文件没有此语句且与恢复无关。
F) 恢复时用 --set-gtid-purged=OFF 选项
- 错误。 这个选项只在 mysqldump 导出备份时生效，restore 时无效。

Q150

English:
Which statement is true about MySQL Enterprise Transparent Data Encryption (TDE)?
• A) Uses appropriate keyring plugin to store keys centrally.
• B) Both MyISAM and InnoDB can be encrypted by setting keyring_engine=ALL.
• C) Lost tablespace keys can only be regenerated if master key is known or in Key Vault.
• D) TDE encrypts InnoDB and MyISAM only when tables are in SYSTEM tablespace.

Answer: A

中文翻译：
关于 MySQL 企业透明数据加密（TDE），哪项正确？
• A）使用合适的 keyring 插件集中存储密钥
• B）MyISAM 和 InnoDB 都可通过设置 keyring_engine=ALL 加密
• C）丢失表空间密钥只能通过主密钥或密钥库恢复
• D）仅系统表空间中的表可被 TDE 加密
解析：

A) 使用合适的 keyring 插件集中存储加密密钥。
- 正确。
  - TDE 的秘钥全部通过 keyring 插件（比如 keyring_file、keyring_encrypted_file、keyring_okv 等）实现集中存储和管理，安全合规。实际应用部署中推荐使用企业版的 keyring_okv（Oracle Key Vault）等中心化方案。
B) 设置 keyring_engine=ALL 即可同时加密 MyISAM 和 InnoDB。
- 错误。
  - MyISAM 并不支持表级别 TDE 加密，TDE 仅支持 InnoDB 表空间。MyISAM 只支持在某些社区补丁或功能废弃。
C) 丢失表空间密钥时，仅在已知主密钥或主密钥在 Key Vault 情况下能重建。
- 错误。
  - 如果主密钥丢失且不在 Key Vault，则无法恢复所有表空间密钥和数据，这本质是密钥管理基础原则；但这并非 MySQL TDE 专属陈述，略显泛泛。
D) 只有表在 SYSTEM 表空间时才能加密 InnoDB 和 MyISAM。
- 错误。
  - TDE 主要面向 InnoDB 的独立表空间和通用表空间，无论是在系统表空间还是独立表空间都可加密，且 MyISAM 不受支持。

Q151

English:
You want to store username and password for MySQL client connection in a local file.
What is the best way to encrypt the file?
• A) Use AES_ENCRYPT() MySQL function on option file
• B) Use mysql_secure_installation to encrypt stored login credentials
• C) Use text editor to create defaults file and encrypt from Linux prompt
• D) Use mysql_config_editor to create an encrypted file

Answer: D

中文翻译：
你希望将 MySQL 客户端连接的用户名和密码存储在本地文件中。最佳加密方式是？
• A）用 AES_ENCRYPT() 加密选项文件
• B）用 mysql_secure_installation 加密登录信息
• C）用文本编辑器创建默认文件并用 Linux 命令加密
• D）用 mysql_config_editor 创建加密文件
解析：

A) 用 AES_ENCRYPT() 加密 option 文件
- 错误。
  - AES_ENCRYPT() 仅用于表内字段数据，不能自动被客户端识别和解密 option 文件。
B) 用 mysql_secure_installation 加密登录信息
- 错误。
  - 该工具用于初始化 MySQL 安全（如 root 密码、匿名用户等），不能用于加密本地登录文件。
C) 编辑 option 文件后用 Linux 命令加密
- 不推荐。
  - 普通加密无法被 MySQL 客户端自动读取和解密，不便于自动化调用，缺乏合规集成。
D) 用 mysql_config_editor 创建加密文件
- 正确。
  - mysql_config_editor 专门用于维护加密的登录凭证（login path），加密后自动供 mysql 客户端等识别，兼顾安全与便捷，推荐企业和安全场景使用。

Q152

English:
You are backing up raw InnoDB files using mysqlbackup.
Which two groups of files are backed up during a full backup? (Choose two.)
• A) ibbackup files
• B) *.CSM files
• C) *.sdi files
• D) .ibd files
• E) ib_logfile files

Answer: D, E

中文翻译：
使用 mysqlbackup 备份原始 InnoDB 文件，完整备份包含哪两类文件？
• A）ibbackup 文件
• B）.CSM 文件
• C）.sdi 文件
• D）.ibd 文件
• E）ib_logfile 文件

解析：
InnoDB 相关备份文件包括：ibdata（系统表空间及部分用户表数据）、.ibd（使用 file-per-table 的用户表数据）、以及 ib_logfile（备份期间的重做日志信息，存入备份文件 ibbackup_logfile）。

Q153

English:
Examine this statement and output:

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(...) ...	381268	31.44 ms	1.01 ms
2	SELECT ... WHERE created < ?	150317	358.34 us	30.06 s
3	SELECT ... + INTERVAL ...	600	523.32 ms	120.24 ms
4	SELECT ... BETWEEN ? AND ?	200	10.32 s	40.19 ms
5	SELECT ... WHERE val = ?	1	21.03 s	274.00 us

You must try to reduce query execution time.
Which two queries should you focus on? (Choose two.)
• A) QN=3
• B) QN=5
• C) QN=1
• D) QN=4
• E) QN=2

Answer: B, D

中文翻译：

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(...) ...	381268	31.44 ms	1.01 ms
2	SELECT ... WHERE created < ?	150317	358.34 us	30.06 s
3	SELECT ... + INTERVAL ...	600	523.32 ms	120.24 ms
4	SELECT ... BETWEEN ? AND ?	200	10.32 s	40.19 ms
5	SELECT ... WHERE val = ?	1	21.03 s	274.00 us

分析 SQL 及输出，需降低查询执行时间，重点关注哪两个查询？
• A）QN=3
• B）QN=5
• C）QN=1
• D）QN=4
• E）QN=2
解析：
看avg_latency，执行次数多的sql 语句已经没有优化的空间了

Q154

English:
You plan daily full backups including ndbinfo and sys databases.
Which command backs up databases in parallel?
• A) mysqldump --single-transaction > 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 --all-databases > full-backup-$(date +%Y%m%d).sql

Answer: B

中文翻译：
计划每日全备份，包含 ndbinfo 和 sys 库，哪个命令支持并行备份？
• A）mysqldump 单事务备份
• B）mysqlpump 包含所有数据库备份
• C）mysqlpump 全库备份
• D）mysqldump 全库备份
解析：
• mysqlpump 支持并行备份，提升效率。

Q155

English:
Which two commands display indexes on the parts table in manufacturing schema? (Choose two.)
• A) DESCRIBE manufacturing.parts;
• B) SELECT * FROM information_schema.statistics WHERE table_schema='manufacturing' AND table_name='parts';
• C) SHOW INDEXES FROM manufacturing.parts;
• D) SELECT * FROM information_schema.COLUMN_STATISTICS;
• E) EXPLAIN SELECT INDEXES FROM manufacturing.parts;

Answer: B, C

中文翻译：
显示 manufacturing.parts 表索引的两个命令？
• A）DESCRIBE 命令
• B）查询 information_schema.statistics
• C）SHOW INDEXES 命令
• D）查询 information_schema.COLUMN_STATISTICS
• E）EXPLAIN 查询

解析：

A) DESCRIBE manufacturing.parts;
解释：该命令只显示表的字段定义、数据类型、是否为主键等，并不展示全部索引信息。
B) SELECT * FROM information_schema.statistics WHERE table_schema='manufacturing' AND table_name='parts';
解释：这是标准SQL方式，直接从MySQL索引统计信息表查询，能全面显示该表索引详细结构。（正确答案）
C) SHOW INDEXES FROM manufacturing.parts;
解释：这是MySQL内置命令，用于展示指定表的所有索引（包括主键、唯一索引、普通索引等）信息。（正确答案）
D) SELECT * FROM information_schema.COLUMN_STATISTICS;
解释：该表主要提供各列的统计信息（如直方图/分布等），不是用于显示索引结构。
E) EXPLAIN SELECT INDEXES FROM manufacturing.parts;
解释：语法错误，EXPLAIN主要用于分析SELECT、INSERT等语句的执行计划，不能直接用于显示索引。

5.相关知识点总结

查看MySQL表的索引结构，可通过SHOW INDEXES FROM <db>.<table>命令快速显示，或通过查询information_schema.statistics系统表来获得详细索引信息，两者实际结果类似。
DESCRIBE和EXPLAIN各有特定用途，不能直接用于查看表的全部索引列表。
熟悉information_schema相关表的作用是数据库开发和性能优化的基础操作。

Q156

English:
Pre-production testing shows client programs incompatible with MySQL 8.0 staging upgrade. You decide to downgrade to MySQL 5.7.
Which two methods achieve this?
• A) Reinstall 5.7 binaries; run 5.7 mysql_upgrade with --force
• B) Reinstall 5.7 binaries and reinitialize --datadir; restore 5.7 physical backup taken before upgrade
• C) Reinstall 5.7 binaries and reinitialize --datadir; restore physical backup of 8.0 tables
• D) Reinstall 5.7 binaries and reinitialize --datadir; restore logical backup of 8.0 non-system tables and recreate users with CREATE USER and GRANT
• E) Reinstall 5.7 binaries; execute mysqlcheck --repair

Answer: B, D

中文翻译：

预发布测试发现客户端与 MySQL 8.0 不兼容，决定降级到 5.7，哪两种方法可实现？
• A）重装 5.7，执行 mysql_upgrade --force
• B）重装 5.7，重建数据目录，恢复升级前 5.7 物理备份
• C）重装 5.7，重建数据目录，恢复 8.0 物理备份
• D）重装 5.7，重建数据目录，恢复 8.0 逻辑备份并重建用户
• E）重装 5.7，执行 mysqlcheck --repair

解析：

A) 只装5.7并执行mysql_upgrade --force：
错误。mysql_upgrade 仅用于升级，不适用于降级。降级不能简单地强制让低版本识别高版本的数据目录。
B) 安装5.7并恢复5.7升级前物理备份：
正确。只有用5.7的数据物理备份恢复，才可保证数据结构与版本兼容。这是官方建议的降级方式。（正确答案）
C) 安装5.7并恢复8.0表的物理备份：
错误。8.0的数据文件可能与5.7的存储格式冲突，无法直接回滚或兼容。
D) 安装5.7并恢复8.0逻辑备份（非系统表），用户手动重建：
正确。通过mysqldump等逻辑备份工具导出8.0的业务表（非系统表），然后用5.7导入，仅需重建账户等信息。这是官方推荐的非物理降级方法。（正确答案）
E) 只装5.7后用mysqlcheck修复：
错误。该命令只能修复表损坏，对主版本降级后数据目录格式不兼容无效。

Q157

English:
Which two are use cases of MySQL asynchronous replication? (Choose two.)
• A) You can scale writes by creating a replicated mesh.
• B) It guarantees near real-time replication between master and slave.
• C) You can scale reads by adding multiple slaves.
• D) MySQL Enterprise Backup can automatically back up from an available slave.
• E) It allows backup on slave without impacting master.

Answer: C, E

中文翻译：
MySQL 异步复制的两个用例？
• A）通过复制网格扩展写入
• B）保证主从近实时复制
• C）通过添加多个从库扩展读取
• D）企业备份可自动从从库备份
• E）允许从库备份不影响主库

解析：

A) 你可以通过创建复制网状结构来扩展写操作。
错误。MySQL异步复制不能扩展写能力，只能扩展读。写操作依然只允许主库，不能多主并行写。
B) 它保证主从之间接近实时的复制。
错误。异步复制无法保证实时，有延迟和落后风险。
C) 你可以通过增加多个从库来扩展读操作。
正确。典型应用就是通过添加多个slave来实现读扩展（分流查询压力）。（正确答案）
D) MySQL Enterprise Backup可以自动从可用的从库进行备份。
与异步复制没有必然直接关系，更多是备份工具自身特性。
E) 它允许在从库上做备份而不影响主库。
正确。可以用slave承担备份任务，避免主库负载，提升高可用性和备份性能。（正确答案）

Q158

English:
Examine this EXPLAIN statement and output:

EXPLAIN
SELECT country.Code, country.name,
       city.name, city.district
FROM country
INNER JOIN city ON city.CountryCode = country.Code
WHERE country.Population > 100000000;

Output excerpt:

id	select_type	table	type	possible_keys	key	          key_len	ref	               rows	filtered	Extra
1	SIMPLE	    country	ALL	    PRIMARY	        NULL	      NULL	    NULL	           239	33.33	    Using where
1	SIMPLE	    city	ref	    CountryCode	    CountryCode	  3	        world.country.Code 18	100	        NULL

Which two are true?
A) The plan contains a full table scan of the city table.
B) There is a problem with the statement reported as a warning.
C) The output suggests adding an index on the countrycode column.
D) 33.33% of rows in the country table will be accessed.
E) The plan contains a full table scan of the country table.
F) It is estimated that 33.33% of rows in the country table match the WHERE clause.

Answer: E，F

中文翻译：
分析 EXPLAIN 输出，以下哪两项正确？
A）执行计划包含 city 表的全表扫描。
B）语句有警告提示存在问题。
C）输出建议为 countrycode 列添加索引。
D）预计访问 country 表中 33.33% 的行。
E）执行计划包含 country 表的全表扫描。
F）预计有 33.33% 的 country 表行匹配 WHERE 条件。

解析：

A) 对city表全表扫描。
- 错误。city的type是ref，表示使用了索引，不是ALL（全表扫描）。
B) 语句有warning问题。
- 错误，没有warning。
C) 输出建议对countrycode列加索引。
- 错误。city表的CountryCode已经被索引（type为ref，key为CountryCode），此列已建有索引。
D) country表将访问33.33%的记录。
- 正确。filtered为33.33，表示预计有33.33%的rows能通过WHERE过滤条件,但是不一定被访问，还有inner join操作。
E) 对country表全表扫描。
- 正确。country表的type为ALL，表示全表扫描。（正确答案）
F) 估计country表有33.33%记录匹配WHERE。
- 正确。filtered字段正是指符合WHERE条件的预估比例。（正确答案）
Extra 信息通常在 EXPLAIN 的输出结果的最后一行显示，可能会显示以下信息：
Using index:表示该查询使用了索引。这说明优化器在查询时使用了索引来加速数据检索，从而提高了查询性能。
Using where:表示该查询使用了WHERE 子句，并根据WHERE 条件进行过滤。
Using temporary:表示该查询创建了一个临时表来完成查询。这通常发生在查询需要分组、排序或进行一些聚合操作时。
Using filesort:表示该查询需要进行文件排序来对结果进行排序。
Using join buffer:表示该查询使用了连接缓冲区，优化器使用连接缓冲区来提高连接操作的效率。
Using sort key:表示查询使用了排序键。
Not enough information for a merge:表示优化器无法对结果进行合并。
Found 1 matching rows:表示找到了一个匹配的行。
Warning:表示一些潜在的警告信息，例如警告优化器可能会因为缺少索引而导致性能问题。

Q159

English:
Which step or set of steps can be used to rotate the error log?
• A) Execute SET GLOBAL log_error = ''.
• B) Execute SET GLOBAL max_error_count = to rotate.
• C) Execute SET GLOBAL expire_logs_days=0 to enforce rotation.
• D) Rename the error log file on disk, then execute FLUSH ERROR LOGS.

Answer: D

中文翻译：哪个步骤或哪些步骤可以用来轮换错误日志？ • A) 执行 SET GLOBAL log_error = '<新的错误日志文件>'。 • B) 执行 SET GLOBAL max_error_count = <数字> 来进行轮换。 • C) 执行 SET GLOBAL expire_logs_days=0 来强制轮换。 • D) 在磁盘上重命名错误日志文件，然后执行 FLUSH ERROR LOGS。

答案： D

解析：
错误日志的轮换通常不能通过简单地设置全局变量来完成。正确的做法是先在文件系统中重命名当前的错误日志文件（相当于“归档”旧日志），然后通过执行 FLUSH ERROR LOGS 命令让 MySQL 创建一个新的错误日志文件并开始记录。选项 A、B、C 都不符合此操作流程，因此正确答案是 D。

Q160

English:
A valid raw backup of the shop.customers MyISAM table was taken. You must restore the table.
Steps started:
Confirm 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? (Choose two.)
• A) cp /backup/customers.sdi /var/tmp
• B) cp /backup/customers.sdi /var/lib/mysql/shop/
• C) mysql> SOURCE '/var/tmp/customers.sdi'
• D) mysql> IMPORT TABLE FROM /var/tmp/customers.sdi
• E) cp /backup/customers.frm /var/lib/mysql/shop/
• F) mysql> IMPORT TABLE FROM /var/lib/mysql/shop/customers.sdi
• G) mysql> ALTER TABLE shop.customers IMPORT TABLESPACE
• H) mysql> ALTER TABLE shop.customers DISCARD TABLESPACE

Answer: A, D

中文翻译：

对 shop.customers MyISAM 表进行了有效的原始备份。你必须恢复该表。
已开始的步骤：
确认 secure_file_priv='/var/tmp'
mysql> DROP TABLE shop.customers;
Shell: cp /backup/customers.MY* /var/lib/mysql/shop/
完成恢复还需要哪两步？（选择两项）
• A) cp /backup/customers.sdi /var/tmp
• B) cp /backup/customers.sdi /var/lib/mysql/shop/
• C) mysql> SOURCE '/var/tmp/customers.sdi'
• D) mysql> IMPORT TABLE FROM /var/tmp/customers.sdi
• E) cp /backup/customers.frm /var/lib/mysql/shop/
• F) mysql> IMPORT TABLE FROM /var/lib/mysql/shop/customers.sdi
• G) mysql> ALTER TABLE shop.customers IMPORT TABLESPACE
• H) mysql> ALTER TABLE shop.customers DISCARD TABLESPACE

解析：
恢复 MyISAM 表的步骤中，除了复制数据文件（.MY* 文件）到数据目录外，还必须处理表定义信息的导入。.sdi 文件包含表的元数据信息。由于 secure_file_priv 限制了文件导入的目录，必须将 .sdi 文件复制到该目录（这里是 /var/tmp），然后使用 IMPORT TABLE FROM 命令从该目录导入表定义。选项 A 和 D 是正确的步骤。其他选项要么路径错误，要么命令不存在。

Q161

English:
Examine this successful command:

cluster.addInstance('<user>@<host>:<port>', { recoveryMethod: 'clone' })
Which three statements are true? (Choose three.)
• A) The account used needs BACKUP_ADMIN privilege.
• B) Target instance must exist; it will be provisioned with data from an existing cluster instance and joined.
• C) InnoDB tablespaces outside datadir can be cloned.
• D) It is always slower than { recoveryMethod: 'incremental' }.
• E) A new instance is installed, initialized, provisioned, and joined to the cluster.
• F) InnoDB redo logs must not rotate during execution or recovery fails.

Answer: A, B, C

中文翻译：
查看这条成功的命令：

cluster.addInstance('<user>@<host>:<port>', { recoveryMethod: 'clone' })
以下哪三项陈述是正确的？（选择三项）
• A) 使用的账户需要 BACKUP_ADMIN 权限。
• B) 目标实例必须已存在；它将从现有集群实例中获取数据并加入集群。
• C) 可以克隆数据目录外的 InnoDB 表空间。
• D) 它总是比 { recoveryMethod: 'incremental' } 慢。
• E) 新实例被安装、初始化、预配并加入集群。
• F) 执行期间 InnoDB 重做日志不能轮换，否则恢复失败。

解析：
cluster.addInstance 使用克隆（clone）方式恢复实例时，必须用具有 BACKUP_ADMIN 权限的账户执行。目标实例必须已经存在，命令会将其初始化为克隆状态并加入集群。克隆支持克隆数据目录外的 InnoDB 表空间。选项 D 错误，克隆并不总是比增量恢复慢。选项 E 错误，克隆方式是在已有实例上操作，不是新安装。选项 F 不适用，因为克隆过程本身不要求重做日志不能轮换。

Q163

English:
In an OLTP system with high concurrent INSERTS and UPDATES, MySQL server performance degrades with more users. What do you recommend?
• A) Decrease innodb_lock_wait_timeout.
• B) Enable innodb_api_disable_rowlock.
• C) Set innodb_autoinc_lock_mode to 1.
• D) Disable innodb_rollback_on_timeout.

Answer: C

中文翻译：
在一个高并发插入（INSERT）和更新（UPDATE）的 OLTP 系统中，随着用户数增加，MySQL 服务器性能下降。你推荐什么做法？
• A) 减小 innodb_lock_wait_timeout。
• B) 启用 innodb_api_disable_rowlock。
• C) 将 innodb_autoinc_lock_mode 设置为 1。
• D) 禁用 innodb_rollback_on_timeout。

解析：
在高并发插入和更新环境中，InnoDB 的自增锁（auto-increment lock）可能成为性能瓶颈。将 innodb_autoinc_lock_mode 设置为 1（“连续模式”）可以减少自增锁的竞争，提高并发性能。其他选项如减小锁等待时间或禁用回滚超时不会直接改善高并发性能，启用 innodb_api_disable_rowlock 反而会禁用行锁，导致性能下降。

innodb_autoinc_lock_mode 参数解析

功能简介

该系统变量 innodb_autoinc_lock_mode 用于控制 InnoDB 表生成自增（auto-increment）值时所采取的锁机制。支持的取值有 0（traditional/传统）、1（consecutive/连续）、2（interleaved/交错）。

默认值：MySQL 8.0 及以后为 2（interleaved），MySQL 5.7 以前为 1（consecutive）。

结构化分段说明

1. 参数属性

命令行格式：--innodb-autoinc-lock-mode=#
变量名：innodb_autoinc_lock_mode
作用范围：全局（Global）
是否可动态修改：否（Dynamic: No）
类型：整数
默认值：2
合法值：0, 1, 2

2. 锁模式说明

值	锁模式（英文）	中文解释	适用场景
0	traditional	传统模式	老版本应用，要求严格自增顺序或最大兼容性
1	consecutive	连续模式	需要保证语句执行顺序与自增值顺序一致
2	interleaved	交错模式（默认，推荐）	高并发场景，提升性能

模式 0（传统）
- 最严格的模式，整个表在插入期间加上 AUTO_INCREMENT 锁。并发性最低。
模式 1（连续）
- 对于包含多行的批量插入，这些插入操作共享自增锁，适合 statement-based replication（语句级复制）。
模式 2（交错，默认）
- 仅当必要时短暂加锁，最大化并发插入性能。适合 row-based replication（行级复制）。

3. 设计背景

MySQL 8.0 默认设置变为交错模式（2），因为此版本默认复制类型也从 statement-based 改为 row-based。
statement-based replication（基于语句复制）要求 predictable（可预测）且 repeatable（可重复）的自增分配方式，所以对应需要更严格的锁（如 consecutive）。
row-based replication（基于行复制）不敏感于 SQL 的执行顺序，所以可以采用性能最佳的 interleaved 模式。

4. 相关知识点总结

interleaved 有助于高并发高性能，但自增值不一定连续。
若业务依赖自增 ID 顺序，请根据实际需求考虑调整该参数。
详细特性与行为建议查看官方文档：InnoDB AUTO_INCREMENT Lock Modes

Q164

English:

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   1200 Aug 20 13:58 ca.pem
-rw-r-----  1 mysql mysql 172040 Aug 22 14:07 ib_buffer_pool
-rw-r-----  1 mysql mysql 209296 Aug 22 14:07 ibdata1
-rw-r-----  1 mysql mysql 50331648 Aug 22 14:07 ib_logfile0
-rw-r-----  1 mysql mysql 50331648 Aug 22 13:47 ib_logfile1
-rw-r-----  1 mysql mysql 522292 Aug 22 14:07 ibtmp1
drwxr-xr-x  1 mysql users   4096 Aug 20 13:59 mysql
-rw-r-----  1 mysql mysql  64064 Aug 20 13:59 mysql-error.log
drwxr-xr-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:58 public_key.pem
-rw-r--r--  1 mysql mysql   1112 Aug 20 13:58 server-cert.pem
-rw-------  1 mysql mysql   1680 Aug 20 13:58 server-key.pem
drwxr-x---  1 mysql mysql   4096 Aug 20 13:59 sys

Examine the output of ls -al /var/lib/mysql showing file and directory permissions.
Which two options will improve the security of the MySQL instance? (Choose two.)
• A) Remove group read/write privileges from the private_key.pem file.
• B) Remove world read privileges from the server-cert.pem certificate file.
• C) Change the group ownership of the mysql directory to the mysql user group.
• D) Remove world read privileges from the public_key.pem file.
• E) Change the parent directory owner and group to mysql.
• F) Remove the world read/execute privilege from the accounting directory.

Answer: A, F

中文翻译：

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   1200 Aug 20 13:58 ca.pem
-rw-r-----  1 mysql mysql 172040 Aug 22 14:07 ib_buffer_pool
-rw-r-----  1 mysql mysql 209296 Aug 22 14:07 ibdata1
-rw-r-----  1 mysql mysql 50331648 Aug 22 14:07 ib_logfile0
-rw-r-----  1 mysql mysql 50331648 Aug 22 13:47 ib_logfile1
-rw-r-----  1 mysql mysql 522292 Aug 22 14:07 ibtmp1
drwxr-xr-x  1 mysql users   4096 Aug 20 13:59 mysql
-rw-r-----  1 mysql mysql  64064 Aug 20 13:59 mysql-error.log
drwxr-xr-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:58 public_key.pem
-rw-r--r--  1 mysql mysql   1112 Aug 20 13:58 server-cert.pem
-rw-------  1 mysql mysql   1680 Aug 20 13:58 server-key.pem
drwxr-x---  1 mysql mysql   4096 Aug 20 13:59 sys

查看 ls -al /var/lib/mysql 的文件和目录权限输出。
哪两项选项可以提升 MySQL 实例的安全性？（选择两项）
• A) 移除 private_key.pem 文件的组读写权限。
• B) 移除 server-cert.pem 证书文件的全局读取权限。
• C) 将 mysql 目录的组所有权改为 mysql 用户组。
• D) 移除 public_key.pem 文件的全局读取权限。
• E) 将父目录的所有者和组改为 mysql。
• F) 移除 accounting 目录的全局读/执行权限。

答案： A, F

解析：
私钥文件（private_key.pem）应有严格的权限限制，移除组的读写权限能防止非授权用户访问。去掉目录（如 accounting）对所有用户的读和执行权限，也能防止未授权访问。其他选项如修改组所有权或去掉证书文件的权限虽然有一定作用，但不如 A 和 F 直接有效。

Q165

English:
A MySQL server is monitored using MySQL Enterprise Monitor's agentless installation.
Which three features are available with this method? (Choose three.)
• A) MySQL Replication monitoring
• B) Network-related information and characteristics
• C) MySQL Query Analysis data
• D) CPU utilization
• E) Security-related advisor warnings
• F) Operating system memory utilization
• G) Disk usage and disk characteristic including disk advisor warnings

Answer: A, C, E

中文翻译：
使用 MySQL Enterprise Monitor 的无代理安装方式监控 MySQL 服务器。
该方法提供哪些三个功能？（选择三项）
• A) MySQL 复制监控
• B) 网络相关信息和特征
• C) MySQL 查询分析数据
• D) CPU 利用率
• E) 安全相关的建议警告
• F) 操作系统内存利用率
• G) 磁盘使用和磁盘特征包括磁盘建议警告

解析：

A) MySQL 复制监控
- 正确。通过SQL命令可远程获取复制状态，无需操作系统级agent。（正确答案）
B) 网络相关信息和特征
- 错误。无代理无法获取详细的网络IO、带宽、连接等操作系统级信息。
C) MySQL 查询分析数据
- 正确。通过采集慢日志、performance_schema或SQL采样等方式，可远程收集查询相关详情。（正确答案）
D) CPU 使用率
- 错误。无代理不能直接获取主机操作系统层面的CPU利用率。
E) 安全相关顾问报警
- 正确。安全顾问基于MySQL配置、账户、权限等远程数据库信息，可以获取和告警。（正确答案）
F) 操作系统内存利用率
- 错误。同样需要agent才能获知主机内存情况。
G) 磁盘使用率和磁盘顾问报警
- 错误。通常也依赖本地agent上报主机存储层、磁盘性能等详细信息，agentless只能获取到数据库级空间。

Q166

English:
You have a MySQL system with 500 GB of data, using both MyISAM and InnoDB engines, requiring frequent backups.
Backup requirements:
• The MySQL system must never be unavailable or locked to clients during backup.
• Recovery must work on any system.
• No more than 1 hour of data loss is allowed on recovery.
Which option fulfills all requirements?
• A) Take a physical backup of the MySQL system.
• B) Use the Clone Plugin to copy data to another MySQL system.
• C) Take a logical backup of the MySQL system.
• D) Take your backup from a slave of the MySQL system.

Answer: D

中文翻译：

你有一个包含 500 GB 数据的 MySQL 系统，使用 MyISAM 和 InnoDB 引擎，需要频繁备份。
备份要求：
• 备份期间 MySQL 系统必须始终可用且不锁定客户端。
• 恢复必须能在任意系统上进行。
• 恢复时最多允许 1 小时的数据丢失。

哪个选项满足所有要求？

• A) 对 MySQL 系统进行物理备份。
• B) 使用克隆插件将数据复制到另一台 MySQL 系统。
• C) 对 MySQL 系统进行逻辑备份。
• D) 从 MySQL 系统的从库进行备份。

答案： D

解析：
从从库备份可以保证主库不受影响，满足无停机要求。并且从库数据是实时同步的，恢复时最多丢失一小时数据（通过复制延迟控制）。物理备份可能导致停机，逻辑备份恢复时间长且不适合大数据量，克隆插件不适合混合存储引擎环境。

Q167

English:
A colleague complains about slow website response. Examine this output:

mysql> SHOW GLOBAL STATUS LIKE 'Table_lock%';
+-----------------------+-------+
| Variable_name         | Value |
+-----------------------+-------+
| Table_locks_immediate | 53148 |
| Table_locks_waited    | 17716 |
+-----------------------+-------+

What is the most likely cause of the high number of lock waits?
A) Using MyISAM storage engine for most common tables.
B) Using InnoDB engine and statements wait while data is inserted.
C) InnoDB buffer pool is full.
D) Table accesses wait for OS-level flush.

Answer: A

中文翻译：
同事抱怨网站响应慢。查看以下输出：

mysql> SHOW GLOBAL STATUS LIKE 'Table_lock%';
+-----------------------+-------+
| Variable_name         | Value |
+-----------------------+-------+
| Table_locks_immediate | 53148 |
| Table_locks_waited    | 17716 |
+-----------------------+-------+

导致大量锁等待的最可能原因是什么？
A) 大多数常用表使用了 MyISAM 存储引擎。
B) 使用 InnoDB 引擎，语句在数据插入时等待。
C) InnoDB 缓冲池已满。
D) 表访问等待操作系统级的刷新。

解析：
MyISAM 表采用表级锁，多个连接同时访问时容易造成锁等待，导致性能瓶颈。而 InnoDB 支持行级锁，锁等待较少。高的 Table_locks_waited 说明表级锁冲突严重，故最可能原因是使用了 MyISAM 存储引擎。

A) 大部分常用表都在用MyISAM存储引擎
正确。MyISAM只支持表级锁，每次写操作会锁全表，且并发高时容易大量等待锁（Table_locks_waited）。（正确答案）
B) 用InnoDB引擎且写入数据时语句会等待
错误。InnoDB主要用行级锁，只有极特殊情况才用表锁，不会导致 Table_locks_waited 持续升高。
C) InnoDB缓冲池已满
错误。缓冲池满会影响缓存命中率和磁盘I/O，不直接引起表锁等候。
D) 表的访问在等待操作系统层的刷新
错误。与表锁等待无直接关系。

Q168

English:
Your MySQL installation is running low on space due to binary logs. You need to reduce log space usage urgently.
Which two sets of actions will accomplish this? (Choose two.)
A) Use SET GLOBAL binlog_expire_logs_seconds= and restart the server.
B) Set binlog_expire_logs_seconds in my.cnf.
C) Set binlog_expire_logs_seconds=0 in my.cnf and restart the server.
D) Use SET PERSIST binlog_expire_logs_seconds=.
E) Use PURGE BINARY LOGS TO <binlog_name>.
F) Use SET GLOBAL binlog_expire_logs_seconds= and run FLUSH BINARY LOGS.

Answer: E, F

中文翻译：
由于二进制日志导致 MySQL 安装空间不足，你需要紧急减少日志空间使用。
哪两组操作可以实现此目的？（选择两项）
A) 使用 SET GLOBAL binlog_expire_logs_seconds=<值> 并重启服务器。
B) 在 my.cnf 中设置 binlog_expire_logs_seconds。
C) 在 my.cnf 中设置 binlog_expire_logs_seconds=0 并重启服务器。
D) 使用 SET PERSIST binlog_expire_logs_seconds=<值>。
E) 使用 PURGE BINARY LOGS TO <binlog_name>。
F) 使用 SET GLOBAL binlog_expire_logs_seconds=<值> 并执行 FLUSH BINARY LOGS。

解析：
要紧急释放二进制日志空间，最直接的方法是使用 PURGE BINARY LOGS TO 命令删除旧日志（选项 E）。
设置过期时间参数（binlog_expire_logs_seconds）需要重启或持久化设置才能生效，且不能立即释放空间。使用 SET GLOBAL binlog_expire_logs_seconds 结合 FLUSH BINARY LOGS （选项 F）可以立即生效并清理旧日志。
选项 A、B、C、D 由于需要重启或不立即生效，不适合紧急情况。

Q169

English:
Which two storage engines provide a view of the data consistent with the storage system at any moment? (Choose two.)
A) MyISAM
B) NDB
C) MEMORY
D) ARCHIVE
E) InnoDB

Answer: B, E

中文翻译：
哪两种存储引擎能提供与存储系统在任意时刻一致的数据视图？（选择两项）
A) MyISAM
B) NDB
C) MEMORY
D) ARCHIVE
E) InnoDB

解析：
NDB 和 InnoDB 支持事务和一致性视图，保证数据的瞬时一致性。MyISAM 是非事务表，不保证一致性。MEMORY 和 ARCHIVE 也不具备事务一致性视图。

Q170

English:
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 from establishing access to the MySQL instance?
A) ALTER USER 'joe'@'%' ACCOUNT LOCK
B) ALTER USER 'joe'@'%' SET PASSWORD='invalid'
C) REVOKE ALL PRIVILEGES ON . FROM 'joe'@'%'
D) REVOKE USAGE ON . FROM 'joe'@'%'
E) ALTER USER 'joe'@'%' IDENTIFIED BY 'invalid' PASSWORD EXPIRE
F) ALTER USER 'joe'@'%' PASSWORD HISTORY 0

Answer: A, E

中文翻译：
查看 Joe 的账户：

CREATE USER 'joe'@'%' IDENTIFIED BY '*secret*';
GRANT ALL PRIVILEGES ON *.* TO 'joe'@'%';

所有 Joe 的现有连接被终止。
哪两个命令会阻止 Joe 建立对 MySQL 实例的访问？
A) ALTER USER 'joe'@'%' ACCOUNT LOCK
B) ALTER USER 'joe'@'%' SET PASSWORD='invalid'
C) REVOKE ALL PRIVILEGES ON . FROM 'joe'@'%'
D) REVOKE USAGE ON . FROM 'joe'@'%'
E) ALTER USER 'joe'@'%' IDENTIFIED BY 'invalid' PASSWORD EXPIRE
F) ALTER USER 'joe'@'%' PASSWORD HISTORY 0

解析：

A) ALTER USER 'joe'@'%' ACCOUNT LOCK
正确。ACCOUNT LOCK 可以锁定账户，锁定后即使命令密码正确也无法登录。（正确答案）
B) ALTER USER 'joe'@'%' SET PASSWORD='invalid'
错误。SET PASSWORD设置的是普通密码，如果Joe自己知道新密码还可登录，此命令不足以保证禁止访问。
C) REVOKE ALL PRIVILEGES ON . FROM 'joe'@'%'
错误。REVOKE只撤销了权限，并不阻止登录，用户依然可以成功连接，只是没有操作权限。
D) REVOKE USAGE ON . FROM 'joe'@'%'
错误。USAGE并非实际权限，REVOKE USAGE效果等同于REVOKE ALL，但不会禁用登录。
E) ALTER USER 'joe'@'%' IDENTIFIED BY 'invalid' PASSWORD EXPIRE
正确。
- ALTER USER ... IDENTIFIED BY 'invalid' 这部分将joe用户的登录密码修改为invalid。
- PASSWORD EXPIRE 这部分的作用是：将用户的当前密码状态标记为"已过期"（EXPIRED）。
- 只要用户的密码处于已过期状态，MySQL会要求用户在下次登录时强制更改密码才能继续操作。设置无效密码并强制密码过期后，Joe下次登录时必须更改密码才能继续，且不知道新密码时无法登录。这种方式可以有效阻止其进一步访问。（正确答案）
F) ALTER USER 'joe'@'%' PASSWORD HISTORY 0
错误。该命令只是设置密码历史条数，不会阻止登录。

Q171

English:
Examine this MySQL client command to connect to a remote database:

mysql -h remote-example.org -u root --protocol=TCP --ssl-mode=
Which two --ssl-mode values will ensure that an X.509-compliant certificate is used to establish the SSL/TLS connection to MySQL?
A) VERIFY_CA
B) REQUIRED
C) DISABLED
D) PREFERRED
E) VERIFY_IDENTITY

Answer: A, E

中文翻译：
查看这个用于连接远程数据库的 MySQL 客户端命令：

mysql -h remote-example.org -u root --protocol=TCP --ssl-mode=

哪两个 --ssl-mode 的值能确保使用符合 X.509 的证书来建立 SSL/TLS 连接？
A) VERIFY_CA
B) REQUIRED
C) DISABLED
D) PREFERRED
E) VERIFY_IDENTITY

解析：
VERIFY_CA 和 VERIFY_IDENTITY 模式都要求客户端验证服务器的 X.509 证书，确保连接的安全性。其他模式要么不强制使用证书，要么不验证证书。

Q172

English:
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@%      |
+----------------+---------------+

Which two are true?
A) Mary connected using a UNIX socket.
B) Mary connected from a client machine whose IP address is 192.0.2.101.
C) Mary connected to the database server whose IP address is 192.0.2.101.
D) Mary has the privileges of account mary@%.
E) Mary authenticated to the account mary@192.0.2.101.

Answer: B, D

中文翻译：
Mary 从 Windows 客户端连接到 Linux MySQL 服务器。查看以下语句和输出：
sql
mysql> SELECT USER(), CURRENT_USER();
+----------------+---------------+
| USER() | CURRENT_USER()|
+----------------+---------------+
| mary@192.0.2.101 | mary@% |
+----------------+---------------+
哪两项是正确的？
A) Mary 使用 UNIX 套接字连接。
B) Mary 从 IP 地址为 192.0.2.101 的客户端机器连接。
C) Mary 连接到了 IP 地址为 192.0.2.101 的数据库服务器。
D) Mary 拥有账号 mary@% 的权限。
E) Mary 认证的是账号 mary@192.0.2.101。

解析：
USER() 返回客户端的连接信息，显示 Mary 从 IP 192.0.2.101 连接，说明客户端 IP 是该地址。
CURRENT_USER() 表示实际认证的账户，这里是 mary@%，说明权限是该账户的权限。不是 UNIX socket 连接，且认证账户不是基于 IP 的。

Q173

English:
Examine this command, which executes successfully:
bash
mysqlbackup --defaults-file=/backups/server-my.cnf --backup-dir=/backups/ full copy-back
Which statement is true about the copy-back process?
A) It restores files from the backup directory to their original MySQL server locations.
B) The copy-back process makes inconsistent backups.
C) The copy-back process is used to overwrite a new backup over an existing backup.
D) It restores files from the data directory to their original MySQL server locations

Answer: D

中文翻译：
查看这条成功执行的命令：

mysqlbackup --defaults-file=/backups/server-my.cnf --backup-dir=/backups/ full copy-back
关于 copy-back 过程，哪个说法正确？
A) 它将备份目录中的文件恢复到 MySQL 服务器的原始位置。
B) copy-back 过程会生成不一致的备份。
C) copy-back 过程用于将新备份覆盖已有备份。
D) 它将数据目录中的文件恢复到 MySQL 服务器的原始位置。

解析：

参数逐项讲解

mysqlbackup
MySQL官方企业级备份恢复工具的命令行主程序（不是社区mariabackup/xtrabackup）。
--defaults-file=/backups/server-my.cnf
指定一个MySQL配置文件（通常含有连接信息、目录结构参数等），此参数允许命令读取里面的配置信息，如datadir、端口、Socket等。这可以保证还原过程与目标数据库的参数匹配。
--backup-dir=/backups/
指定备份存放目录。这里的数据是之前backup/restore操作保存的完整物理备份，包括数据文件、日志、元数据文件等。copy-back操作会从此目录还原文件到MySQL数据目录(datadir)。
full copy-back
full指定操作对象为一次“完整备份”（区别于增量、差异备份）；
copy-back表示“恢复”操作，即把备份文件从备份目录复制到MySQL实例的数据目录。这个步骤通常用于停库情况下的还原。

总结命令作用

把/backups/目录里的MySQL完整物理备份，按server-my.cnf中的参数，还原回MySQL的数据目录，实现数据库恢复。

copy-back 过程是将备份数据从备份目录恢复到 MySQL 的数据目录（data directory），即恢复到服务器的原始数据文件位置。选项 A 正确。
D 选项表述不准确，备份目录和数据目录是不同的。
B 选项错误.copy-back 恢复的是一致备份。
C 选项描述不符合备份恢复的实际用途。

Q174

English:
You are planning to take a full MySQL instance backup.
Which two factors will help to determine the backup strategy?
A) the expected size of the backup
B) how much down time is planned
C) the OS super user rights
D) the number of user accounts for the MySQL instance
E) the location of the physical server

Answer: A, B

中文翻译：

你计划对整个 MySQL 实例进行完整备份。
哪两个因素有助于确定备份策略？
A) 预期备份数据的大小
B) 计划的停机时间长短
C) 操作系统超级用户权限
D) MySQL 实例的用户账户数量
E) 物理服务器的位置

解析：

备份策略通常取决于数据大小（影响备份时间和存储需求）和允许的停机时间（影响备份方式选择，如热备或冷备）。操作系统权限、用户账户数和服务器位置对备份策略影响较小。

备份策略

https://dev.mysql.com/doc/refman/8.0/en/backup-policy.html

Q175

English:
Which three are characteristics of logical backups?
A) They consist of exact copies of database directories and files.
B) They can be created by mysqlbackup for InnoDB tables or by file-system commands, such as cp, scp, tar, or rsync, for MyISAM tables.
C) They can be performed while the MySQL server is not running.
D) They can be run only against a running MySQL server.
E) They are machine independent and highly portable.
F) Backup and restore granularity is available at the server level, database level, or table level for any storage engine.
G) In addition to databases, backups can include any related files, such as log or configuration files.

Answer: D, E, F

中文翻译：

下列哪三项是逻辑备份的特点？
A) 它们是数据库目录和文件的精确拷贝。
B) 它们可以通过 mysqlbackup 对 InnoDB 表创建，或通过文件系统命令（如 cp、scp、tar、rsync）对 MyISAM 表创建。
C) 它们可以在 MySQL 服务器未运行时执行。
D) 它们只能针对正在运行的 MySQL 服务器执行。
E) 它们与机器无关，具有高度可移植性。
F) 备份和恢复的粒度可在服务器级、数据库级或表级，对任何存储引擎均可用。
G) 除数据库外，备份还可以包含日志或配置文件等相关文件。

解析：

A) 它们是数据库目录和文件的精确副本。
错误。这是典型“物理备份”特征，逻辑备份是导出SQL语句或文本，不复制物理存储文件。
B) 对于InnoDB表可用mysqlbackup备份，对于MyISAM表可用cp等文件工具备份。
错误。这些都是物理备份方法，不属于逻辑备份类别。
C) 逻辑备份可以在MySQL服务未运行的情况下执行。
错误。逻辑备份工具（如mysqldump）需要通过SQL与数据库通讯，服务必须启动才能备份。
D) 只能针对正在运行的MySQL服务器执行。
正确。逻辑备份工具只能连接运行中的数据库，通过SQL导出数据。（正确答案）
E) 逻辑备份具有机器无关性和高度可移植性。
正确。逻辑备份多为文本格式（如SQL），不同平台、不同硬件间易于迁移导入。（正确答案）
F) 可针对任意存储引擎，实现服务器、库或表级别的备份和恢复粒度。
正确。逻辑备份可灵活导出/导入指定库或表，无论存储引擎。（正确答案）
G) 备份除数据库以外，还可包括日志或配置文件。
错误。逻辑备份一般只包含“数据库结构和数据”，日志/配置需用物理方式单独备份。

Q176

English:
What does the slave SQL thread do?
A) reads the relay log and executes the events contained in them
B) connects to the master and asks it to send updates recorded in its binary logs
C) acquires a lock on the binary log for reading each event to be sent to the slave
D) monitors

Answer: A

中文翻译：

从库的 SQL 线程做什么？
A) 读取中继日志并执行其中包含的事件
B) 连接主库并请求发送记录在主库二进制日志中的更新
C) 对二进制日志加锁以读取每个事件发送给从库
D) 监控

解析：

关联知识Q86

从库的 SQL 线程负责读取中继日志（relay log）并执行其中的事件以应用主库的变更。
选项 B 是 IO 线程的职责，C 和 D 不符合定义。

Q178

Original:
Which three components comprise MySQL InnoDB Cluster to achieve database high availability?
A. MySQL Servers with Group Replication to replicate data to all members of the cluster
B. MySQL X Plugin to enable MySQL to use the X Protocol to speed up and monitor data replication
C. MySQL Semi-Sync replication plugin is used to provide cluster consistency
D. MySQL Shell to create and administer InnoDB Clusters using the built-in AdminAPI
E. MySQL Enterprise Backup to keep data consistent and always ready to be used
F. MySQL Router to ensure that client requests are load balanced and routed to the correct servers

Answer: A, D, F

中文翻译：
MySQL InnoDB Cluster 由哪三部分组成以实现数据库高可用性？
A. 带有组复制功能的 MySQL 服务器，用于将数据复制到集群的所有成员
B. MySQL X 插件，启用 MySQL 使用 X 协议以加速和监控数据复制
C. MySQL 半同步复制插件，用于提供集群一致性
D. 使用内置 AdminAPI 创建和管理 InnoDB 集群的 MySQL Shell
E. MySQL 企业备份，用于保持数据一致并随时可用
F. MySQL 路由器，确保客户端请求负载均衡并路由到正确的服务器

解析：

A. MySQL Servers with Group Replication to replicate data to all members of the cluster
正确。组复制（Group Replication）是InnoDB Cluster的核心，保证数据同步和自动故障转移。（正确答案）
B. MySQL X Plugin
错误。X Plugin 主要用于NoSQL/X协议接口，与HA集群支撑无直接强绑定关系。
C. MySQL Semi-Sync replication plugin
错误。半同步复制是与传统主从/主备架构相关，InnoDB Cluster高可用性依赖组复制。
D. MySQL Shell to create and administer InnoDB Clusters using the built-in AdminAPI
正确。MySQL Shell（含AdminAPI）是管理和初始化InnoDB集群的官方推荐工具。（正确答案）
E. MySQL Enterprise Backup
错误。虽然备份很重要，但它不属于InnoDB Cluster提供高可用的核心组件。
F. MySQL Router to ensure that client requests are load balanced and routed to the correct servers
正确。MySQL Router 支持故障自动切换和负载均衡，是InnoDB Cluster外部访问的关键部分。（正确答案）

MySQL InnoDB Cluster 高可用集群简介

https://dev.mysql.com/doc/refman/8.0/en/mysql-innodb-cluster-introduction.html

MySQL InnoDB Cluster 是 MySQL 官方推荐的高可用（High Availability, HA）一体化解决方案，通过整合多项 MySQL 技术，帮助用户快速搭建易用且可靠的数据库高可用环境。

主要特点：
- 至少包含三台 MySQL Server 实例构成集群
- 能够自动实现高可用与扩展，提升数据库服务的可靠性和弹性
- 使用 MySQL Group Replication 实现数据同步与主备转换
- 集成 MySQL Router 实现客户端的高可用透明路由

2. 相关技术组件

MySQL Shell：高级客户端工具，支持脚本配置与管理（提供 JavaScript/Python 接口）
MySQL Server with Group Replication：
- 实现多节点间自动数据复制
- 支持集群自动成员管理、故障容错、自动主从切换等
MySQL Router：轻量级路由中间件，帮助应用透明地连接 InnoDB Cluster

3. 集群架构说明

单主多从模式（默认）：
- 1 个主实例（Read/Write），负责读写
- 2 个副本实例（Read Only），用于数据高可用和只读分流
- 主节点写入的数据会自动通过 Group Replication 同步到其他从节点
多主模式（高级——所有实例均可为主节点）
MySQL Router作用：
- 将客户端请求自动转发到当前主节点，实现故障切换自动化
- 支持负载均衡等高级连接管理功能

4. 部署与管理简化

通过 AdminAPI（MySQL Shell 提供）脚本化自动管理，无需逐节点手动配置
支持 JavaScript、Python 两种脚本语言，适合自动化部署和大规模环境运维
可动态修改集群拓扑结构，保证持续高可用

5. 实例扩容与自动克隆

支持 MySQL Clone 功能，新节点可自动加入集群、自动同步数据，无须手动传输
集群和路由器（MySQL Router）集成紧密，支持自动“引导”（bootstrapping），无需手动路由配置

6. 管理与监控

通过 AdminAPI，能集中管理集群的状态、节点、路由器，包含集群内路由器的健康信息
可为路由器自动创建专用账号，提升安全性和自动化水平

7. 兼容性说明

InnoDB Cluster 不支持 MySQL NDB Cluster，这两者是不同的产品系列。

8. 参考资料

管理命令方法：详见 MySQL Shell AdminAPI（支持 JavaScript & Python）
详细文档参见各相关用户手册和开发文档

Q179

Original:

CREATE ROLE r_world_rd;
GRANT SELECT ON world.* TO r_world_rd;
CREATE USER john IDENTIFIED BY 'p@ssw0rd';
GRANT r_world_rd TO john;

Examine these statements issued by user John:

mysql> SHOW GRANTS;
+-----------------------------------------+
| Grants for john@%                       |
+-----------------------------------------+
| GRANT USAGE ON *.* TO 'john'@'%'        |
| GRANT 'r_world_rd'@'%' TO 'john'@'%'    |
+-----------------------------------------+
2 rows in set (0.01 sec)

mysql> SELECT * FROM world.city;
ERROR 1142 (42000): SELECT command denied to user 'john'@'localhost' for table 'city'

Examine these statements, which execute successfully:
What is the reason for the error?

A. John needs to reconnect to the database.
B. The statement was blocked by MySQL Firewall.
C. John has not activated the role.
D. The DBA needs to execute FLUSH PRIVILEGES.

Answer: C

中文翻译：

CREATE ROLE r_world_rd;
GRANT SELECT ON world.* TO r_world_rd;
CREATE USER john IDENTIFIED BY 'p@ssw0rd';
GRANT r_world_rd TO john;

Examine these statements issued by user John:

mysql> SHOW GRANTS;
+-----------------------------------------+
| Grants for john@%                       |
+-----------------------------------------+
| GRANT USAGE ON *.* TO 'john'@'%'        |
| GRANT 'r_world_rd'@'%' TO 'john'@'%'    |
+-----------------------------------------+
2 rows in set (0.01 sec)

mysql> SELECT * FROM world.city;
ERROR 1142 (42000): SELECT command denied to user 'john'@'localhost' for table 'city'

查看这些语句，哪些能成功执行：
错误的原因是什么？
A. John 需要重新连接数据库。
B. 语句被 MySQL 防火墙阻止。
C. John 没有激活该角色。
D. DBA 需要执行 FLUSH PRIVILEGES。

解析：

题中情况如下：
• 创建了角色 r_world_rd 并授权 SELECT 权限给角色。
• 创建用户 john 并将角色授权给他。
• SHOW GRANTS 显示 john 有角色权限，但执行 SELECT * FROM world.city; 时出现权限拒绝错误。
这是因为 MySQL 中，角色授权给用户后，用户需要激活角色才能使用角色权限。未激活角色时，用户权限不会生效，导致权限不足报错。
选项分析：
• A：重新连接数据库不会自动激活角色，不能解决问题。
• B：防火墙阻止与题意不符，且错误代码是权限错误，不是防火墙阻止。
• C：未激活角色确实是权限不足原因
• D：FLUSH PRIVILEGES 用于刷新权限表，使权限变更生效。若 DBA 新增了权限但未刷新，权限不会生效，导致访问被拒。图片中显示 SHOW GRANTS 已显示角色权限给用户，说明权限表已刷新，理论上无需执行 FLUSH PRIVILEGES。

1. MySQL角色（Role）简介

MySQL 中的角色（role）是一组权限的集合，类似于用户账户。可以将权限赋予角色，再将角色分配给用户，实现权限的批量分配和灵活管理，免去为每个用户单独配置繁琐特权的过程。

2. 角色管理的核心操作

创建与删除角色：
- 用 CREATE ROLE 创建角色
- 用 DROP ROLE 删除角色
授权与收回权限：
- 用 GRANT 向用户或角色授予权限或角色
- 用 REVOKE 收回用户或角色的权限（无法收回 mandatory_roles 里的角色）
查询权限和角色：
- 用 SHOW GRANTS 查看账户或角色的所有权限与角色分配情况
激活与默认角色设置：
- SET DEFAULT ROLE 设置某用户登录时默认激活的角色
- SET ROLE 在当前会话中动态切换激活的角色
- CURRENT_ROLE() 查询当前会话激活的角色集合
系统变量：
- mandatory_roles：定义所有用户都自动拥有的强制角色
- activate_all_roles_on_login：控制用户登录时是否自动激活全部已授权角色

3. 角色的创建、授权与用户分配

示例：

有数据库 app_db，开发人员需要全部权限，部分用户只读，部分用户读写。

步骤（简化）：

创建角色

CREATE ROLE 'app_developer', 'app_read', 'app_write';

授权角色

GRANT ALL ON app_db.* TO 'app_developer';
GRANT SELECT ON app_db.* TO 'app_read';
GRANT INSERT, UPDATE, DELETE ON app_db.* TO 'app_write';

创建用户

CREATE USER 'dev1'@'localhost' IDENTIFIED BY 'dev1pass';
CREATE USER 'read_user1'@'localhost' IDENTIFIED BY 'read_user1pass';
CREATE USER 'read_user2'@'localhost' IDENTIFIED BY 'read_user2pass';
CREATE USER 'rw_user1'@'localhost' IDENTIFIED BY 'rw_user1pass';

分配角色

GRANT 'app_developer' TO 'dev1'@'localhost';
GRANT 'app_read' TO 'read_user1'@'localhost', 'read_user2'@'localhost';
GRANT 'app_read', 'app_write' TO 'rw_user1'@'localhost';

设置默认激活角色

SET DEFAULT ROLE ALL TO
  'dev1'@'localhost',
  'read_user1'@'localhost',
  'read_user2'@'localhost',
  'rw_user1'@'localhost';

4. 强制角色 mandatory_roles

在 MySQL 启动时（配置文件）或运行时（SET PERSIST）可设置 mandatory_roles
所有用户会自动获得这些角色，无需单独分配。
如需设置，配置示例：
SET PERSIST mandatory_roles = 'role1,role2@localhost,r3@%.example.com';
配置权限要求：需要 ROLE_ADMIN 和 SYSTEM_VARIABLES_ADMIN 权限。

5. 查询与校验角色权限

查看用户有哪些角色及权限
SHOW GRANTS FOR 'user'@'host';
SHOW GRANTS FOR 'user'@'host' USING 'role1', 'role2';
USING 子句可以“展开”角色，显示角色实际拥有的权限。

6. 角色激活与切换

SET ROLE 动态激活、切换、或禁用某些角色。
例如：
- SET ROLE NONE; 当前会话无激活角色
- SET ROLE ALL EXCEPT 'app_write'; 只激活写以外的所有角色
- SET ROLE DEFAULT; 恢复登录默认激活的角色

7. 撤销和恢复角色权限

使用 REVOKE 可撤销已分配给角色的权限，影响所有获得该角色的用户。
恢复权限直接用 GRANT 重新授权。

8. 删除角色

DROP ROLE 'app_read', 'app_write';
删除角色后，相应角色会被自动从所有用户撤销。

9. 用户与角色的互通性

角色和用户账户互为授权对象，可灵活延展权限体系。
GRANT 'user1', 'role1' TO 'user2'; 既可将角色授权给用户，也可将一个用户当作角色授权给另一个用户或角色。
但二者的一些属性有区别，比如创建ROLE默认锁定，而用户默认未锁定。

10. 实用场景举例

老系统开发账户直接有权限，后续可将旧用户账户锁定作为“角色”，新开发人员创建新账户并继承其权限：
ALTER USER 'old_dev'@'localhost' ACCOUNT LOCK;
CREATE USER 'new_dev'@'localhost' IDENTIFIED BY 'newpass';
GRANT 'old_dev'@'localhost' TO 'new_dev'@'localhost';

Q180

Original:
Which three are features of MySQL Enterprise Backup?
A. the ability to use the output file, which contains SQL statements, as input to a MySQL session
B. the ability to edit the output file produced by MySQL Enterprise Backup
C. the ability to back up individual tables or individual tablespaces while your server instance is online
E. the ability to extract and restore individual rows from a backup
F. the ability to perform incremental backups

Answer: A, C, F

中文翻译：

MySQL Enterprise Backup 的三个特性是什么？
A. 能够将包含 SQL 语句的输出文件作为 MySQL 会话的输入使用
B. 能够编辑 MySQL Enterprise Backup 生成的输出文件
C. 能够在服务器实例在线时备份单个表或单个表空间
E. 能够从备份中提取并恢复单个行数据
F. 能够执行增量备份

解释：

• A：MySQL Enterprise Backup 可以生成逻辑备份文件，包含 SQL 语句，这些文件可以作为 MySQL 会话的输入用于恢复。
• C：支持在线备份单个表或表空间，无需关闭服务器。
• F：支持增量备份，只备份自上次备份后更改的数据。

选项 B 和 E 不正确，因为：
• B：输出文件不建议手动编辑。
• E：备份工具通常不支持直接提取和恢复单行数据，行级恢复需要专门工具或逻辑导出。

Q181

Original:
Which two statements are true about InnoDB data-at-rest encryption?
A. It does not support the transportable tablespaces feature.
B. It supports only non-blob datatypes.
C. It enforces encryption from disk to memory and over network transmission.
D. It decrypts data for use in memory
E. It supports all indexes transparently.

Answer: D, E

中文翻译：

关于 InnoDB 静态数据加密，哪两个说法是正确的？
A. 不支持可迁移表空间功能。
B. 只支持非 BLOB 数据类型。
C. 实现从磁盘到内存以及网络传输的加密。
D. 在内存中使用时会解密数据。
E. 透明支持所有索引。

解释：
• D：静态加密的数据在加载到内存时会被解密供服务器使用。
• E：加密对索引透明，所有索引均被支持，无需特殊处理。
选项 A、B、C 不正确，因为：
• A：InnoDB 支持带加密的可迁移表空间（有部分限制）。
• B：加密适用于所有数据类型，不仅限非 BLOB 类型。
• C：静态数据加密保护磁盘上的数据，网络传输加密由 SSL/TLS 等机制单独处理，不属于静态数据加密范畴。

MySQL 8.4 InnoDB 静态数据加密（Data-at-Rest Encryption）功能说明

1. 静态数据加密简介

InnoDB 采用两级加密密钥架构：主加密密钥与表空间密钥。
- 表空间密钥加密实际数据，主加密密钥负责加密表空间密钥。
- 主加密密钥可轮换（master key rotation）。
加密功能依赖密钥管理 keyring 组件或插件。
MySQL 全部版本都提供 component_keyring_file，企业版额外支持 component_keyring_encrypted_file、keyring_okv、keyring_aws、keyring_hashicorp。
安全合规要求：仅 keyring_file/encrypted_file 不适合用于 PCI、FIPS 等场景，建议配合专业密钥管理系统。

加密算法：

使用高级加密标准（AES）。
表空间密钥加密用 ECB 模式；数据加密用 CBC 模式。

2. 加密前提条件

必须在 MySQL 启动时就加载一个（且只能有一个）keyring 组件/插件，否则将无法初始化 InnoDB。
创建了加密表空间后，启动时必须继续加载同一个 keyring 组件，否则启动出错且无法恢复数据。
主密钥丢失，数据无法恢复！
需及时备份 keyring 文件，尤其是首次加密、密钥轮换前后。

3. Schema 与表空间默认加密设置

使用 default_table_encryption 系统变量设置 schema 与 general tablespace 的默认加密属性（可全局或会话级设置）。
创建/修改 schema、表空间时可用 ENCRYPTION 明确声明；未声明则用 default_table_encryption。
变更已有表空间/schema 的加密必须显式带 ENCRYPTION 参数，不能自动生效。
启用 table_encryption_privilege_check 则需有 TABLE_ENCRYPTION_ADMIN 权限，才能突破默认加密策略。

4. 各表空间和日志的加密实践

文件表空间（file-per-table）：
- 默认为 schema 的加密设置，除非 CREATE TABLE 时显式指定 ENCRYPTION。
- 修改加密需 ALTER TABLE ... ENCRYPTION。
General 表空间：
- 默认为 default_table_encryption，也可显式指定 ENCRYPTION。
- 更改亦需 ALTER TABLESPACE ... ENCRYPTION。
Doublewrite 文件：
- 属于已加密表空间的页面会自动加密，无需手动干预。
mysql 系统表空间：
- 默认不加密，可以通过 ALTER TABLESPACE ... ENCRYPTION 显式开启或关闭。
- 需要有全实例 CREATE TABLESPACE 权限。
Redo Log/Undo Log:
- 通过 innodb_redo_log_encrypt/innodb_undo_log_encrypt 开启或关闭，默认不加密。
- 控制的是新写入的数据，历史数据不变。
- 启用加密后，启动必须有 keyring，否则无法读写相关日志。

5. 主加密密钥轮换（Master Key Rotation）

推荐定期轮换；只影响主密钥、重新加密表空间密钥，并不重新加密业务数据。
命令：ALTER INSTANCE ROTATE INNODB MASTER KEY;
需要 ENCRYPTION_KEY_ADMIN 权限。
支持与业务 DML 操作并发，但不能和表空间加密操作并发。
操作失败/中断可自动恢复。

6. 备份/导入与复制

导出/导入表空间 仅支持文件表空间类型，需配合 .cfp 文件和实际数据文件处理表空间密钥导出/导入。
主从复制：ALTER INSTANCE ROTATE INNODB MASTER KEY 可记录 binlog，但依赖主从均已启用支持加密的 keyring 组件。

7. 查询与监控

可通过 information_schema 查询表空间、表、schema 的加密状态字段（ENCRYPTION、CREATE_OPTIONS、DEFAULT_ENCRYPTION）。
配合 performance_schema 可监控加密进度（ALTER TABLESPACE 操作阶段性进度）。

8. 注意事项与限制

文件表空间加密用于表数据的页级加密；通用表空间与系统表空间支持就地加解密（INPLACE），支持并发 DML。
master key 只用来加密表空间密钥，不改变业务数据，只更表头字段。要改变表空间密钥，需先关闭再启用加密。
仅支持 AES 算法，ECB/CBC 模式，且 CBC 不使用填充（InnoDB 自行对齐块大小）。
并非所有表空间支持加密（如传统 system tablespace 除外）。
不允许将加密表的数据迁移至不支持加密的表空间，反过来则可以。
数据压缩和加密可同时开启，压缩在先于加密。
keyring 文件推荐和数据分离保存；删除 keyring 组件不等于清除 keyring 文件。

Q182

CREATE TABLE rental (
    rental_id int unsigned NOT NULL AUTO_INCREMENT,
    rental_date datetime NOT NULL,
    inventory_id int unsigned NOT NULL,
    customer_id int unsigned NOT NULL,
    return_date datetime DEFAULT NULL,
    staff_id int unsigned NOT NULL,
    last_update timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    PRIMARY KEY (rental_id)
) ENGINE=InnoDB;

Now examine this query:

SELECT rental_id, customer_id
FROM rental
WHERE rental_date BETWEEN NOW() - INTERVAL 1 MONTH AND NOW()
  AND inventory_id = 42
  AND staff_id = 1024;

Examine this statement, which executes successfully:
You want to add one or more indexes that minimize the work done by the query.
Which statement accomplishes this?

ALTER TABLE rental
    ADD INDEX (inventory_id, staff_id, customer_id, rental_id, rental_date);

ALTER TABLE rental
    ADD INDEX (inventory_id)
    ADD INDEX (staff_id),
    ADD INDEX (rental_date),
    ADD INDEX (customer_id);

ALTER TABLE rental
    ADD INDEX (inventory_id),
    ADD INDEX (staff_id),
    ADD INDEX (rental_date);

ALTER TABLE rental
    ADD INDEX (rental_date, inventory_id, staff_id, customer_id);

ALTER TABLE rental
    ADD INDEX (inventory_id, staff_id, rental_date, customer_id);

ALTER TABLE rental
    ADD INDEX (inventory_id, staff_id, rental_date);

Answer: E

中文翻译：

查看以下语句，这些语句能成功执行：

CREATE TABLE rental (
    rental_id int unsigned NOT NULL AUTO_INCREMENT,
    rental_date datetime NOT NULL,
    inventory_id int unsigned NOT NULL,
    customer_id int unsigned NOT NULL,
    return_date datetime DEFAULT NULL,
    staff_id int unsigned NOT NULL,
    last_update timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    PRIMARY KEY (rental_id)
) ENGINE=InnoDB;

Now examine this query:

SELECT rental_id, customer_id
FROM rental
WHERE rental_date BETWEEN NOW() - INTERVAL 1 MONTH AND NOW()
  AND inventory_id = 42
  AND staff_id = 1024;

你想添加一个或多个索引，以最小化查询所做的工作量。
哪个语句可以实现这个目标？
A.

 ALTER TABLE rental
    ADD INDEX (inventory_id, staff_id, customer_id, rental_id, rental_date);

ALTER TABLE rental
    ADD INDEX (inventory_id)
    ADD INDEX (staff_id),
    ADD INDEX (rental_date),
    ADD INDEX (customer_id);

ALTER TABLE rental
    ADD INDEX (inventory_id),
    ADD INDEX (staff_id),
    ADD INDEX (rental_date);

 ALTER TABLE rental
    ADD INDEX (rental_date, inventory_id, staff_id, customer_id);

ALTER TABLE rental
    ADD INDEX (inventory_id, staff_id, rental_date, customer_id);

ALTER TABLE rental
    ADD INDEX (inventory_id, staff_id, rental_date);

解释：

根据题意，查询是：

SELECT rental_id, customer_id
FROM rental
WHERE rental_date BETWEEN NOW() - INTERVAL 1 MONTH AND NOW()
  AND inventory_id = 42
  AND staff_id = 1024;

查询中有三个过滤条件：
• rental_date 是范围条件（BETWEEN）
• inventory_id 精确匹配
• staff_id 精确匹配
索引设计原则：
• 范围条件字段应放在索引的最后，因为范围条件后字段索引无法有效使用。
• 精确匹配字段应放在前面。
• 多个单列索引（C 选项）可以让优化器选择最优索引，或者进行索引合并。
选项分析：
• A 索引字段太多，浪费
• B MySQL只能用一列单列索引，需要多次回表，不推荐
• C MySQL只能用一列单列索引，需要多次回表，不推荐
• D 是覆盖索引，但不符合精确匹配字段放在前面、范围条件字段放在索引最后的设计原则
• E 是覆盖索引，且符合精确匹配字段放在前面、范围条件字段放在索引最后的设计原则
因此，E 是最佳选择。
• F 不是覆盖索引，需要回表或者索引下推

Q183

Original:
CREATE USER mary@192.0.2.100 IDENTIFIED BY 'p@SSw0rd' REQUIRE NONE PASSWORD EXPIRE;
Examine this statement, which executes successfully:
Which two are true?
A. Mary cannot query data until she changes her password.
B. Mary requires no password to connect to the MySQL server.
C. Mary cannot connect to the MySQL server until the DBA resets her password.
D. Mary must connect from the client machine 192.0.2.100.
E. Mary must connect using the username 'mary@192.0.2.100'

Answer: A, D

中文翻译：

查看以下成功执行的语句：
CREATE USER mary@192.0.2.100 IDENTIFIED BY 'p@SSw0rd' REQUIRE NONE PASSWORD EXPIRE;

哪两个说法是正确的？
A. Mary 在更改密码之前不能查询数据。
B. Mary 连接 MySQL 服务器时不需要密码。
C. Mary 在 DBA 重置密码之前不能连接 MySQL 服务器。
D. Mary 必须从客户端机器 192.0.2.100 连接。
E. Mary 必须使用用户名 'mary@192.0.2.100' 连接。

解释：

语句为：

CREATE USER mary@192.0.2.100 IDENTIFIED BY 'P@SSw0rd' REQUIRE NONE PASSWORD EXPIRE;

• mary@192.0.2.100：用户只能从 IP 地址 192.0.2.100 连接（对应选项 D 正确）。
• IDENTIFIED BY 'P@SSw0rd'：设置了初始密码。
• REQUIRE NONE：不要求使用 SSL。
• PASSWORD EXPIRE：密码立即过期，用户必须更改密码才能连接。

选项分析：

A. Mary 在更改密码前无法查询数据。
- 正确。
  因为 PASSWORD EXPIRE，首次登录后需要修改密码才有权限执行其他操作（如查询），否则只能登录，不能使用数据库。
B. Mary 连接 MySQL 服务器时无需密码。
- 错误。
  已通过 IDENTIFIED BY 'p@SSw0rd' 指定了密码，连接时必须填写该密码。
C. Mary 只有在 DBA 重设密码后才能连接 MySQL 服务器。
- 错误。
  用户本人首次登录时可以自己重设密码，无需管理员干预。
D. Mary 必须从客户端主机 192.0.2.100 连接。
- 正确。
  用户名写成 mary@192.0.2.100，表示只有从该 IP 登录时匹配此用户。
E. Mary 必须使用用户名 'mary@192.0.2.100' 进行连接。
- 错误。
  正确的用户名是 mary，而不是 mary@192.0.2.100。@ 后面是 MySQL 匹配用的主机部分，而不是用户名组成部分。

Q184

Original:
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. If ANALYZE TABLE is invoked from the same session, it hangs until the transaction is committed or rolled back.
B. If OPTIMIZE TABLE is invoked, it will create a table lock on t and force a transaction rollback.
C. If OPTIMIZE TABLE t is invoked from another session, it executes normally and returns the status.
D. mysqlcheck --analyze --all-databases will execute normally on all tables and return a report.

Answer: A

中文翻译：

t 是一个非空的 InnoDB 表。
以下语句在一个会话中执行：

BEGIN;
SELECT * FROM t FOR UPDATE;

哪个说法是正确的？
A. 如果在同一个会话中调用 ANALYZE TABLE，会挂起直到事务提交或回滚。
B. 如果调用 OPTIMIZE TABLE，会对表 t 加锁并强制回滚事务。
C. 如果在另一个会话中调用 OPTIMIZE TABLE t，它会正常执行并返回状态。
D. mysqlcheck --analyze --all-databases 会正常执行所有表并返回报告。
答案： A

解释：

给定的上下文是：

BEGIN;
SELECT * FROM t FOR UPDATE;

这表示当前会话开启了一个事务，并对表 t 进行了行级锁定。

• A：ANALYZE TABLE 在执行期间需要请求read lock，在同一会话中调用时，需要等待之前的锁释放,正确。
• B：OPTIMIZE TABLE 会对 InnoDB 表执行表重建操作，通常会加表锁，但不会强制回滚其他会话的事务。它会等待锁释放。
• C：行锁：SELECT ... FOR UPDATE 只锁定被选中的行，不会锁住整张表。OPTIMIZE TABLE（对 InnoDB）：本质上会 rebuild 表，需要获取独占的元数据锁（MDL X）。行锁和OPTIMIZE TABLE的独占表锁/元数据锁会冲突，错误；
• D：mysqlcheck --analyze --all-databases mysqlcheck 命令执行时，每个表在被处理时都会被加锁，因此在处理期间对其他会话不可用，不过对于检查（check）操作，表只会被加上读锁（READ lock），错误。

因此，A 是正确的选项。

Q185

Original:
What does the binlog dump thread do?
A) It monitors and schedules the rotation/deletion of the binary logs.
B) 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.
D) It connects to the master and asks it to send updates recorded in its binary logs.

Answer: C

中文翻译：

binlog dump 线程的作用是什么？
A) 它监控并调度二进制日志的轮换和删除。
B) 它读取中继日志并执行其中包含的事件。
C) 它在读取每个事件以发送给从服务器时获取对二进制日志的锁。
D) 它连接到主服务器并请求发送记录在其二进制日志中的更新。

解释：

binlog dump 线程是 MySQL 主服务器为每个连接的从服务器创建的线程，负责读取二进制日志中的事件并发送给从服务器。为了确保读取的一致性，它会获取二进制日志的读锁，防止日志在读取时被修改或轮换。
• 选项 A 描述的是二进制日志轮换管理的功能，不是 binlog dump 线程的职责。
• 选项 B 是从服务器上的 SQL 线程的职责，它读取并执行中继日志事件。
• 选项 D 是从服务器的 IO 线程的行为，不是 binlog dump 线程的功能。

Q186

Original:
You must replay the binary logs on your MySQL server.
Which command do you use?
A) mysqlbinlog binlog.000003 binlog.000004 binlog.000005 | mysql -h 127.0.0.1
B) mysqlbinlog -h 127.0.0.1 binlog.000003 binlog.000004 binlog.000005
C) mysqlpump -h 127.0.0.1 binlog.000003 binlog.000004 binlog.000005
D) cat binlog.000003 binlog.000004 binlog.000005 | mysql -h 127.0.0.1
E) mysql -h 127.0.0.1 --local-infile binlog.000003 binlog.000004 binlog.000005

Answer: A

中文翻译：

你必须在 MySQL 服务器上重放二进制日志。
你会使用哪个命令？
A) mysqlbinlog binlog.000003 binlog.000004 binlog.000005 | mysql -h 127.0.0.1
B) mysqlbinlog -h 127.0.0.1 binlog.000003 binlog.000004 binlog.000005
C) mysqlpump -h 127.0.0.1 binlog.000003 binlog.000004 binlog.000005
D) cat binlog.000003 binlog.000004 binlog.000005 | mysql -h 127.0.0.1
E) mysql -h 127.0.0.1 --local-infile binlog.000003 binlog.000004 binlog.000005

解释：

A) mysqlbinlog binlog.000003 binlog.000004 binlog.000005 | mysql -h 127.0.0.1
- 解释：使用 mysqlbinlog 工具解析多条 binlog 日志，将解析后内容通过管道传送给 mysql 客户端，让 MySQL 服务器执行。这是重放（replay）binlog 的标准、推荐方式。
B) mysqlbinlog -h 127.0.0.1 binlog.000003 binlog.000004 binlog.000005
- 解释：mysqlbinlog 不支持 -h 作为目标服务器参数，-h 在 mysqlbinlog 里用来读取远程服务器日志，并不能直接应用 replay，命令基本无效。
C) mysqlpump -h 127.0.0.1 binlog.000003 binlog.000004 binlog.000005
- 解释：mysqlpump 是逻辑备份工具，用于导出数据库结构和数据，不能重放 binlog 文件，参数也不对。
D) cat binlog.000003 binlog.000004 binlog.000005 | mysql -h 127.0.0.1
- 解释：直接 cat 二进制文件到 mysql，MySQL 不能识别 binlog 的二进制格式，会报错或破坏数据，不可行。
E) mysql -h 127.0.0.1 --local-infile binlog.000003 binlog.000004 binlog.000005
- 解释：--local-infile 别用于加载文本数据文件，本质并不会解析或重放 binlog，也不可用。

Q187

Original:

mysql> SHOW FULL PROCESSLIST;
+----+------------------+-----+----------------------------------------+----------------------+
| Id | User             | ... | State                                  | Info                 |
+----+------------------+-----+----------------------------------------+----------------------+
|  6 | event_scheduler  | ... | Waiting on empty queue                 |                      |
| 20 | root             | ... |                                        |                      |
| 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               |
+-----------+-----------------+------------------+--------------------+

Examine these commands and output: Which connection ID is holding the metadata lock?
A.6
B.22
C.20
D.21
E.24
F.25
Answer: C

中文翻译：

mysql> SHOW FULL PROCESSLIST;
+----+------------------+-----+----------------------------------------+----------------------+
| Id | User             | ... | State                                  | Info                 |
+----+------------------+-----+----------------------------------------+----------------------+
|  6 | event_scheduler  | ... | Waiting on empty queue                 |                      |
| 20 | root             | ... |                                        |                      |
| 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               |
+-----------+-----------------+------------------+--------------------+

查看以下命令和输出：哪个连接 ID 持有元数据锁？
A.6
B.22
C.20
D.21
E.24
F.25
答案： c

解释：

• SHOW FULL PROCESSLIST

显示当前 MySQL 数据库中，所有正在连接的会话（连接）。
其中关键字段：

Id：连接的唯一编号，这是连接ID，也叫会话ID，标识每一个客户端和MySQL的连接。例如：Id=22 就是某一个客户端连接的唯一编号。
User：连接的用户名。
State：当前连接在做什么，是否在等待、运行等。
Info：当前执行的 SQL 语句（如果有的话）。

• performance_schema.metadata_locks

显示当前有哪些元数据锁（metadata lock），以及它们的状态。
关键字段解释：

OBJECT_TYPE：锁作用的对象类型（如 TABLE 表、SCHEMA 数据库）。
OBJECT_SCHEMA：数据库名。
OBJECT_NAME：对象名（如表名）。
LOCK_TYPE：锁的类型（比如读锁、写锁）。
LOCK_STATUS：锁的状态（GRANTED表示已获取，PENDING表示还在等待）。
OWNER_THREAD_ID：持有该锁的线程编号（不是连接ID，后面我们会查对应关系）。
OWNER_EVENT_ID:事件ID，用来唯一标识某个线程在执行的一个具体“事件”或“操作”。
每个线程（THREAD_ID）可以有多个事件（EVENT_ID），比如一个线程先执行A操作，再执行B操作，每个操作都有自己的 EVENT_ID。
OWNER_EVENT_ID 主要用于 performance_schema 内部追踪锁与具体操作的对应关系。

• performance_schema.threads：

显示每个线程（MySQL 内部的 thread）和连接ID（processlist_id）之间的对应关系。
关键字段解释：

THREAD_ID：线程编号。
PROCESSLIST_ID：连接ID,就是上面 SHOW FULL PROCESSLIST 的 Id，用来对应连接和线程。
PROCESSLIST_USER：用户名。
PARENT_THREAD_ID：父线程编号，通常可以忽略。

• 注意：

SHOW FULL PROCESSLIST 里的 Id
这是连接ID，也叫会话ID，标识每一个客户端和MySQL的连接。
例如：Id=22 就是某一个客户端连接的唯一编号。
performance_schema.metadata_locks 里的 OWNER_EVENT_ID
这是事件ID，用来唯一标识某个线程在执行的一个具体“事件”或“操作”。
每个线程（THREAD_ID）可以有多个事件（EVENT_ID），比如一个线程先执行A操作，再执行B操作，每个操作都有自己的 EVENT_ID。
OWNER_EVENT_ID 主要用于 performance_schema 内部追踪锁与具体操作的对应关系。
连接、线程、事件的关系
一个连接（PROCESSLIST_ID/Id）对应一个线程（THREAD_ID）。
一个线程内，可能会产生多个事件（EVENT_ID），比如执行不同的SQL语句时。
所以：OWNER_EVENT_ID 只和线程里的操作有关，不和连接ID直接对应。

• 从 SHOW FULL PROCESSLIST 输出看，ID 为 22 和 24 的连接都在等待元数据锁,这两个连接Id排除。
• 从 performance_schema.metadata_locks 查询结果看，OWNER_THREAD_ID = 60 和 OWNER_THREAD_ID = 62 持有锁（GRANTED 状态表示已获取锁）。线程62 已经获得了 test 数据库的 INTENTION_EXCLUSIVE（意向排他）元数据锁（GRANTED）。它还在等待 demo_test 表的 SHARED_NO_READ_WRITE 元数据锁（PENDING）。
• 结合 performance_schema.threads 和 processlist 的映射，线程 60 对应的连接 ID 是 20，线程 62 对应的连接 ID 是 22。
• 从 SHOW FULL PROCESSLIST 输出看，ID 为 22 在等待元数据锁,所以持有元数据锁的是20。
综上，连接 ID 20 持有元数据锁，所以答案是 c。

MySQL 10.11.4 元数据锁（Metadata Locking）

https://dev.mysql.com/doc/refman/8.0/en/metadata-locking.html

Metadata Locking 简介

元数据锁的作用和对象
- MySQL 使用元数据锁来管理数据库对象的并发访问，确保数据一致性。
- 锁作用于：表、数据库（schema）、存储过程/函数/触发器/事件、表空间、GET_LOCK() 获得的用户锁、以及底层锁服务的锁等。
- 通过 Performance Schema 的 metadata_locks 表可查看锁持有和等待信息，排查阻塞问题。
性能影响
- 随着查询量增大，元数据锁会带来一定开销。
- 当多个查询同时访问同一对象时，争用会加剧，影响并发性能。
元数据锁的优先级与获取
- 写锁优先级高于读锁（可通过 max_write_lock_count 系统变量调整）。
- 如果 write 锁过多被连续优先，reach max_write_lock_count 后，read 锁可被优先满足，防止写锁“饿死”读锁。
- 元数据锁逐个获取，有死锁检测。
- DML 语句按语句中表的出现顺序锁定；DDL 语句/LOCK TABLES 等按表名排序后依次锁定，以减少死锁几率。
锁定顺序实际案例
- 同一个对象被多个会话操作时，锁定顺序影响最终执行顺序和结果。
- 例：RENAME TABLE 与 LOCK/INSERT，表名不同，锁获取顺序变化，导致 INSERT 作用目标表不同。
- 可通过调整表名影响锁的获取与执行顺序。
外键约束和关联表锁
- 对有外键约束的相关表，元数据锁会自动延伸以防止 DML 和 DDL 冲突。
元数据锁的释放时机
- 保证事务可串行化：被事务（显式或隐式）使用的表，其元数据锁要等到事务结束才释放，防止其它会话在事务未提交前对表做 DDL。
- 适用于所有表引擎（包括非事务表）。
- 对于 autocommit 模式，每条语句自动作为事务，锁仅保持到语句结束。
- 锁在 PREPARE 期间释放（即使在事务内）。
- XA 事务 PREPARED 状态下，锁在客户端断开或服务器重启后依旧保持，直到后续明确 XA COMMIT/ROLLBACK。

总结

元数据锁是保证结构/数据一致性和并发安全的核心机制之一。
锁的获取及释放存在复杂优先级和顺序，能直接影响到多线程环境下数据库操作的结果。
了解/监控/合理干预锁的行为，有助于提升数据库的高并发效率与安全性。

29.12.13.3 metadata_locks 表

简介

1. 定义与用途

metadata_locks 是 Performance Schema 提供的只读表，用于展示 MySQL 的元数据锁情况。
可以用来排查并发时的锁等待、锁竞争、死锁等问题，定位哪些会话持有锁、哪一些会话正等待锁，帮助分析锁依赖关系。

2. 能展示的信息：

已经授予的锁（当前会话持有的元数据锁）
等待授予的锁（哪些会话在等待哪些锁）
被死锁检测器终止的锁请求
等待超时未处理的锁请求

3. 锁状态和生命周期

LOCK_STATUS 字段用于显示每个锁的状态。每次锁操作，表内容会自动更新：
- GRANTED：锁已成功获取
- PENDING：当前请求等待中
- VICTIM：死锁检测中锁作为牺牲者（会被终结）
- TIMEOUT：请求超时未获锁
- KILLED：被 kill 命令终止
- PRE_ACQUIRE_NOTIFY、POST_RELEASE_NOTIFY：存储引擎进入/离开锁通知时的标记，极短暂
当锁释放时，该行会被删除。

4. 锁类型和作用对象：

OBJECT_TYPE 字段指定锁对象类别，有：GLOBAL、SCHEMA、TABLE、FUNCTION、PROCEDURE、EVENT、USER LEVEL LOCK（GET_LOCK()获得的用户锁）、LOCKING SERVICE、TABLESPACE、BACKUP LOCK 等。
OBJECT_SCHEMA、OBJECT_NAME 分别表示对象所属的 schema 和对象名。

5. 其他重要列说明：

OBJECT_INSTANCE_BEGIN：锁对象的内存地址（唯一标识）
LOCK_TYPE：锁类型（如 INTENTION_EXCLUSIVE、SHARED、EXCLUSIVE 等）
LOCK_DURATION：锁持续时间（STATEMENT、TRANSACTION、EXPLICIT）
SOURCE：产生这个事件的源码文件及行号
OWNER_THREAD_ID、OWNER_EVENT_ID：请求此锁的线程和事件

6. 索引：

主键: (OBJECT_INSTANCE_BEGIN)
辅助索引: (OBJECT_TYPE, OBJECT_SCHEMA, OBJECT_NAME)
辅助索引: (OWNER_THREAD_ID, OWNER_EVENT_ID)

7. 配置和控制

默认表大小自动调整，想自定义表容量可在 MySQL 启动参数设置 performance_schema_max_metadata_locks。
元数据锁统计通过名为 wait/lock/metadata/sql/mdl 的 instrument 进行，可在 my.cnf 启用/禁用，也可 runtime 动态调整（setup_instruments 表 UPDATE）。

8. 限制

只读表，不能 TRUNCATE。

总结

metadata_locks 是 MySQL 并发架构中定位元数据锁争用、死锁最直接的诊断工具。
通过本表可实时了解谁在等什么锁、谁已获得锁、是否有异常终止/超时等。
主要字段用于描述锁定对象、锁类型、锁持续时间、锁状态及拥有者、来源等。
支持对象粒度广泛，包括所有“数据库结构”类对象与部分特殊锁。
LOCK_STATUS 是排查锁竞争和异常的关键字段。
可通过参数和 instrument 对元数据锁监控级别进行控制。
作为只读表，不允许直接修改或截断。

MySQL中的元数据锁与普通锁？常见锁类型总览

一、元数据锁（Metadata Lock, MDL）与普通锁的区别

元数据锁（MDL）
- 目的：保护数据库对象（如表、库、存储过程等）的结构和定义在并发环境下的一致性。
- 作用对象：表结构、库、触发器、事件、表空间、用户级锁（如GET_LOCK）、锁服务等所有“结构级”对象。
- 行为：
  - 不会保护数据本身的并发访问，仅保护对象结构，防止 DDL（比如 ALTER、DROP、RENAME）和 DML 并发时发生冲突。
  - 特点是隐式自动加锁，无需手动控制，颗粒度较粗。
  - 贯穿全部存储引擎，只要操作 MySQL 元对象，就涉及 MDL。
  - 举例： 一个表参与未提交的事务期间，其他会话无法对该表做 DDL 操作（如 ALTER 结构），因为 MDL 锁住了表的元数据。
- 查询工具：performance_schema.metadata_locks
普通锁（数据锁，Data Lock）
- 目的：实现数据并发的一致性、隔离性，防止脏读、幻读、丢失更新等问题。
- 作用对象：表中的实际数据行或数据页，保护的是“数据内容”。
- 行为：
  - 对应不同的存储引擎有不同类型（如 InnoDB 支持行锁、表锁；MyISAM 只有表锁）。
  - 需要事务支持时可用显式语句（如 SELECT ... FOR UPDATE）。
  - 颗粒度较细（页级/行级/表级），直接影响并发性能和冲突概率。
  - 举例： 两个事务同时更新同一行记录（InnoDB 行锁冲突时等待或死锁）。

二、MySQL中的常见锁类型总览

元数据锁（Metadata Lock, MDL）
- 控制：表/字段/索引等结构的并发访问和修改
- 隐式加锁、自动管理，全局生效
表锁（Table Lock）
- 作用范围：整个表
- 应用场景：MyISAM、MEMORY存储引擎或显式 LOCK TABLES
- 性能影响：并发能力有限
行锁（Row Lock）
- 作用范围：单行（也可能是多行）
- 支持引擎：InnoDB
- 加锁方式：隐式（DML语句）、显式（如 SELECT ... FOR UPDATE、SELECT ... LOCK IN SHARE MODE）
- 优点：高并发支持，锁粒度细
页锁（Page Lock）
- 作用范围：数据页
- 主要用于某些老旧引擎（如BDB），MySQL主流存储引擎已极少见
意向锁（Intention Lock）
- 作用范围：表级，辅助 InnoDB 的多粒度锁管理
- 类型：意向共享锁（IS）、意向排它锁（IX）
- 自动加锁，无需显示控制
间隙锁（Gap Lock）与临键锁（Next-Key Lock）
- 只适用于 InnoDB（RR隔离级别）
- 防止幻读，实现可重复读
自定义用户锁（User-Level Lock）
- 通过函数如 GET_LOCK()、RELEASE_LOCK() 获取和释放，可以跨会话控制流程同步
- 不是保护数据、结构，而是应用层协作同步
全局锁（Global Lock）
- 应用场景常见于备份（如 FLUSH TABLES WITH READ LOCK）
- 阻塞所有写操作，部分读操作，对整个实例生效

三、简单对比表

锁名称	粒度/作用对象	保护内容	典型用途/场景	是否仅InnoDB支持
元数据锁	表/库/结构对象	结构/定义一致性	DDL和DML并发、阻止结构变更	×
表锁	整个表	数据	MyISAM, 显式LOCK TABLE	×
行锁	单行/多行	数据	InnoDB事务、DML并发	√
意向锁	表级	辅助行锁管理	多粒度锁定检测	√
间隙/临键锁	行间区间/索引区间	防幻读	RR级别隔离	√
用户级锁	跨会话/自定义	程序同步	业务逻辑中的锁，非数据/结构	×
全局锁	整库/全实例	所有表数据	备份、维护	×

四、总结

元数据锁：控制“表结构级”并发，自动管理，结构变更安全保障。
普通锁（如行锁、表锁等）：直接保护数据并发安全，核心用于事务一致性和高效并发控制。
生产运维中，经常遇到结构变更被阻塞（MDL原因）、大事务竞争表锁/行锁、死锁等问题，了解不同锁机制是优化并发与定位瓶颈的基础。

Q189

Original:
Which three statements are true about data dictionary in MySQL Server?
A. It auto detects when a new schema is moved into datadir.
B. It facilitates fast DDL by using transactional storage.
C. It stores frequently used query plans.
D. It uses the transactional storage engine
E. It is based on SQL standards
F. It provides data to INFORMATION_SCHEMA.

Answer: B D F

中文翻译：

关于 MySQL 服务器中的数据字典，以下哪三项是正确的？
A. 当有新模式移动到数据目录时，它会自动检测。
B. 它通过使用事务存储来加快 DDL 操作。
C. 它存储频繁使用的查询计划。
D. 它使用事务存储引擎。
E. 它基于 SQL 标准。
F. 它为 INFORMATION_SCHEMA 提供数据。

解释：

• 数据字典使用事务存储（如 InnoDB）来支持快速且可靠的 DDL 操作。
• 它确实使用事务存储引擎来管理元数据。
• 数据字典作为元数据存储层，为 INFORMATION_SCHEMA 提供数据。
• 数据字典不自动检测文件系统中直接移动的新模式（A 错误）。
• 查询计划缓存由优化器或缓存管理，不在数据字典中（C 错误）。
• 数据字典不是直接基于 SQL 标准（E 错误）。

Q200

Original:
Which two tasks are performed by the mysql_secure_installation program?
A. It downloads the latest MySQL software over a secure connection and installs it
B. It checks whether the hash value on downloaded software from MySQL repositories matches the official count.
C. It requires setting a password for the root account.
D. It removes anonymous accounts.
E. It checks whether all account passwords match the server's established security level.
F. It properly sets the file permissions and file ownership for MySQL server files.

Answer: C D

中文翻译：

mysql_secure_installation 程序执行了哪两项任务？
A. 它通过安全连接下载并安装最新的 MySQL 软件
B. 它检查从 MySQL 仓库下载的软件的哈希值是否匹配官方计数
C. 它要求为 root 账户设置密码
D. 它删除匿名账户
E. 它检查所有账户密码是否符合服务器建立的安全级别
F. 它正确设置 MySQL 服务器文件的权限和文件所有权

解释：

• mysql_secure_installation 用于初始化 MySQL 安全配置，如设置 root 密码（选项C）和删除匿名用户(选项D)。
• 它不负责软件下载或文件权限管理，也不检查密码强度（虽然有些版本会提示密码强度，但非主要功能）。

mysql_secure_installation

1. 官方原文

文档标题：6.4.2 mysql_secure_installation — Improve MySQL Installation Security
主要说明了 mysql_secure_installation 工具通过一系列交互式步骤提升 MySQL 的安全性，包括 root 账号密码设置、删除匿名账户、移除测试数据库等功能。

2. 中文翻译

概述说明

mysql_secure_installation 工具用于提升 MySQL 数据库初始安装后的安全性。运行该脚本后，可以完成多项推荐的安全措施。

功能点说明

设置 root 账户密码。
移除可以远程访问的 root 账户。
移除匿名用户账户。
删除 test 数据库及以 test_ 开头的数据库权限。

工具使用方式

一般情况下，直接在命令行输入：
mysql_secure_installation
按照提示逐步操作即可。
工具支持密码强度插件（validate_password），未安装时会询问是否安装启用从而校验密码强度。

常用选项参数（含常用中文解释）

--help
显示帮助信息并退出。
--defaults-extra-file=<filename>
指定额外配置文件，优先级高于全局配置文件。
--defaults-file=<filename>
只使用指定的配置文件。
--defaults-group-suffix=<str>
读取配置时增加指定后缀的分组内容。
--host=<hostname> 或 -h <hostname>
指定连接的 MySQL 服务器主机。
--no-defaults
启动时不读取任何配置文件（但 .mylogin.cnf 除外）。
--password=<password> 或 -p <password>
此选项已被忽略，实际登录时仍会提示输入密码。
--port=<port_num> 或 -P <portnum>
指定 TCP/IP 连接使用的端口号。
--print-defaults
显示当前程序读取到的所有选项和配置。
--protocol=<type>
指定连接协议（如 TCP、SOCKET、PIPE、MEMORY）。
--socket={file_name|pipe_name} 或 -S <path>
指定本地连接的 UNIX socket 文件或 Windows 命名管道名称。
以 --ssl 开头的相关参数
用于设定 SSL/TLS 加密连接的密钥与证书选项。
--ssl-fips-mode={OFF|ON|STRICT}
控制是否启用 FIPS 模式，已弃用，未来版本会移除。
--tls-ciphersuites=<list>
指定 TLSv1.3 下允许的加密套件。
--tls-sni-servername=<servername>
指定 TLS SNI 服务器名称扩展。
--tls-version=<list>
允许使用的 TLS 协议版本。
--use-default
非交互方式执行（适合无人值守脚本自动化）。
--user=<username> 或 -u <username>
指定用于连接 MySQL 的账号名称。

3. 相关知识点总结

mysql_secure_installation 是 MySQL 官方推荐的新装数据库后的基础安全加固工具。其核心职责是清理不安全的默认配置。
建议数据库首次安装完务必运行一次该程序，消除常见安全隐患。
几乎所有配置参数均可通过命令行或配置文件指定，能够灵活适应多节点、多环境运维需求。
密码强度检测、SSL/TLS 加密参数亦能一并进行定制配置，进一步提升连接安全性。

参考链接：
官方文档：mysql_secure_installation

Q201

Original:
You must determine if your MySQL server sort_buffer_size parameter setting is appropriate for your workload.
Which two commands will show the relevant systemwide counters?
A) SHOW STATUS;
B) SELECT * FROM performance_schema.global_status;
C) SELECT * FROM performance_schema.session_status;
D) SHOW ENGINE INNODB STATUS;
E) SELECT * FROM information_schema.innodb_metrics;
F) SHOW GLOBAL STATUS;

Answer: B F

中文翻译：

你必须判断 MySQL 服务器的 sort_buffer_size 参数设置是否适合你的工作负载。
以下哪两个命令可以显示相关的系统范围计数器？
A) SHOW STATUS;
B) SELECT * FROM performance_schema.global_status;
C) SELECT * FROM performance_schema.session_status;
D) SHOW ENGINE INNODB STATUS;
E) SELECT * FROM information_schema.innodb_metrics;
F) SHOW GLOBAL STATUS;

解释：

• SHOW STATUS; performance_schema.session_status 提供当前会话的状态计数器，有助于分析排序缓冲区的使用，但是当前会话并非全局，不选。
• SHOW GLOBAL STATUS;SELECT * FROM performance_schema.global_status;提供全局的状态计数器 BF正确。
• SHOW ENGINE INNODB STATUS 和 information_schema.innodb_metrics主要展示 InnoDB 引擎状态侧重于 InnoDB 特定的指标，但不会包含通用的 Sort_merge_passes 或其他排序相关计数器。数器。

MySQL `sort_buffer_size` 参数说明

这是 MySQL 的一个会话级/全局级参数，影响排序操作时的内存缓冲区大小。
关键参数如下：
- 命令行格式：--sort-buffer-size=#
- 系统变量名：sort_buffer_size
- 作用域（Scope）：Global, Session
- 动态修改：支持
- 作用对象：所有排序相关操作，跟存储引擎无关
- 类型：整数（bytes）
- 默认值：262144（256KB）
- 最小值：32768（32KB）
- 最大值（Windows与32位平台）：4294967295（约4GB-1）
- 最大值（64位平台）：18446744073709551615（极大数值，但64位Windows仍为4GB-1）
- 单位：字节（bytes）

1. 作用/含义

sort_buffer_size 是什么？
- 每个需要执行排序的会话都会单独分配一个此大小的缓冲区。
- 该参数与存储引擎无关，是MySQL排序优化的通用参数。
- 必须至少能容纳15个元组(tuple)来完成排序。
- 如果 max_sort_length 设置过大，也需相应增大 sort_buffer_size。
- Sort_merge_passes: 这个计数器表示 MySQL 需要执行多趟合并排序的次数。当需要排序的数据量大于 sort_buffer_size 时，MySQL 会将数据分成块，对每个块进行排序，然后将排序后的块合并。如果 Sort_merge_passes 的值持续很高，这可能表明 sort_buffer_size 太小，导致频繁的磁盘 I/O 和性能下降。理想情况下，此值应尽可能低。

Sort_scan: 这个计数器表示执行的全表扫描（或索引扫描，但主要关注全表扫描）并需要排序的次数。虽然这个值不能直接告诉 sort_buffer_size 是否合适，但它可以帮助了解有多少查询需要排序操作。
通过查询这些状态，用户可以了解排序缓冲区的使用情况和未命中比例，这有助于判断是否需要调整sort_buffer_size以适应当前的工作负载。

2. 调优场景及原则

如果通过 SHOW GLOBAL STATUS 发现 Sort_merge_passes 每秒值很高，就可以考虑适当增大 sort_buffer_size，以优化无法通过SQL优化或索引改进的 ORDER BY / GROUP BY 的性能。
优化器自行评估空间需求，但会根据该上限分配，若全局值过大可能反而让大多数排序查询变慢；
实践建议：只为确有需要的会话单独提高（session级设置），而不是全局调大。
Linux下，推荐不超过256KB或2MB这两个门槛，否则大幅增大会导致分配内存明显变慢；
最佳值需根据真实业务试验、权衡确定。

3. 限制与注意事项

最大建议配置为4GB-1（4294967295），64位Linux平台可更大，但64位Windows始终以4GB-1为上限，多填部分会发出告警。
增大 max_sort_length 可能要求同步增大 sort_buffer_size。
详细影响见官方文档 ORDER BY 优化和临时文件存储相关章节。

Q202

Original:
Which two statements are true about general tablespaces?
A. A new table can be created explicitly in a general tablespace.
B. General tablespaces support temporary tables
C. A general tablespace can have multiple data files.
D. Dropping a table from a general tablespace releases the space back to the operating system.
E. An existing table can be moved into a general tablespace

Answer: A E

中文翻译：

关于通用表空间，以下哪两项是正确的？
A. 可以显式地在通用表空间中创建新表。
B. 通用表空间支持临时表。
C. 通用表空间可以包含多个数据文件。
D. 从通用表空间中删除表会将空间释放回操作系统。
E. 可以将现有表移动到通用表空间中。

解释：

A. 新表可以被显式创建在一个通用表空间中。
- 解析：在创建表时，可以使用 TABLESPACE tablespace_name 明确指定新表属于哪个 general tablespace。此说法正确。（正确）
B. 通用表空间支持临时表
- 解析：通用表空间只支持永久（非临时）表和表分区，不能用于临时表。（错误）
C. 一个通用表空间可以有多个数据文件。
- 解析：目前（MySQL 5.7及以后）一个 general tablespace 只能有一个数据文件，不能有多个数据文件。（错误）
D. 从通用表空间中删除表，会将空间返回给操作系统。
- 解析：删除表后，空间会在内部表空间中标记为可重用，但不会归还给操作系统。除非是独立表空间（.ibd 文件）且文件被drop，否则空间不会回收给操作系统。（错误）
E. 可以将已有表移动到通用表空间。
- 解析：可以使用 ALTER TABLE ... TABLESPACE tablespace_name 将现有表迁移到指定的 general tablespace。此说法正确。（正确）

关于通用表空间（General Tablespaces）

https://dev.mysql.com/doc/refman/8.4/en/general-tablespaces.html

1. 通用表空间能力

通用表空间类似于系统表空间（system tablespace），可以存储多个表的数据（即为共享表空间）。
与每表一个表空间（file-per-table tablespace）相比，通用表空间在元数据管理上有内存优势：多个表集中在少量表空间中，可减少内存消耗。
通用表空间的数据文件可放在MySQL数据目录内或独立的目录，便于性能独立管理、磁盘绑定等。
支持所有表的行存储格式和相关特性。
用户可以通过 TABLESPACE 选项，在创建或修改表时指定表空间。也支持将表在不同类型表空间间移动。

2. 创建通用表空间

使用 CREATE TABLESPACE 语法。可指定数据文件路径和块大小（FILE_BLOCK_SIZE）。例如：
- 在数据目录下：
  CREATE TABLESPACE ts1 ADD DATAFILE 'ts1.ibd' Engine=InnoDB;
- 指定外部目录（需预先告知InnoDB，并重启服务）：
  CREATE TABLESPACE ts1 ADD DATAFILE '/my/tablespace/directory/ts1.ibd' Engine=InnoDB;
如果未指定数据文件名，会自动生成全局唯一的UUID文件名。
ENGINE = InnoDB 必须明确定义，或设置为默认存储引擎。

3. 向通用表空间添加表

创建表或修改表时可使用 TABLESPACE 关键字指定加入某个通用表空间：
- 创建表：CREATE TABLE t1 (c1 INT PRIMARY KEY) TABLESPACE ts1;
- 修改表：ALTER TABLE t2 TABLESPACE ts1;
表分区不能添加到共享表空间（包括系统和通用表空间）。

4. 行格式支持

通用表空间支持所有InnoDB行格式：REDUNDANT、COMPACT、DYNAMIC、COMPRESSED。
但压缩表与非压缩表不能在同一个通用表空间中共存，物理页大小需统一。
若需存放压缩表，创建表空间时必须指定对应压缩页大小的 FILE_BLOCK_SIZE，表的 KEY_BLOCK_SIZE 需与 FILE_BLOCK_SIZE 相对应。例如：
- CREATE TABLESPACE ts2 ADD DATAFILE 'ts2.ibd' FILE_BLOCK_SIZE = 8192 Engine=InnoDB;
- CREATE TABLE t4 (...) TABLESPACE ts2 ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8;
若未指定 FILE_BLOCK_SIZE，则等于 innodb_page_size，只能存储非压缩行格式表。

5. 在表空间间迁移表

使用 ALTER TABLE ... TABLESPACE 迁移表（含全量重建表数据，可能占用双倍空间）：
- 移到已有通用表空间：ALTER TABLE tbl_name TABLESPACE ts1;
- 移到系统表空间：ALTER TABLE tbl_name TABLESPACE innodb_system;
- 移到每表一个表空间：ALTER TABLE tbl_name TABLESPACE innodb_file_per_table;
临时表无法移动到持久化表空间。
DATA DIRECTORY 选项仅对 file-per-table 表空间有效。

6. 重命名通用表空间

用 ALTER TABLESPACE s1 RENAME TO s2; 命令实现，需要 CREATE TABLESPACE 权限。
需要自动提交模式，不能在有表锁操作时执行，会阻塞DDL，DML可并发。

7. 删除通用表空间

用 DROP TABLESPACE，前提是表空间内所有表已被删除。未清空则报错。
删除表空间不会自动删除空间文件，需要手动执行DROP TABLESPACE。
通用表空间不属于任何数据库，DROP DATABASE 只会删除空间内表，不会删除该空间。
类似系统表空间，truncate/drop 表后释放的空间不会归还操作系统，只能被新的InnoDB数据复用。

8. 通用表空间的限制

已有主表空间或file-per-table表空间不能直接转换为通用表空间。
不支持创建临时通用表空间，也不支持存储临时表。
不支持表分区。
表空间文件 ADD DATAFILE 不能用于主从同机场景，否则两个实例可能创建同名同路径空间文件引起冲突。
仅已知目录才能作为表空间目录（如加入innodb_directories）。
不支持 ALTER TABLE ... DISCARD/IMPORT TABLESPACE 对通用表空间的表。
复制、空间扩容、表空间收缩等方面，通用表空间与file-per-table表空间特性不全等价。

Q203

Original:
Examine this statement, which executes successfully:

mysql> SOURCE /usr/share/mysql-8.0/audit_log_filter_linux_install.sql

You then reconnect to MySQL and execute several queries.

Examine the resulting text content of the /audit.log file:

<?xml version="1.0" encoding="UTF-8"?>
<AUDIT>
<AUDIT_RECORD>
<TIMESTAMP>2019-12-12T04:36:39 UTC</TIMESTAMP>
<RECORD_ID>1</RECORD_ID>
<NAME>Audit</NAME>
<SERVER_ID>1</SERVER_ID>
<VERSION>1</VERSION>
<STARTUP_OPTIONS>/usr/sbin/mysqld</STARTUP_OPTIONS>
<OS_VERSION>x86_64-Linux</OS_VERSION>
<MYSQL_VERSION>8.0.18-commercial</MYSQL_VERSION>
</AUDIT_RECORD>
</AUDIT>

Why does the file contain no visible statement events?

A. You must use the audit_log_filter_set_filter() and audit_log_filter_set_user() functions to specify what to log
B. You must add audit_log=ON to the MySQL configuration file and restart MySQL to log statements.
C. You must use the audit_log_read() and audit_log_read_bookmark() functions to read the statement events.
D. You must wait for the audit log buffer to fill before it will flush to disk.

Answer: A

中文翻译：

检查该语句，它成功执行了：

mysql> SOURCE /usr/share/mysql-8.0/audit_log_filter_linux_install.sql

然后你重新连接到 MySQL 并执行了几条查询语句。

查看 /audit.log 文件中的文本内容：

<?xml version="1.0" encoding="UTF-8"?>
<AUDIT>
<AUDIT_RECORD>
<TIMESTAMP>2019-12-12T04:36:39 UTC</TIMESTAMP>   <!-- 时间戳：2019-12-12 04:36:39 UTC -->
<RECORD_ID>1</RECORD_ID>                          <!-- 记录编号：1 -->
<NAME>Audit</NAME>                                <!-- 名称：Audit -->
<SERVER_ID>1</SERVER_ID>                          <!-- 服务器编号：1 -->
<VERSION>1</VERSION>                              <!-- 版本：1 -->
<STARTUP_OPTIONS>/usr/sbin/mysqld</STARTUP_OPTIONS> <!-- 启动选项：/usr/sbin/mysqld -->
<OS_VERSION>x86_64-Linux</OS_VERSION>             <!-- 操作系统版本：x86_64-Linux -->
<MYSQL_VERSION>8.0.18-commercial</MYSQL_VERSION>  <!-- MySQL 版本：8.0.18-commercial -->
</AUDIT_RECORD>
</AUDIT>

为什么文件中没有可见的语句事件？
A. 你必须使用 audit_log_filter_set_filter() 和 audit_log_filter_set_user() 函数来指定要记录的内容。
B. 你必须在 MySQL 配置文件中添加 audit_log=ON 并重启 MySQL 才能记录语句。
C. 你必须使用 audit_log_read() 和 audit_log_read_bookmark() 函数来读取语句事件。
D. 你必须等待审计日志缓冲区填满后才会刷新到磁盘。

解释：

• 审计日志插件默认不会记录所有语句事件，需要通过函数 audit_log_filter_set_filter() 和 audit_log_filter_set_user() 明确指定哪些事件和用户需要被记录（选项 A 正确）。
• --audit-log 是 MySQL 审计日志插件的启动项，只影响插件如何加载，和审计日志“内容是否被记录”无关，重启也没用，B错误
• 选项 C 讲的是读取审计日志的函数，但问题是日志文件没有语句事件，和读取无关。
• 选项 D 不正确，审计日志会周期性刷新，不必等待缓冲区完全填满。

--audit-log[=value] 参数说明

官方文档内容

命令行格式（Command-Line Format）
--audit-log[=value]
类型（Type）
Enumeration（枚举类型）
默认值（Default Value）
ON
有效值（Valid Values）
- ON
- OFF
- FORCE
- FORCE_PLUS_PERMANENT

作用

此选项用于控制服务器在启动时如何加载 audit_log 插件。仅在插件已通过 INSTALL PLUGIN 注册或通过 --plugin-load 或 --plugin-load-add 加载时可用。

详细用法参见官方文档 Section 8.4.5.2（Installing or Uninstalling MySQL Enterprise Audit）。
https://dev.mysql.com/doc/refman/8.0/en/audit-log-reference.html#option_mysqld_audit-log

详细说明与示例

参数值应为插件加载选项中可选的其中一种：
- ON：正常加载插件（默认）
- OFF：不加载插件
- FORCE：强制加载插件
- FORCE_PLUS_PERMANENT：强制加载并且运行期间不可卸载插件

例如：
--audit-log=FORCE_PLUS_PERMANENT
表示服务器启动时加载 audit_log 插件，并在运行期间不允许卸载该插件。

8.4.5.7 审计日志过滤（Audit Log Filtering）

https://dev.mysql.com/doc/refman/8.4/en/audit-log-filtering.html

一、简介

1. 审计日志过滤功能简介

审计日志过滤功能依赖于审计日志插件以及相应表和函数。
如果只安装了插件，但未配套安装表和函数，则会进入“传统/遗留过滤模式”（Legacy Mode），该模式已弃用，仅支持简单过滤。
规范的审计日志过滤采用“规则驱动”，可按用户、事件类别、事件子类别、事件字段等维度进行灵活控制。

2. 审计日志过滤的规则（Rule-based Filtering）

过滤规则通过定义“过滤器”（filter）实现，每个过滤器包含一组筛选规则，可设置为包含或排除指定事件，并可阻止（中止）某些操作。
可定义多个过滤器，并将其分配给一个或多个账户。
支持为没有明确分配过滤器的用户设定默认过滤器。
过滤规则可用于实现如异常 SQL 统计等功能。

3. 审计日志过滤的实现方式

通过如下 SQL 函数接口操作过滤器和分配关系（必须拥有 AUDIT_ADMIN 或 SUPER 权限）:
- audit_log_filter_set_filter(): 定义过滤器
- audit_log_filter_remove_filter(): 移除过滤器
- audit_log_filter_set_user(): 对用户启用过滤
- audit_log_filter_remove_user(): 停用用户筛选
- audit_log_filter_flush(): 刷新表变更以生效
过滤器定义和关系数据默认存于 mysql 数据库的 audit_log_filter 表，可通过 SQL 查询。
每个会话当前使用的过滤器 ID 可通过只读变量 audit_log_filter_id 查看。

4. 使用审计日志过滤的注意事项和约束

必须正确安装插件及所需表、函数，否则功能不可用或进入遗留模式。
必须拥有 AUDIT_ADMIN 或 SUPER 权限。
系统支持“豁免终止”权限（AUDIT_ABORT_EXEMPT），防止管理员被误配置阻断，可自动赋予 SYSTEM_USER 账户。

二、总结

审计日志过滤（Audit Log Filtering）是 MySQL 高级企业功能，实现对数据库审计事件的精细化、规则驱动式的日志采集与操作控制。

规则驱动（Rule-based）与“遗留模式（Legacy）”的区别：

规则驱动可灵活基于用户、事件类型、细节字段等多维度进行事件筛选和中止。
遗留模式功能简单，仅可按用户和事件状态过滤。

**过滤器与账户分配机制：
允许为不同用户、组或默认用户分配不同的过滤规则，极大增强安全与合规的策略灵活性。
分配关系和过滤器定义以表结构持久化存储，方便查询和管理。

**权限安全保障：
所有相关操作需管理员权限（AUDIT_ADMIN 或 SUPER）。
提供终止豁免机制（AUDIT_ABORT_EXEMPT），防止误导致关键信息无法被管理员挽救。

**SQL 接口统一管理：
所有过滤器定义、分配、刷新等操作均通过 SQL 逻辑函数完成，既便于集成，也方便审计与自动化管理。

**使用建议和常见陷阱：
一定要完整安装全部组件，包括所有需要的表与函数，不然会退化为弃用的传统模式！
新增、修改、删除表数据后，如未调用 audit_log_filter_flush()，变更不会立即生效。
用户名与主机名比对是区分大小写的（与权限校验略有不同）。

Q204

Original:
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. Using SET PERSIST will update the my.ini file.
D. Editing the file will immediately change the running server configuration.

Answer: B

中文翻译：

在 Windows 平台上，MySQL 服务器运行时，关于 my.ini 文件哪项是正确的？
A. MySQL 服务器不使用 my.ini 配置服务器选项。
B. MySQL 服务器服务仅在启动时读取该选项文件。
C. 使用 SET PERSIST 会更新 my.ini 文件。
D. 编辑该文件会立即更改正在运行的服务器配置。

解析：

• MySQL 服务器启动时读取 my.ini 文件，之后对该文件的修改不会影响当前运行的服务器。
• 使用 SET PERSIST 命令会更新 mysqld-auto.cnf 文件，而非 my.ini。
• 编辑 my.ini 文件不会立即改变运行中的服务器配置，必须重启服务器才会生效。

MySQL 配置文件 my.ini 简介

1. 基本定义

my.ini 是 MySQL 在 Windows 系统下（或部分 Linux 下）的主要配置文件，用于定义数据库服务器的启动参数、运行环境、性能调优、安全配置等。
等价配置文件名为 my.cnf（在 Linux/Unix 下常用）。

2. my.ini 主要作用

控制 MySQL 服务端（mysqld）、客户端（mysql）、备份工具等各组件的行为
设置服务端口、数据路径、字符集、最大连接数、缓存、日志、权限等

3. 常见 my.ini 配置结构

典型 my.ini 文件结构如下（以 MySQL 8 为例）：

# 注释使用 #
[client]
port=3306
default-character-set=utf8mb4

[mysqld]
# 服务端端口和目录
port=3306
basedir="C:/Program Files/MySQL/MySQL Server 8.0/"
datadir="C:/ProgramData/MySQL/MySQL Server 8.0/Data/"
# 最大连接数
max_connections=200
# 字符集
character-set-server=utf8mb4
collation-server=utf8mb4_unicode_ci
# 缓存与队列
innodb_buffer_pool_size=1G
query_cache_size=64M
# 日志
log-error="C:/ProgramData/MySQL/MySQL Server 8.0/Logs/error.log"
slow_query_log=1
slow_query_log_file="C:/ProgramData/MySQL/MySQL Server 8.0/Logs/slow.log"
# 权限
skip-grant-tables=0

[mysql]
default-character-set=utf8mb4

4. 核心参数说明

[client]：客户端（如mysql命令行工具）连接参数
[mysqld]：MySQL 服务器主进程参数，如端口、路径、内存、用户权限等
[mysql]：MySQL 命令行工具自身参数
常用参数举例：

port (端口号)
basedir (MySQL 安装目录)
datadir (数据文件目录)
max_connections (最大并发连接数)
character-set-server (默认字符集)
innodb_buffer_pool_size (InnoDB缓冲区大小)
log-error (错误日志路径)
slow_query_log (开启慢查询日志)
skip-grant-tables (跳过权限表，常用于密碼丢失紧急恢复)

通过 systemd 启动多个 MySQL 服务器时，哪两个是要求？
A. 每个实例必须有唯一的 socket 文件和 TCP/IP 端口。
B. 每个实例必须有唯一的密码。
C. 每个实例需要不同的 server-id。
D. 每个实例必须有唯一的数据目录。
E. 每个实例必须配置唯一的 server-uuid。

解析：

• 多实例必须使用不同的 socket 和端口，避免冲突。
• 每个实例需要独立的数据目录存储文件。
• server-id 只在复制环境必须不同，非必需。
• 密码和 server-uuid 不属于启动多个实例的强制要求。

使用 systemd 配置多 MySQL 实例指南

https://dev.mysql.com/doc/refman/8.0/en/using-systemd.html#systemd-multiple-mysql-instances

核心概念：

利用 Linux 的 systemd 系统和服务管理器原生支持，在同一台机器上运行和管理多个 MySQL 服务实例。这消除了对旧工具 mysqld_multi 的需求。

配置步骤：

修改 MySQL 配置文件 (my.cnf):
在配置文件中为每个实例创建一个专属的配置组。
组名格式：[mysqld@实例名] (必须使用 @ 作为分隔符，这是 systemd 的要求)。
在每个组内定义该实例特定的关键参数：

datadir: 实例的数据目录路径 (必须唯一)

socket: 实例的 socket 文件路径 (必须唯一)

port: 实例监听的端口号 (必须唯一)

log-error: 实例的错误日志文件路径

配置文件路径示例：

RPM 平台 (如 CentOS/RHEL/Fedora):

/etc/my.cnf 或 /etc/mysql/my.cnf

Debian 平台 (如 Ubuntu/Debian):

/etc/mysql/mysql.conf.d/mysqld.cnf

配置示例：

RPM 平台:

[mysqld@replica01]
        datadir=/var/lib/mysql-replica01
        socket=/var/lib/mysql-replica01/mysql.sock
        port=3307
        log-error=/var/log/mysqld-replica01.log

        [mysqld@replica02]
        datadir=/var/lib/mysql-replica02
        socket=/var/lib/mysql-replica02/mysql.sock
        port=3308
        log-error=/var/log/mysqld-replica02.log

Debian 平台:

 [mysqld@replica01]
        datadir=/var/lib/mysql-replica01
        socket=/var/lib/mysql-replica01/mysql.sock
        port=3307
        log-error=/var/log/mysql/replica01.log

        [mysqld@replica02]
        datadir=/var/lib/mysql-replica02
        socket=/var/lib/mysql-replica02/mysql.sock
        port=3308


        log-error=/var/log/mysql/replica02.log

使用 systemd 管理实例：

systemd 会自动使用特制的 template unit file (模板服务单元文件) 来管理多实例：

RPM 平台: mysqld@.service (代替基础的 mysqld.service)

Debian 平台: mysql@.service (代替基础的 mysql.service)

管理命令语法： systemctl [命令] mysqld@实例名 (RPM) 或 systemctl [命令] mysql@实例名 (Debian)

启动实例:

```

systemctl start mysqld@replica01
systemctl start mysqld@replica02


            
设置开机自启:

        systemctl enable mysqld@replica01
        systemctl enable mysqld@replica02


            
检查状态: `systemctl status mysqld@replica01`

停止实例: ```
systemctl stop mysqld@replica01

重启实例: systemctl restart mysqld@replica01

支持通配符: 例如，查看所有以 replica 开头的实例状态：

    `systemctl status 'mysqld@replica*'`

systemd 的工作原理：

当执行 systemctl start mysqld@replica01 时，systemd 利用模板文件 mysqld@.service。

文件中的 %I 或 %i 会被替换成传入的实例名 (如 replica01)。

systemd 最终通过命令 mysqld --defaults-group-suffix=@%I ... 启动 MySQL。

这个 --defaults-group-suffix=@%I 参数是关键，它告诉 MySQL 进程：

加载 [mysqld] 组 (基础配置)。

加载 [server] 组 (基础配置)。

加载匹配实例名的 [mysqld@实例名] 组 (上一步配置的实例专属参数)。

这样，每个实例就能获得其专属的配置（数据目录、端口、socket等）。

重要注意事项：

Debian 平台 - AppArmor 限制：

Debian 系统的 AppArmor 安全模块默认会阻止 MySQL 访问非标准位置（如示例中的 /var/lib/mysql-replica*）。

解决方法：必须手动定制 /etc/apparmor.d/usr.sbin.mysqld 配置文件，添加对新路径的读写权限，或者临时禁用 AppArmor 对 MySQL 的配置（不推荐）。完成后需要重新加载 AppArmor (systemctl reload apparmor)。
Debian 平台 - 卸载/升级问题：

当前 Debian 的 MySQL 软件包卸载或升级脚本无法正确处理通过 mysql@实例名管理的额外实例。

关键操作：在卸载 MySQL 软件包或进行重大升级之前，必须手动停止所有通过这种方式创建的额外实例 (systemctl stop mysql@replica01 等)。否则可能会导致问题。

总结：

Systemd 提供了简洁高效的管理多个 MySQL 实例的方式，主要步骤是修改 my.cnf 定义带 @实例名的配置组，然后使用 systemctl 命令配合实例名进行启停和管理。务必留意不同平台（RPM/Debian）的细微差别，特别是 Debian 上的 AppArmor 和包管理限制。

Q209

Original:
MySQL Enterprise Monitor Query Analyzer is configured to monitor an instance.
Which statement is true?
A. An agent must be installed locally on the instance to use the Query Analyzer.
B. The Query Response Time index (QRTi) is fixed to 100ms and cannot be customized.
C. The slow query log must be enabled on the monitored server to collect information for the Query Analyzer.
D. The Query Analyzer can monitor an unlimited number of normalized statements.
E. Enabling the events_statements_history_long consumer allows tracking the longest running query.

Answer: D

中文翻译：

MySQL Enterprise Monitor 查询分析器配置监控一个实例。
以下哪项说法正确？
A. 必须在实例本地安装代理才能使用查询分析器。
B. 查询响应时间指标（QRTi）固定为100毫秒，无法自定义。
C. 必须启用慢查询日志以收集查询分析器信息。
D. 查询分析器可以监控无限数量的标准化语句。
E. 启用 events_statements_history_long 消费者可以追踪最长运行的查询。

解析：

A. 需在监控实例本地安装代理	❌ 错误	Query Analyzer支持无代理架构（Agentless Architecture），仅需通过IP、账号远程连接即可收集数据，无需本地安装代理。
B. QRTi固定为100ms不可修改	❌ 错误	QRTi（查询响应时间指数）阈值可自定义，默认100ms仅为基础值，用户可调整最佳/可接受/不可接受的时间范围。
C. 必须启用慢查询日志	❌ 错误	Query Analyzer通过Performance Schema（如events_statements_summary_by_digest表）直接获取SQL执行数据，无需启用慢查询日志。
D. 可监控无限量标准化语句	✅ 正确	Query Analyzer对SQL进行标准化处理（去除参数值，保留查询结构），理论上支持无限数量的标准化模式聚合分析，无数量限制。
E. 启用events_statements_history_long可追踪长查询	❌ 错误	该消费者仅提供历史查询详情，非Query Analyzer必需功能；长查询追踪依赖Performance Schema的常规数据收集，无需强制启用此消费者。

📊 第32章 Query Analyzer

https://dev.mysql.com/doc/mysql-monitor/8.0/en/mem-qanal-using.html
功能定义
MySQL Query Analyzer（查询分析器）用于监控在MySQL服务器上执行的SQL语句，并显示每个查询的详细信息、执行次数及执行时间。对于字面值（literal values）不同但结构相似的查询，系统会合并报告以减少冗余。

⚙️ 数据收集机制
数据来源
通过MySQL服务器的Performance Schema语句摘要（Statement Digests）功能收集SQL语句信息（适用于MySQL Server 5.6.14及以上版本）。
代理支持
数据可直接从MySQL服务器获取，无需额外配置，但需通过MySQL Enterprise Monitor Agent（MySQL企业监控代理）实现数据采集。
注：具体用户界面操作详见第32.3节“Query Analyzer用户界面”。

🔍 数据分析与应用
查询监控：查看并追踪查询的执行统计信息（如执行次数、耗时分布）。
数据筛选：支持对查询结果进行过滤和钻取分析（drill down）。
性能关联：将查询执行情况与服务器状态图（如CPU、内存使用率）进行关联分析，定位性能瓶颈。
注：关于Query Analyzer数据的查看、过滤及报告功能，详见第32.3节“Query Analyzer用户界面”。

💎 核心价值
效率提升：自动合并相似查询，避免重复分析。
开箱即用：依赖Performance Schema原生能力，无需代码侵入。
深度诊断：通过执行统计与服务器指标的联动，快速定位性能问题根源。

Q210

Original:
Which two methods can be used to determine whether a query uses the hash join algorithm?
A. EXPLAIN FORMAT=TREE
B. EXPLAIN FORMAT=JSON
C. EXPLAIN ANALYZE
D. EXPLAIN FORMAT=TRADITIONAL
E. EXPLAIN without any formatting argument

Answer: A C

中文翻译：

哪两种方法可以判断查询是否使用了哈希连接算法？
A. EXPLAIN FORMAT=TREE
B. EXPLAIN FORMAT=JSON
C. EXPLAIN ANALYZE
D. EXPLAIN FORMAT=TRADITIONAL
E. 不带格式参数的 EXPLAIN

解析：

关联知识点 Q80
可通过 EXPLAIN 、EXPLAIN FORMAT=TREE、EXPLAIN ANALYZE 查看具体某条 SQL 是否用到了 Hash Join，
在MySQL 8.0.20之前，EXPLAIN必须包含FORMAT=TREE选项才能看见hash join
ACE都可以，但是为了保险选择AC

Q211

Original:
Which two statements are true about using backups of the binary log?
A. Multiple binary logs can be used to restore data.
B. They allow for point-in-time recovery of the data.
C. Binary logs can always be used to unapply unwanted schema changes.
D. Binary logs are relatively small, and therefore, excellent for long-term storage and disaster recovery.
E. Multiple binary logs can be applied in parallel for faster data restoration.
Answer: A B
中文翻译：
关于使用二进制日志备份，哪两项说法正确？
A. 可以使用多个二进制日志恢复数据。
B. 允许进行数据的时间点恢复。
C. 二进制日志总是可以用来撤销不需要的模式更改。
D. 二进制日志体积较小，非常适合长期存储和灾难恢复。
E. 可以并行应用多个二进制日志以加快恢复速度。

解析：

• 恢复数据时通常需要应用多个连续的二进制日志。
• 二进制日志支持基于时间点的恢复。
• 二进制日志不能用来撤销操作，只能重放。
• 二进制日志通常比较大，不适合长期存储。
• 二进制日志应用是顺序的，不能并行。

Q212

Original:
Which statement is true about cold backups?
A) They are backups taken from snapshots of a running database.
B) They are good to use when many users are online accessing the database.
C) They are good to use if only data structures must be backed up but not log files.
D) They are backups taken from OS copy commands.

Answer: D

中文翻译：

关于冷备份，哪项说法正确？
A) 冷备份是从运行中数据库的快照中获得的备份。
B) 适合在大量用户在线访问数据库时使用。
C) 适合只备份数据结构而不备份日志文件时使用。
D) 冷备份是通过操作系统复制命令拷贝得到的备份。

解析：

• 冷备份是数据库关闭时，通过操作系统文件拷贝获得的备份。
• 运行中快照属于热备份。
• 冷备份适合数据库处于关闭状态，用户不可访问。

Q213

Original:
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.

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------- 1 mysql mysql    3287 Dec 12 07:54 ib_buffer_pool
-rw------- 1 mysql mysql 12582712912 Dec 12 09:50 ibdata1
-rw------- 1 mysql mysql 50331648 Dec 12 09:50 ib_logfile0
-rw------- 1 mysql mysql 50331648 Dec 11 14:05 ib_logfile1
-rw------- 1 mysql mysql 12582912 Dec 12 08:05 ibtmp1
-rw------- 1 mysql mysql 25165824 Dec 12 09:50 mysql.ibd

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

Examine these commands and output:
Which two statements are true?
A. Truncating the transactions table will free up the most disk space.
B. Executing SET GLOBAL innodb_row_format=COMPRESSED and then ALTER TABLE transactions will free up disk space.
C. Truncating the sales and leads tables will free up disk space.
D. Executing ALTER TABLE transactions will enable you to free up disk space.
E. The transactions table was created with innodb_file_per_table=OFF.

Answer: C E

中文翻译：

你的 MySQL 服务器从早期主版本升级。
sales 数据库有三张表，其中 transactions 表有400万行。
你发现数据目录分区磁盘空间不足，开始调查。

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------- 1 mysql mysql    3287 Dec 12 07:54 ib_buffer_pool
-rw------- 1 mysql mysql 12582712912 Dec 12 09:50 ibdata1
-rw------- 1 mysql mysql 50331648 Dec 12 09:50 ib_logfile0
-rw------- 1 mysql mysql 50331648 Dec 11 14:05 ib_logfile1
-rw------- 1 mysql mysql 12582912 Dec 12 08:05 ibtmp1
-rw------- 1 mysql mysql 25165824 Dec 12 09:50 mysql.ibd

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

查看以下命令和输出，哪两项陈述是正确的？
A. 截断 transactions 表将释放最多磁盘空间。
B. 执行 SET GLOBAL innodb_row_format=COMPRESSED，然后 ALTER TABLE transactions 会释放磁盘空间。
C. 截断 sales 和 leads 表将释放磁盘空间。
D. 执行 ALTER TABLE transactions 可以释放磁盘空间。
E. transactions 表是在 innodb_file_per_table=OFF 模式下创建的。

解析：

• 通过 show global variables like 'innodb_file_per_table' 输出可见，当前设置为 ON，但 transactions 表的文件大小并不在单独的 .ibd 文件中，而是存储在共享表空间（如 ibdata1）中，说明该表是在 innodb_file_per_table=OFF 模式下创建的（升级时遗留）。
• 共享表空间无法通过截断单表释放空间，截断 transactions 表不会释放空间。
• sales 和 leads 表有独立的 .ibd 文件，截断它们可以释放对应的磁盘空间。
• 直接执行 ALTER TABLE transactions 如果不指定操作，默认不会释放空间，且修改表格式为压缩格式需要明确执行，且可能不会显著释放空间。

附注：
图片中：
• innodb_file_per_table=ON 表示新创建的表会有独立表空间。
• ibdata1 文件很大，说明旧表（如 transactions）存放在共享表空间中。
• sales.ibd 和 leads.ibd 文件较小，表示这两表有独立表空间。

Q214

Original:
Examine this statement, which executes successfully:

mysql> SOURCE /usr/share/mysql-8.0/audit_log_filter_linux_install.sql

You then reconnect to MySQL and execute several queries.

Examine the resulting text content of the <datadir>/audit.log file:

<?xml version="1.0" encoding="UTF-8"?>
<AUDIT>
  <AUDIT_RECORD>
    <TIMESTAMP>2019-12-12T04:36:39 UTC</TIMESTAMP>
    <RECORD_ID>1_2019-12-12T04:36:39</RECORD_ID>
    <NAME>Audit</NAME>
    <SERVER_ID>1</SERVER_ID>
    <VERSION>1</VERSION>
    <STARTUP_OPTIONS>/usr/sbin/mysqld</STARTUP_OPTIONS>
    <OS_VERSION>x86_64-Linux</OS_VERSION>
    <MYSQL_VERSION>8.0.18-commercial</MYSQL_VERSION>
  </AUDIT_RECORD>
</AUDIT>

Why does the file contain no visible statement events?
A. You must wait for the audit log buffer to fill before it will flush to disk.
B. You must read the audit log statements through the Performance Schema.
C. You must add audit_log = ON to the MySQL configuration file and restart MySQL to log statements.
D. You must use the audit_log_filter_set_filter() and audit_log_filter_set_user() functions to specify what to log.
E. You must use the audit_log_read() and audit_log_read_bookmark() functions to read the statement events.

Answer: D

中文翻译：

请查看此语句，执行成功：

mysql> SOURCE /usr/share/mysql-8.0/audit_log_filter_linux_install.sql

You then reconnect to MySQL and execute several queries.

Examine the resulting text content of the <datadir>/audit.log file:

<?xml version="1.0" encoding="UTF-8"?>
<AUDIT>
  <AUDIT_RECORD>
    <TIMESTAMP>2019-12-12T04:36:39 UTC</TIMESTAMP>
    <RECORD_ID>1_2019-12-12T04:36:39</RECORD_ID>
    <NAME>Audit</NAME>
    <SERVER_ID>1</SERVER_ID>
    <VERSION>1</VERSION>
    <STARTUP_OPTIONS>/usr/sbin/mysqld</STARTUP_OPTIONS>
    <OS_VERSION>x86_64-Linux</OS_VERSION>
    <MYSQL_VERSION>8.0.18-commercial</MYSQL_VERSION>
  </AUDIT_RECORD>
</AUDIT>

为什么文件中没有可见的语句事件？
A. 必须等待审计日志缓冲区填满后才会刷新到磁盘。
B. 必须通过 Performance Schema 读取审计日志语句。
C. 必须在 MySQL 配置文件中添加 audit_log = ON 并重启 MySQL 才能记录语句。
D. 正确，必须使用 audit_log_filter_set_filter() 和 audit_log_filter_set_user() 函数来指定要记录的内容。
E. 必须使用 audit_log_read() 和 audit_log_read_bookmark() 函数来读取语句事件。

解析：
• 审计日志默认不会记录所有语句，必须通过调用 audit_log_filter_set_filter() 和 audit_log_filter_set_user() 明确指定要审计的语句和用户。
• 题中日志文件只包含启动相关信息，没有具体语句事件，说明未配置过滤器来记录具体语句。
• 其他选项不符合题意：
o A 说等待缓冲区填满，通常不会导致完全无语句记录。
o B Performance Schema 并非唯一读取方式。
o C audit_log 插件已启用且文件生成，说明配置已生效。
o E 是读取日志的函数，不影响日志写入。

8.4.5.7 审计日志过滤（Audit Log Filtering）

一、内容

1. 审计日志过滤功能简介

审计日志过滤功能依赖于审计日志插件以及相应表和函数。
如果只安装了插件，但未配套安装表和函数，则会进入“传统/遗留过滤模式”（Legacy Mode），该模式已弃用，仅支持简单过滤。
规范的审计日志过滤采用“规则驱动”，可按用户、事件类别、事件子类别、事件字段等维度进行灵活控制。

2. 审计日志过滤的规则（Rule-based Filtering）

过滤规则通过定义“过滤器”（filter）实现，每个过滤器包含一组筛选规则，可设置为包含或排除指定事件，并可阻止（中止）某些操作。
可定义多个过滤器，并将其分配给一个或多个账户。
支持为没有明确分配过滤器的用户设定默认过滤器。
过滤规则可用于实现如异常 SQL 统计等功能。

3. 审计日志过滤的实现方式

通过如下 SQL 函数接口操作过滤器和分配关系（必须拥有 AUDIT_ADMIN 或 SUPER 权限）:
- audit_log_filter_set_filter(): 定义过滤器
- audit_log_filter_remove_filter(): 移除过滤器
- audit_log_filter_set_user(): 对用户启用过滤
- audit_log_filter_remove_user(): 停用用户筛选
- audit_log_filter_flush(): 刷新表变更以生效
过滤器定义和关系数据默认存于 mysql 数据库的 audit_log_filter 表，可通过 SQL 查询。
每个会话当前使用的过滤器 ID 可通过只读变量 audit_log_filter_id 查看。

4. 使用审计日志过滤的注意事项和约束

必须正确安装插件及所需表、函数，否则功能不可用或进入遗留模式。
必须拥有 AUDIT_ADMIN 或 SUPER 权限。
系统支持“豁免终止”权限（AUDIT_ABORT_EXEMPT），防止管理员被误配置阻断，可自动赋予 SYSTEM_USER 账户。

二、相关知识点总结

审计日志过滤（Audit Log Filtering）是 MySQL 高级企业功能，实现对数据库审计事件的精细化、规则驱动式的日志采集与操作控制。

规则驱动（Rule-based）与“遗留模式（Legacy）”的区别：

规则驱动可灵活基于用户、事件类型、细节字段等多维度进行事件筛选和中止。

**遗留模式功能简单，仅可按用户和事件状态过滤。

**过滤器与账户分配机制：

允许为不同用户、组或默认用户分配不同的过滤规则，极大增强安全与合规的策略灵活性。
分配关系和过滤器定义以表结构持久化存储，方便查询和管理。

**权限安全保障：

所有相关操作需管理员权限（AUDIT_ADMIN 或 SUPER）。
提供终止豁免机制（AUDIT_ABORT_EXEMPT），防止误导致关键信息无法被管理员挽救。

**SQL 接口统一管理：

所有过滤器定义、分配、刷新等操作均通过 SQL 逻辑函数完成，既便于集成，也方便审计与自动化管理。

**使用建议和常见陷阱：

一定要完整安装全部组件，包括所有需要的表与函数，不然会退化为弃用的传统模式！
新增、修改、删除表数据后，如未调用 audit_log_filter_flush()，变更不会立即生效。
用户名与主机名比对是区分大小写的（与权限校验略有不同）。

Q215

英文原题

You are investigating performance problems in a MySQL database where all data fits in memory. You determine that SELECTs from one table are the main cause for poor response times. Which two actions are likely to fix the problem?

A) Convert the table to use a non-transactional storage engine.
B) Investigate InnoDB mutexes on slow queries and adjust innodb_lock_wait_timeout accordingly.
C) Minimize current operating system activity.
D) Alter the table to use column definitions with a smaller storage footprint.
E) Create suitable table indexes that target the slow queries

题目翻译

你正在排查一个 MySQL 数据库的性能问题（所有数据都能放入内存）。你发现某个表上的 SELECT 查询是导致响应变慢的主要原因。下列哪两项行动最有可能解决这个问题？

选项解释

A. 把表转换为非事务型存储引擎。
- 通常这不会直接解决 SELECT 查询慢的问题，而且会丢失事务、并发等数据库特性。
B. 检查慢查询对应的 InnoDB mutex，并调整 innodb_lock_wait_timeout 参数。
- 该参数主要影响锁等待，SELECT 查询一般不会出现长时间锁等待（除非有大量写入冲突），这并不是优化 SELECT 性能的核心方法。
C. 最小化当前操作系统活动。
- 系统总体负载越低当然会有利于数据库性能，但如果所有数据都在内存，且系统负载不是瓶颈，这并不是针对 SELECT 慢的直接优化手段。
D. 修改表结构，使用更节省空间的列定义。
- 正确。更小的行尺寸可以提升在内存中的缓存命中率和数据处理效率，减少 CPU 与内存带宽消耗，对 SELECT 性能有提升。
E. 针对慢查询创建合适的表索引。
- 正确。缺失索引往往是 SELECT 查询慢的最常见原因，创建合适的索引能极大提高检索效率。

正确答案

D) Alter the table to use column definitions with a smaller storage footprint.
E) Create suitable table indexes that target the slow queries

sekkoo

（精解版）MySQL8.0 OCP (1Z0-908) 练习题

版权、使用条款与免责声明

Q1

中文翻译

解析

从命令行区分 MySQL 备份是热备份还是冷备份

热备份（Hot Backup）

冷备份（Cold Backup）

总结判断方法

Q2

中文翻译

解析

复制失败的根本原因：主库日志缺失导致从库无法获取所需事务

为什么从库不能简单复制 10-50？

1. GTID（全局事务标识符）概念

2. GTID 集合（Sets）

3. 主从复制中的 GTID 关系

Q3

中文翻译

解析

MySQL 认证插件及明文客户端插件需求

1. 认证插件概述

2. 各认证插件详细介绍及明文客户端插件需求

3. 明文客户端插件的作用

4. 认证插件工作流程示例

5. 配置建议

Q4

中文翻译

解析

Q5

Question (English)

中文翻译

解析

1. 命令及输出含义

2. MySQL 8 磁盘临时表存储机制

3. 临时表类型

4. 临时表存储位置及引擎

5. 选项分析

6. 相关变量说明

总结

Q6

Question (English)

中文翻译

解析

1. MySQL 服务器面临的网络攻击风险

2. 选项分析

3. 推荐的防护措施

3.1 使用防火墙保护数据库服务器（选项 B）

3.2 限制连接来源（选项 E）

4. 其他安全建议

5. 不推荐措施

总结

Q7

Question (English)

中文翻译

解析

选项分析

MySQL 初始化命令详解

1. mysqld --initialize

2. mysqld --initialize-insecure

其他相关知识点

安全建议

推荐操作流程（安全起见）

参考命令示例

Q8

Question (English)

中文翻译

解析

1. mysqldump 工具简介

2. 关键参数说明

3. mysqldump 导出内容详解

4. 其他相关知识点

5. 小结

Q9

Question (English)

中文翻译

解析

MySQL 连接控制插件相关知识点

推荐操作

1. `mysqld --initialize`

2. `mysqld --initialize-insecure`