当前位置： 首页 > news >正文

MySQL 8.0 OCP 1Z0-908 题目解析(37)

news 2025/7/27 11:35:59

题目146

Choose two.

Which two are true about binary logs used in asynchronous replication?

□ A) The master connects to the slave and initiates log transfer.
□ B) They contain events that describe all queries run on the master.
□ C) They contain events that describe database changes on the master.
□ D) They are pulled from the master to the slave.
□ E) They contain events that describe only administrative commands run on the master.

翻译

选择两项。

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

□ A) 主库连接到从库并启动日志传输。
□ B) 它们包含描述主库上运行的所有查询的事件。
□ C) 它们包含描述主库上数据库更改的事件。
□ D) 它们从主库被拉取到从库。
□ E) 它们仅包含描述主库上运行的管理命令的事件。

解析和答案

  • 选项A：在异步复制中，是从库连接到主库并请求二进制日志，而不是主库连接到从库，A错误。
  • 选项B：二进制日志并不包含主库上运行的所有查询，例如一些不需要记录的查询（如 SELECT 语句，除非开启了查询日志等特殊设置）不会被记录，B错误。
  • 选项C：二进制日志主要记录主库上导致数据库更改的事件，如 INSERT、UPDATE、DELETE 等操作，C正确。
  • 选项D：在异步复制中，从库主动从主库拉取二进制日志，D正确。
  • 选项E：二进制日志不仅包含管理命令，还包含数据更改等操作的事件，E错误。

综上，正确答案是 CD。

知识点总结

  • MySQL 异步复制：了解异步复制的工作原理，包括主库和从库之间的连接方式以及二进制日志的传输过程。
  • 二进制日志内容：掌握二进制日志所包含的事件类型，主要是数据库更改的事件，而不是所有查询或仅管理命令。
  • 复制中的日志拉取：理解在异步复制中，从库如何获取主库的二进制日志，即从库主动拉取主库的二进制日志。

题目147

Choose the best answer.

Examine these entries from the general query log:

Time                          Id Command Argument
2019-12-17T00:36:23.389450Z   24 Connect root@localhost on mydb using SSL/TLS
2019-12-17T00:36:23.389754Z   24 Query select @@version_comment limit 1
2019-12-17T00:36:23.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.049458Z   25 Query UPDATE t1 SET val = 10 WHERE ID = 130
2019-12-17T00:36:38.513674Z   24 Query UPDATE t2 SET val = 42 WHERE ID = 3805

All UPDATE statements reference existing rows.
Which describes the outcome of the sequence of statements?

○ A) All statements execute without error.
○ B) A deadlock occurs immediately.
○ C) Connection 25 experiences a lock wait timeout.
○ D) A deadlock occurs after innodb_lock_wait_timeout seconds.
○ E) Connection 24 experiences a lock wait timeout.

翻译

选择最佳答案。

查看通用查询日志中的这些条目：

Time                          Id Command Argument
2019-12-17T00:36:23.389450Z   24 Connect root@localhost on mydb using SSL/TLS
2019-12-17T00:36:23.389754Z   24 Query select @@version_comment limit 1
2019-12-17T00:36:23.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.049458Z   25 Query UPDATE t1 SET val = 10 WHERE ID = 130
2019-12-17T00:36:38.513674Z   24 Query UPDATE t2 SET val = 42 WHERE ID = 3805

所有 UPDATE 语句都引用了现有的行。
哪个描述了这些语句序列的结果？

○ A) 所有语句都无错误地执行。
○ B) 立即发生死锁。
○ C) 连接 25 遇到锁等待超时。
○ D) 在 innodb_lock_wait_timeout 秒后发生死锁。
○ E) 连接 24 遇到锁等待超时。

解析和答案

  • 选项A：由于存在死锁风险，不会所有语句都无错误执行，A错误。
  • 选项B：连接24先更新了t1表的ID=130的行，连接25更新了t2表的ID=3805的行，然后连接25要更新t1表的ID=130的行（此时被连接24的事务锁定 ），连接24要更新t2表的ID=3805的行（此时被连接25的事务锁定 ），这种循环等待会立即导致死锁，B正确。
  • 选项C：不是连接25单独遇到锁等待超时，而是死锁，C错误。
  • 选项D：死锁是立即发生的，不是等待 innodb_lock_wait_timeout 秒后，D错误。
  • 选项E：不是连接24单独遇到锁等待超时，而是死锁，E错误。

所以答案是B。

知识点总结

  • 死锁概念：了解死锁的定义，即两个或多个事务在执行过程中，因争夺资源而造成的一种互相等待的现象，若无外力作用，它们都将无法推进下去。
  • 死锁产生条件：掌握死锁产生的四个必要条件，包括互斥条件（资源不能被共享，只能由一个进程使用 ）、请求与保持条件（进程已获得资源，又对其他资源发出请求 ）、不剥夺条件（进程已获得的资源，在未使用完之前，不能被剥夺 ）、循环等待条件（若干进程之间形成一种头尾相接的循环等待资源关系 ）。
  • InnoDB死锁检测：清楚 InnoDB 存储引擎会自动检测死锁，当检测到死锁时，会回滚其中一个事务，以打破死锁。
  • 事务与锁：明白在 InnoDB 中，事务在执行 UPDATE 等操作时会对相关的行加锁，不同的事务对同一行的操作会导致锁竞争，从而可能引发死锁。
  • 死锁处理：知道当发生死锁时，MySQL 会自动选择一个事务进行回滚，通常是回滚拥有最少行级锁的事务，以解决死锁问题。
  • 锁等待超时：了解 innodb_lock_wait_timeout 参数的作用，它用于设置事务等待行锁的超时时间，当事务等待锁的时间超过该值时，会发生锁等待超时错误，而不是死锁。
  • 死锁与锁等待超时区别：区分死锁和锁等待超时的不同，死锁是两个或多个事务互相等待对方的锁，而锁等待超时是一个事务等待另一个事务的锁超过了指定的时间。
  • 事务隔离级别影响：明白不同的事务隔离级别（如 READ COMMITTED、REPEATABLE READ ）可能会影响死锁的发生概率和处理方式，REPEATABLE READ 是 InnoDB 的默认隔离级别，在该级别下可能更容易发生死锁。
  • 死锁预防与避免：掌握一些预防和避免死锁的方法，如按相同的顺序访问表和行、避免在事务中持有锁的时间过长、使用更短的事务等。
  • 日志分析：能够通过分析通用查询日志（general query log）等日志文件，识别事务的执行顺序和锁的竞争情况，从而判断是否存在死锁风险以及死锁发生的原因。

题目148

Choose the best answer.

Examine this partial output for InnoDB Cluster status:

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

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

○ A) It can rejoin the cluster by using the command cluster.addInstance(‘@host3:3377’).
○ B) It has been expelled from the cluster because of a transaction error.
○ C) It can be recovered from a donor instance on host3 by cloning using the command cluster.rejoinInstance(‘@host3:3377’).
○ D) It has been removed from the cluster by using the command STOP GROUP_REPLICATION;.
○ E) It can rejoin the cluster by using the command dba.rebootClusterFromCompleteOutage().

翻译

选择最佳答案。

查看 InnoDB Cluster 状态的部分输出：\

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

哪条语句解释了部署在 host2 上的实例的状态？

○ A) 它可以通过使用命令 cluster.addInstance(‘@host3:3377’) 重新加入集群。
○ B) 由于事务错误，它已被驱逐出集群。
○ C) 它可以通过使用命令 cluster.rejoinInstance(‘@host3:3377’) 从 host3 上的捐赠者实例克隆来恢复。
○ D) 它已通过使用命令 STOP GROUP_REPLICATION; 从集群中移除。
○ E) 它可以通过使用命令 dba.rebootClusterFromCompleteOutage() 重新加入集群。

解析和答案

  • 选项A：cluster.addInstance 用于添加新实例，而不是让缺失的实例重新加入，A错误。
  • 选项B：状态为 (MISSING) 不一定是因为事务错误，B错误。
  • 选项C：当实例状态为 (MISSING) 时，可以使用 cluster.rejoinInstance 命令从在线的捐赠者实例（如 host3 ）克隆数据来恢复，C正确。
  • 选项D：STOP GROUP_REPLICATION 是停止组复制，不是移除实例，D错误。
  • 选项E：dba.rebootClusterFromCompleteOutage 用于完全 outage 后的集群重启，不是针对单个缺失实例，E错误。

所以答案是C。

知识点总结

  • InnoDB Cluster 实例状态：了解 InnoDB Cluster 中实例的不同状态，如 ONLINE、(MISSING) 等，以及每种状态的含义和处理方法。
  • 实例恢复命令：掌握用于恢复缺失实例的命令，如 cluster.rejoinInstance，该命令可以从在线的捐赠者实例克隆数据来恢复缺失的实例。
  • 集群管理操作：清楚不同的集群管理命令的作用，如 cluster.addInstance（添加新实例 ）、cluster.rejoinInstance（恢复缺失实例 ）、dba.rebootClusterFromCompleteOutage（完全 outage 后的集群重启 ）等，以便在不同情况下选择正确的命令进行操作。

题目149

Choose the best answer.

MySQL Enterprise Monitor Query Analyzer is configured to monitor an instance.

Which statement is true?

○ A) The Query Response Time index (QRTI) is fixed to 100ms and cannot be customized.
○ B) Enabling the events_statements_history_long consumer allows tracking the longest running query.
○ C) An agent must be installed locally on the instance to use the Query Analyzer.
○ D) The Query Analyzer can monitor an unlimited number of normalized statements.
○ E) The slow query log must be enabled on the monitored server to collect information for the Query Analyzer.

翻译

选择最佳答案。

MySQL Enterprise Monitor Query Analyzer 已配置为监控一个实例。

哪个陈述是正确的？

○ A) 查询响应时间指数（QRTI）固定为 100ms，无法自定义。
○ B) 启用 events_statements_history_long 消费者允许跟踪运行时间最长的查询。
○ C) 必须在实例本地安装代理才能使用 Query Analyzer。
○ D) Query Analyzer 可以监控无限数量的规范化语句。
○ E) 必须在被监控的服务器上启用慢查询日志才能为 Query Analyzer 收集信息。

解析和答案

  • 选项A：查询响应时间指数（QRTI）是可以自定义的，不是固定为 100ms，A错误。
  • 选项B：events_statements_history_long 主要用于记录语句历史，不一定能直接跟踪运行时间最长的查询，B错误。
  • 选项C：MySQL Enterprise Monitor Query Analyzer 不需要在实例本地安装代理，C错误。
  • 选项D：Query Analyzer 可以监控无限数量的规范化语句，D正确。
  • 选项E：虽然慢查询日志可以提供信息，但 Query Analyzer 不一定依赖慢查询日志，还可以通过其他方式收集信息，E错误。

综上，正确答案是 D。

知识点总结

  • MySQL Enterprise Monitor Query Analyzer：了解 MySQL Enterprise Monitor Query Analyzer 的功能和特点，包括其对语句的监控能力。
  • 查询响应时间指数（QRTI）：掌握 QRTI 的作用和可配置性，以及如何根据实际需求进行调整。
  • 监控代理与日志：理解 Query Analyzer 与监控代理、慢查询日志等之间的关系，以及它们在监控过程中的作用。

题目150

Choose two.

Examine this query and its output:

mysql> select * from sys.user_summary_by_statement_type where statement in ('select', 'insert', 'Quit');
+------+----------+---------+----------------+-------------+-------------+-------------+--------------+--------------+-----------+
| user | statement| total   | total_latency  | max_latency | lock_latency| rows_sent   | rows_examined| rows_affected| full_scans|
+------+----------+---------+----------------+-------------+-------------+-------------+--------------+--------------+-----------+
| app  | select   | 919866  | 2.41 h         | 330.01 ms   | 1.52 m      | 542614816   | 542614816    | 0            | 919958    |
| app  | insert   | 923070  | 1.66 h         | 287.41 ms   | 1.65 m      | 0           | 0            | 923026       | 0         |
| app  | Quit     | 679892  | 9.54 s         | 170.97 ms   | 0 ps        | 0           | 0            | 0            | 0         |
| bob  | select   | 344964  | 53.61 m        | 328.42 ms   | 34.51 s     | 203509545   | 203509542    | 0            | 344847    |
| bob  | insert   | 346159  | 37.94 m        | 235.77 ms   | 36.94 s     | 0           | 0            | 346159       | 0         |
| bob  | Quit     | 254971  | 3.65 s         | 69.91 ms    | 0 ps        | 0           | 0            | 0            | 0         |
| root | select   | 230621  | 36.88 m        | 21.47 s     | 23.81 s     | 135639074   | 135644067    | 0            | 230595    |
| root | insert   | 231585  | 25.86 m        | 364.22 ms   | 31.45 s     | 0           | 0            | 4150423      | 0         |
| root | Quit     | 170363  | 2.24 s         | 130.14 ms   | 0 ps        | 0           | 0            | 0            | 0         |
+------+----------+---------+----------------+-------------+-------------+-------------+--------------+--------------+-----------+
9 rows in set (0.00 sec)

Which two statements are true?

□ A) User bob had a significantly higher ratio of SELECT + INSERT statements to quit than both app and root users.
□ B) User bob had the largest total time waiting for locks.
□ C) The app user had the highest total number of rows read from storage engines.
□ D) The root user had the largest number of modified rows for a SELECT statement.
□ E) The root user had the largest single wait time.

翻译

选择两个答案。

查看此查询及其输出：

mysql> select * from sys.user_summary_by_statement_type where statement in ('select', 'insert', 'Quit');
+------+----------+---------+----------------+-------------+-------------+-------------+--------------+--------------+-----------+
| user | statement| total   | total_latency  | max_latency | lock_latency| rows_sent   | rows_examined| rows_affected| full_scans|
+------+----------+---------+----------------+-------------+-------------+-------------+--------------+--------------+-----------+
| app  | select   | 919866  | 2.41 h         | 330.01 ms   | 1.52 m      | 542614816   | 542614816    | 0            | 919958    |
| app  | insert   | 923070  | 1.66 h         | 287.41 ms   | 1.65 m      | 0           | 0            | 923026       | 0         |
| app  | Quit     | 679892  | 9.54 s         | 170.97 ms   | 0 ps        | 0           | 0            | 0            | 0         |
| bob  | select   | 344964  | 53.61 m        | 328.42 ms   | 34.51 s     | 203509545   | 203509542    | 0            | 344847    |
| bob  | insert   | 346159  | 37.94 m        | 235.77 ms   | 36.94 s     | 0           | 0            | 346159       | 0         |
| bob  | Quit     | 254971  | 3.65 s         | 69.91 ms    | 0 ps        | 0           | 0            | 0            | 0         |
| root | select   | 230621  | 36.88 m        | 21.47 s     | 23.81 s     | 135639074   | 135644067    | 0            | 230595    |
| root | insert   | 231585  | 25.86 m        | 364.22 ms   | 31.45 s     | 0           | 0            | 4150423      | 0         |
| root | Quit     | 170363  | 2.24 s         | 130.14 ms   | 0 ps        | 0           | 0            | 0            | 0         |
+------+----------+---------+----------------+-------------+-------------+-------------+--------------+--------------+-----------+
9 rows in set (0.00 sec)

哪两个陈述是正确的？

□ A) 用户 bob 的 SELECT + INSERT 语句与 Quit 语句的比率明显高于 app 和 root 用户。
□ B) 用户 bob 的总锁等待时间最长。
□ C) app 用户从存储引擎读取的总行数最多。
□ D) root 用户的 SELECT 语句修改的行数最多。
□ E) root 用户的单次等待时间最长。

解析和答案

  • 选项A：计算各用户的 SELECT + INSERT 与 Quit 的比率，app 用户的比率为 (919866 + 923070) / 679892 ≈ 2.71，bob 用户的比率为 (344964 + 346159) / 254971 ≈ 2.70，root 用户的比率为 (230621 + 231585) / 170363 ≈ 2.71，bob 用户的比率并不明显高于其他用户，A错误。
  • 选项B：查看 lock_latency 列，bob 用户的总锁等待时间为 34.51 s + 36.94 s = 71.45 s，app 用户为 1.52 m + 1.65 m = 184.2 s，root 用户为 23.81 s + 31.45 s = 55.26 s，bob 用户的总锁等待时间不是最长，B错误。
  • 选项C：查看 rows_examined 列，app 用户的 rows_examined 为 542614816，是所有用户中最高的，C正确。
  • 选项D：SELECT 语句不会修改行，rows_affected 列对于 SELECT 语句为 0，D错误。
  • 选项E：查看 max_latency 列，root 用户的 max_latency 为 21.47 s，app 用户为 330.01 ms，bob 用户为 328.42 ms，root 用户的单次等待时间最长，E正确。

所以答案是CE。

知识点总结

  • sys 模式视图：sys.user_summary_by_statement_type 视图用于汇总按用户和语句类型分类的语句执行统计信息，包括执行次数、延迟、锁等待时间、处理的行数等。
  • 锁等待时间：lock_latency 列表示该用户在执行该类型语句时的总锁等待时间，通过比较不同用户的锁等待时间可以了解各用户的锁竞争情况。
  • 数据读取量：rows_examined 列表示该用户在执行该类型语句时从存储引擎读取的总行数，该值越高表示数据读取量越大。
  • 单次等待时间：max_latency 列表示该用户在执行该类型语句时的最大单次等待时间，该值可以反映语句执行的最大延迟情况。
http://www.lryc.cn/news/600814.html

相关文章：

  • mysql group by 多个行转换为一个字段
  • 数据结构（4）单链表算法题（上）
  • 图解网络-小林coding笔记（持续更新）
  • 期货资管软件定制开发流程
  • write`系统调用
  • 宝塔面板如何升级OpenSSL
  • 哈尔滨←→南昌的铁路要道
  • IC测试之pogo pin学习与总结-20250726
  • 鲲鹏服务器部署Kafka2.8.1
  • 微服务springcloud http客户端feign
  • 【资讯】2025年软件行业发展趋势：AI驱动变革，云原生与安全成核心
  • 【Spring Cloud】微服务学习
  • LeetCode——1717. 删除子字符串的最大得分
  • 秋招Day20 - 微服务 - 概念
  • 【机器学习深度学习】模型微调：多久才算微调完成？——如何判断微调收敛，何时终止训练
  • 二维数组相关学习
  • 大模型蒸馏(distillation)---从DeepseekR1-1.5B到Qwen-2.5-1.5B蒸馏
  • UniappDay03
  • 【Canvas与旗帜】条纹版大明三辰旗
  • AI是否会终结IT职业？深度剖析IT行业的“涌现”与重构
  • 慧星云新增大模型服务：多款大模型轻松调用
  • C++：STL中vector的使用和模拟实现
  • MySQL的底层原理--InnoDB数据页结构
  • 人大金仓 kingbase 连接数太多, 清理数据库连接数
  • 基于匿名管道的多进程任务池实现与FD泄漏解决方案
  • VUE2 学习笔记7 v-model、过滤器
  • 6.数组和字符串
  • ChatIm项目文件上传与获取
  • 拉普拉斯方程的径向解法
  • opencv学习（图像金字塔）