题目65
Choose two.
Which two are characteristics of snapshot-based backups?
□ A) The frozen file system can be cloned to another virtual machine immediately into active service.
□ B) There is no need for InnoDB tables to perform its own recovery when restoring from the snapshot backup.
□ C) Snapshot-based backups greatly reduce time during which the database and applications are unavailable.
□ D) A separate physical copy must be made before releasing the snapshot backup.
□ E) Snapshot backups can be used only in virtual machines.
翻译
选择两项。
基于快照的备份有哪两个特征？
□ A) 冻结的文件系统可立即克隆到另一台虚拟机并投入 active 服务。
□ B) 从快照备份恢复时，InnoDB 表无需自行执行恢复操作。
□ C) 基于快照的备份可大幅减少数据库和应用不可用的时间。
□ D) 释放快照备份前，必须制作单独的物理副本。
□ E) 快照备份仅可在虚拟机中使用。
解析和答案
- 选项A：快照备份的冻结文件系统克隆后，通常需进行恢复等操作才能投入服务，不是“立即”可用，A错误。
- 选项B：InnoDB 表从快照恢复时，可能仍需进行崩溃恢复等操作（如回滚未提交事务 ），B错误。
- 选项C：快照备份通过快速捕获状态，减少了数据库和应用因备份而暂停的时间，C正确。
- 选项D：为避免快照占用源存储且保障数据可用性，释放快照前需制作物理副本，D正确。
- 选项E：快照备份不仅可在虚拟机中使用，物理机等环境也可，E错误。
所以答案是C、D。
知识点总结
- 快照备份特性：理解基于快照备份的核心特点，它能快速获取数据状态，减少备份窗口（即数据库和应用不可用时间 ），但恢复或使用时可能需额外步骤（如制作物理副本、InnoDB 恢复 ）。掌握这些特性，有助于在备份策略选择中，根据业务对停机时间、恢复复杂度的要求，合理采用快照备份方式，平衡备份效率和恢复可行性。
- 备份策略选择：在实际数据库运维中，快照备份是一种高效的备份手段，但也有其适用场景和限制。知晓其减少停机时间的优势，以及需制作物理副本等要求，能够结合业务需求（如高可用性、快速恢复 ）和系统环境（物理机、虚拟机 ），选择合适的备份策略，保障数据安全和业务连续性。
题目66
Choose two.
Examine this SQL statement:
mysql> GRANT r_read@localhost TO mark WITH ADMIN OPTION;
Which two are true?
□ A) Mark can grant the privileges assigned to the r_read@localhost role to another user.
□ B) Mark can grant the r_read@localhost role to another user.
□ C) ADMIN OPTION causes the role to be activated by default.
□ D) Mark must connect from localhost to activate the r_read@localhost role.
□ E) Mark can revoke the r_read@localhost role from another role.
□ F) ADMIN OPTION allows Mark to drop the role.
翻译
选择两项。
查看以下 SQL 语句：
mysql> GRANT r_read@localhost TO mark WITH ADMIN OPTION;
以下哪两项是正确的？
□ A) Mark 可以将分配给 r_read@localhost 角色的权限授予另一个用户。
□ B) Mark 可以将 r_read@localhost 角色授予另一个用户。
□ C) ADMIN OPTION 会使角色默认被激活。
□ D) Mark 必须从 localhost 连接才能激活 r_read@localhost 角色。
□ E) Mark 可以从另一个角色中撤销 r_read@localhost 角色。
□ F) ADMIN OPTION 允许 Mark 删除该角色。
解析和答案
- 选项A：
WITH ADMIN OPTION是针对角色授予的权限，不是直接授予角色的权限给其他用户，A错误。 - 选项B：因为授予时带
WITH ADMIN OPTION，所以 Mark 可以将r_read@localhost角色授予其他用户，B正确。 - 选项C：
ADMIN OPTION与角色是否默认激活无关，C错误。 - 选项D：角色激活与连接主机无关（这里角色
r_read@localhost是角色名，不是连接限制 ），D错误。 - 选项E：由于有
ADMIN OPTION，Mark 可以从其他角色中撤销r_read@localhost角色，E正确。 - 选项F：
ADMIN OPTION不允许 Mark 删除角色，删除角色用DROP ROLE语句，F错误。
所以答案是B、E。
知识点总结
- MySQL角色授权（WITH ADMIN OPTION）：理解
GRANT... WITH ADMIN OPTION在角色授权中的作用，即被授权用户可以将该角色再授予其他用户或从其他角色中撤销。掌握该选项对角色授权流程的影响，能够正确使用该选项进行角色的委派管理，同时明确其与权限授予、角色删除等操作的区别，保障数据库角色和权限管理的准确性。 - 数据库角色与权限管理：深入了解 MySQL 中角色和权限的授予、撤销机制，角色作为权限集合的载体，通过
GRANT语句进行分配，WITH ADMIN OPTION扩展了角色委派的能力。在实际应用中，合理运用这些机制构建灵活且安全的权限体系，既要满足用户间的权限委派需求，又要避免权限滥用风险。
题目67
Choose two.
Which two commands will display indexes on the parts table in the manufacturing schema?
□ A) EXPLAIN SELECT INDEXES FROM manufacturing.parts;
□ B) SELECT * FROM information_schema.statistics WHERE table_schema=‘manufacturing’ AND TABLE_NAME=‘parts’;
□ C) DESCRIBE manufacturing.parts;
□ D) SHOW INDEXES FROM manufacturing.parts;
□ E) SELECT * FROM information_schema.COLUMN_STATISTICS;
翻译
选择两项。
哪两个命令会显示 manufacturing 模式下 parts 表的索引？
□ A) EXPLAIN SELECT INDEXES FROM manufacturing.parts;
□ B) SELECT * FROM information_schema.statistics WHERE table_schema=‘manufacturing’ AND TABLE_NAME=‘parts’;
□ C) DESCRIBE manufacturing.parts;
□ D) SHOW INDEXES FROM manufacturing.parts;
□ E) SELECT * FROM information_schema.COLUMN_STATISTICS;
解析和答案
- 选项A：
EXPLAIN用于查看查询执行计划，不是用于显示表索引，且语法错误（SELECT INDEXES不是有效语法 ），A错误。 - 选项B：
information_schema.statistics表存储了表的索引等统计信息，通过指定table_schema和TABLE_NAME可查询parts表的索引信息，B正确。 - 选项C：
DESCRIBE主要用于显示表的列结构信息，不显示索引详情，C错误。 - 选项D：
SHOW INDEXES FROM是 MySQL 中用于显示表索引信息的直接命令，D正确。 - 选项E：
information_schema.COLUMN_STATISTICS表主要存储列的统计信息，不是索引信息，E错误。
所以答案是B、D。
知识点总结
- MySQL索引查看方法：掌握查看表索引的不同方法，包括使用
SHOW INDEXES FROM直接命令，以及从information_schema.statistics系统表查询。理解不同命令和系统表的作用，能够根据需求（如脚本化查询、详细索引信息查看 ）选择合适的方式查看索引，辅助数据库优化和管理。 - 系统表与元数据查询：熟悉
information_schema中相关系统表（如statistics）存储的元数据内容，了解如何通过查询系统表获取数据库对象（如表、索引 ）的信息。这对于自动化运维、数据字典构建等场景非常重要，能够灵活运用系统表进行元数据检索和分析。
题目68
Choose the best answer.
You reconfigure and start a slave that was not replicating for several days.
The configuration file and CHANGE MASTER command are correct.
Examine the GTID information from both master and slave:
Master:
gtids_executed: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-321,bbbbbbbb-bbbbbbbb-bbbb-bbbbbbbbbbbb:1-50,cccccccc-cccc-cccc-cccc-cccccccccccc:1234-1237
gtids_purged: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-100,bbbbbbbb-bbbbbbbb-bbbb-bbbbbbbbbbbb:1-10,cccccccc-cccc-cccc-cccc-cccccccccccc:1234-1237
Slave:
gtids_executed: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-160,cccccccc-cccc-cccc-cccc-cccccccccccc:1234-1237
gtids_purged: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-70,cccccccc-cccc-cccc-cccc-cccccccccccc:1234-1237
Which statement is true?
○ A) Replication will fail because the master has already purged transactions with cccccccc-cccc-cccc-cccc-cccccccccccc GTIDs.
○ B) Replication will work.
○ C) Replication will fail because the master does not have the required transaction with bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb GTIDs in its binary logs.
○ D) Replication will fail because the slave has purged more aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa transactions than the master.
○ E) Replication will fail because of inconsistent numbers in cccccccc-cccc-cccc-cccc-cccccccccccc GTIDs.
翻译
选择最佳答案。
你重新配置并启动了一个已有数天未进行复制的从库。
配置文件和 CHANGE MASTER 命令均正确。
查看主库和从库的 GTID 信息：
主库：
gtids_executed: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-321,bbbbbbbb-bbbbbbbb-bbbb-bbbbbbbbbbbb:1-50,cccccccc-cccc-cccc-cccc-cccccccccccc:1234-1237
gtids_purged: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-100,bbbbbbbb-bbbbbbbbbbbb-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_purged: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-70,cccccccc-cccc-cccc-cccc-cccccccccccc:1234-1237
以下哪项陈述是正确的？
○ A) 复制将失败，因为主库已清除带有 cccccccc-cccc-cccc-cccc-cccccccccccc GTID 的事务。
○ B) 复制将正常工作。
○ C) 复制将失败，因为主库的二进制日志中没有带有 bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb GTID 的所需事务。
○ D) 复制将失败，因为从库清除的 aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa 事务比主库多。
○ E) 复制将失败，因为 cccccccc-cccc-cccc-cccc-cccccccccccc GTID 中的编号不一致。
解析和答案
- 选项A：主库
gtids_purged中cccccccc-cccc-cccc-cccc-cccccccccccc是1234-1237，从库gtids_executed中该 GTID 也是1234-1237，说明主库未清除这些事务的有效部分，A错误。 - 选项B：从库
gtids_executed中缺少主库的bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb:1-50相关 GTID，主库gtids_purged中该 GTID 已清除到1-10，二进制日志中可能没有从库需要的11-50事务，复制会失败，B错误。 - 选项C：从库没有
bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb相关 GTID 的执行记录，主库gtids_purged显示该 GTID 已清除到1-10，二进制日志中可能没有从库需要的后续事务（11-50），导致复制失败，C正确。 - 选项D：从库
gtids_purged中aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa是1-70，主库是1-100，从库清除的比主库少，D错误。 - 选项E：主库和从库
cccccccc-cccc-cccc-cccc-cccccccccccc的 GTID 范围一致（1234-1237），E错误。
所以答案是C。
知识点总结
- MySQL GTID 复制原理：理解 GTID（全局事务标识符 ）在复制中的作用，
gtids_executed记录已执行的事务，gtids_purged记录已清除的事务。当从库启动复制时，需要主库二进制日志中包含从库缺失的 GTID 事务，否则复制失败。掌握通过分析主从库 GTID 信息判断复制能否正常进行的方法，保障复制拓扑的稳定性。 - 复制故障排查：在处理复制故障时，重点关注 GTID 相关的
gtids_executed和gtids_purged参数，分析主从库事务的一致性。明确主库事务清除（gtids_purged）对从库复制的影响，能够准确判断因 GTID 缺失导致的复制故障，进而采取修复措施（如重新初始化从库、补充缺失事务 ）。
和队列(Queue))
