2026年OracleMySQL数据库管理认证考试真题题库

2026年OracleMySQL数据库管理认证考试真题题库1.以下关于MySQLInnoDB存储引擎中事务隔离级别的描述，哪一项是正确的？A.READUNCOMMITTED级别下，一个事务可以读取到另一个未提交事务修改的数据B.REPEATABLEREAD级别下，会出现幻读现象C.READCOMMITTED级别下，同一事务多次读取同一记录，结果总是一致的D.SERIALIZABLE级别通过多版本并发控制实现，不会加锁答案：A解析：A正确。READUNCOMMITTED是最低的隔离级别，允许“脏读”，即一个事务可以读到另一个未提交事务修改的数据。B错误。在MySQLInnoDB的默认隔离级别REPEATABLEREAD下，通过多版本并发控制（MVCC）和间隙锁（GapLock）机制，可以避免幻读（PhantomRead）现象。C错误。READCOMMITTED隔离级别下，一个事务多次读取同一记录，如果该记录在两次读取之间被其他事务提交修改，则两次读取结果可能不同，即存在“不可重复读”问题。D错误。SERIALIZABLE是最高的隔离级别，它通过强制事务串行执行来实现，通常涉及大量的锁机制（包括行锁、间隙锁等），而不仅仅是依赖MVCC。2.假设有一个用户表`users`，结构如下：```sqlCREATETABLEusers(idINTPRIMARYKEYAUTO_INCREMENT,usernameVARCHAR(50)NOTNULLUNIQUE,emailVARCHAR(100),created_atTIMESTAMPDEFAULTCURRENT_TIMESTAMP,INDEXidx_email(email))ENGINE=InnoDB;```当前表中有大量数据。现需要给`username`字段添加一个前缀索引，仅取前10个字符。以下哪条SQL语句能正确实现且对线上业务影响相对较小？A.`ALTERTABLEusersADDINDEXidx_username_prefix(username(10))USINGBTREE;`B.`CREATEINDEXidx_username_prefixONusers(username(10));`C.`ALTERTABLEusersADDKEYidx_username_prefix(username(10));`D.`以上皆可`答案：D解析：在MySQL中，为字段创建前缀索引的语法是灵活的。A、B、C三种写法都是有效的。A和C使用了`ALTERTABLE...ADDINDEX/KEY`语法，其中`KEY`是`INDEX`的同义词。B使用了`CREATEINDEX`语法，这是标准SQL的写法。三者都会在`users`表的`username`字段上创建一个名为`idx_username_prefix`的前缀索引，只索引该字段的前10个字符。在InnoDB表上创建索引通常涉及表的重建（OnlineDDL特性可能允许部分操作不锁表，但具体取决于MySQL版本和操作类型）。对于大型表，任何添加索引的操作都需要谨慎，应在业务低峰期进行，并评估其对性能的影响。从语法正确性上讲，三者等效。3.观察以下SQL语句：```sqlEXPLAINSELECTFROMordersoEXPLAINSELECTFROMordersoWHEREo.customer_idIN(SELECTidFROMcustomersWHEREcountry='USA')ANDo.order_date>'2025-01-01';```在`orders`表有`(customer_id,order_date)`的复合索引，`customers`表`id`是主键，`country`字段有独立索引。执行计划显示对`orders`表进行了全表扫描。以下哪种优化措施最可能有效提升此查询性能？A.将IN子查询改为EXISTS子查询B.为`orders`表的`order_date`字段添加独立索引C.将IN子查询改为JOIN连接D.为`orders`表添加`(order_date,customer_id)`复合索引答案：C解析：原查询使用IN子查询，可能导致优化器先执行子查询，生成结果集，然后对`orders`表进行全表扫描来匹配`customer_id`。虽然`orders`表有`(customer_id,order_date)`索引，但查询条件`o.order_date>'2025-01-01'`是范围查询，在复合索引中，范围查询列（`order_date`）后面的列（`customer_id`）无法有效使用索引进行检索（最左前缀原则失效的一种情况）。因此，优化器可能认为使用该复合索引效率不高，转而选择全表扫描。C选项，将查询改写为JOIN，通常能让优化器更好地利用索引。例如：```sqlSELECTo.FROMordersoSELECTo.FROMordersoJOINcustomerscONo.customer_id=c.idWHEREc.country='USA'ANDo.order_date>'2025-01-01';```这样，优化器可以选择先通过`customers`表的`country`索引找到符合条件的`id`，再利用`orders`表的`(customer_id,order_date)`索引进行高效的索引查找和范围扫描。这是处理此类关联查询的经典优化手段。A选项，改为EXISTS有时能优化，但原理类似JOIN，且在此场景下JOIN写法更直观，优化器优化路径更清晰。B选项，添加`order_date`独立索引，对以`customer_id`为起点的IN查询优化作用有限。D选项，索引顺序为`(order_date,customer_id)`，对于`WHEREo.order_date>'2025-01-01'ANDo.customer_idIN(...)`这样的条件，`customer_id`的过滤是等值（IN列表），但放在范围列后面，索引效果可能不理想。4.在MySQL8.0中，关于窗口函数`ROW_NUMBER()`,`RANK()`,`DENSE_RANK()`的区别，以下说法错误的是？A.`ROW_NUMBER()`为每一行分配一个唯一的连续整数，排名无重复且无间隔B.`RANK()`排名可能重复，且重复后的下一个排名数字会出现跳跃C.`DENSE_RANK()`排名可能重复，但重复后的下一个排名数字连续不跳跃D.对于完全相同的数据行，`ROW_NUMBER()`会给它们分配相同的排名数字答案：D解析：A正确。`ROW_NUMBER()`函数不考虑值是否相同，严格按照窗口分区和排序顺序为每一行分配一个唯一的序号（1,2,3...）。B正确。`RANK()`函数在值相同时会分配相同的排名，并且会留下空位。例如，分数为100,100,90，则排名为1,1,3。C正确。`DENSE_RANK()`函数在值相同时分配相同排名，但后续排名连续。例如，分数为100,100,90，则排名为1,1,2。D错误。`ROW_NUMBER()`永远不会为不同的行分配相同的数字，即使它们排序依据的字段值完全相同。如果需要为相同值分配相同序号，应使用`RANK()`或`DENSE_RANK()`。5.关于MySQL的二进制日志（BinaryLog）及其格式，以下描述正确的是？A.使用`STATEMENT`格式时，主从库的表结构必须完全一致，否则可能导致复制错误B.`ROW`格式会记录每行数据修改的细节，因此其日志量总是比`STATEMENT`格式大C.`MIXED`格式默认采用`STATEMENT`格式记录，仅在可能引起主从不一致时自动切换为`ROW`格式D.即使启用`ROW`格式，对于`UPDATE`语句，如果未修改任何行，该语句仍会被完整记录到二进制日志中答案：C解析：A错误。`STATEMENT`格式记录的是SQL语句本身。主从库表结构不一致可能导致语句在从库执行失败或产生不同结果，但这并非`STATEMENT`格式独有的绝对要求，而是数据一致性的通用要求。`ROW`格式下，如果列数量不一致，也可能出错。B错误。`ROW`格式记录行变化，对于影响大量行的操作（如`UPDATE`或`DELETE`不带WHERE条件，或修改大量行），其日志量确实可能远大于`STATEMENT`格式。但对于只影响单行或少数行的操作，`ROW`格式的日志量可能与`STATEMENT`格式相差不大，甚至更小（特别是涉及复杂查询时）。因此“总是”一词过于绝对。C正确。`MIXED`格式是`STATEMENT`和`ROW`的混合。MySQL会判断SQL语句是否可能引起主从不一致（例如使用了不确定函数`UUID()`,`RAND()`，或涉及触发器、存储过程等），如果可能，则自动使用`ROW`格式记录，否则使用`STATEMENT`格式。D错误。在`ROW`格式下，如果一条`UPDATE`语句没有找到匹配的行或者没有实际修改任何数据（即使找到匹配行但数据未变），则不会在二进制日志中记录任何事件（对于基于语句的过滤可能记录一个空事务，但不会记录行事件）。这是`ROW`格式的一个优化。6.在配置MySQLGroupReplication（组复制）时，以下哪个参数是确保单主模式下，写操作必须在大多数成员上达成共识的关键配置？A.`group_replication_single_primary_mode`B.`group_replication_enforce_update_everywhere_checks`C.`group_replication_consistency`D.`group_replication_group_name`答案：C解析：A选项`group_replication_single_primary_mode`用于设置组复制模式为单主模式（ON）或多主模式（OFF），它决定是否自动管理主节点选举，但不直接控制写共识的达成机制。B选项`group_replication_enforce_update_everywhere_checks`用于多主模式，检查事务是否能在所有成员上安全执行，与写共识的多数派原则无直接关系。C选项`group_replication_consistency`是控制组复制一致性级别的关键参数。它可以设置为`EVENTUAL`、`BEFORE_ON_PRIMARY_FAILOVER`、`BEFORE`、`AFTER`、`BEFORE_AND_AFTER`等。这个参数影响事务何时提交、是否等待大多数成员应用事务等。例如，设置为`BEFORE`（或更高）时，事务需要在大多数成员上达成共识（即事务日志被复制到多数派）后，才能在原发起者上提交。这是实现数据强一致性和高可用的核心机制。D选项`group_replication_group_name`是组的标识符，与共识机制无关。7.分析以下涉及JSON操作的SQL语句：```sqlSELECTJSON_EXTRACT('{"user":{"name":"Alice","age":30,"hobbies":["reading","cycling"]}}','$.user.hobbies[1]');```该语句的返回结果是什么？A.`"cycling"`B.`cycling`C.`"reading"`D.`NULL`答案：A解析：`JSON_EXTRACT(json_doc,path)`函数从JSON文档中提取由路径表达式指定的值，并以JSON格式返回。路径`.u函数返回的是JSON类型的值，所以结果是带有双引号的JSON字符串字面量`"cycling"`，而不是去掉引号的纯文本`cycling`。如果希望得到无引号的字符串，可以使用`JSON_UNQUOTE(JSON_EXTRACT(...))`或简写函数`JSON_VALUE()`（MySQL8.0.21+）。8.你发现一个关键业务的InnoDB表`transaction_log`查询突然变慢。使用`SHOWPROCESSLIST`发现大量状态为`Waitingfortablemetadatalock`的会话。以下哪项操作最不可能直接导致此类锁等待？A.一个长时间运行的`SELECTFROMtransaction_log`查询A.一个长时间运行的`SELECTFROMtransaction_log`查询B.一个正在执行的`ALTERTABLEtransaction_logADDCOLUMNaudit_flagTINYINT;`C.一个被挂起（未提交）的事务，该事务之前对`transaction_log`表进行过`UPDATE`操作D.另一个会话对`transaction_log`表执行了`FLUSHTABLEStransaction_logWITHREADLOCK;`答案：A解析：元数据锁（MetadataLock，MDL）主要用于保护表结构定义的一致性，防止在查询或事务过程中表结构被修改。B、C、D都是导致MDL等待的常见原因。B：`ALTERTABLE`需要获取表的排他MDL锁，它会阻塞所有后续对该表的MDL请求（包括后续的查询），直到`ALTER`完成。C：一个未提交的事务（即使只是`SELECT`，在RR隔离级别下也会持有MDL读锁）会持有MDL锁。如果该事务之前有写操作，其MDL锁的持有期可能更长，会阻塞像`ALTER`这样的需要排他MDL锁的操作。反过来，一个正在等待的`ALTER`（排他MDL请求）会阻塞后续所有新的MDL读请求（如普通查询），从而导致“雪崩”式的`Waitingfortablemetadatalock`等待。D：`FLUSHTABLES...WITHREADLOCK`会关闭表并重新打开，同时获取全局读锁。这个过程需要获取表的排他MDL锁，因此会阻塞其他所有访问该表的操作。A选项：一个长时间运行的普通`SELECT`查询（在READCOMMITTED或REPEATABLEREAD隔离级别下），在MySQL5.5+（特别是启用MDL后）一般只会在执行开始时短暂获取MDL读锁，然后释放（对于InnoDB，数据一致性由MVCC保证）。它本身通常不会长时间阻塞其他需要MDL锁的操作（如另一个`SELECT`），也不会是`Waitingfortablemetadatalock`状态的直接持有者。它更可能持有的是行锁或造成慢查询，但不会直接导致大量的MDL等待。MDL等待的根源通常是需要排他MDL锁的操作（如DDL）被阻塞，进而阻塞了后续的所有查询。9.在MySQL性能调优中，关于`innodb_buffer_pool_size`的设置，以下哪项建议最合理？A.应设置为服务器物理内存的50%，为操作系统和其他应用留出足够空间B.应设置为服务器物理内存的80%左右，并观察系统是否有足够的剩余内存用于文件缓存等C.应尽可能设置得大，接近服务器物理内存的100%，以确保所有数据都能缓存D.在内存为64GB的专用数据库服务器上，建议设置为48GB答案：B解析：`innodb_buffer_pool_size`是InnoDB存储引擎最重要的缓存池，用于缓存表数据和索引。A（50%）可能过于保守，未能充分利用内存提升数据库性能。B是最通用的建议原则。将大部分可用内存分配给InnoDB缓冲池，但需要为操作系统、其他MySQL进程（如连接线程、排序缓冲区等）、以及可能的文件系统缓存留出一定空间（通常建议留出总内存的20%-25%）。具体的比例需要根据服务器总内存大小、是否专用数据库服务器、以及工作负载来调整。例如，在内存非常大的系统（如512GB以上），分配给缓冲池的比例可以更高（如90%）。C（接近100%）是危险的。操作系统需要内存来管理进程、文件系统缓存（对于MyISAM表或通用文件操作很重要）、以及处理突发需求。分配所有内存可能导致系统开始使用交换分区（swap），严重降低性能甚至导致服务不稳定。D给出了一个具体数值（64GB机器设48GB）。这符合B选项的“80%左右”原则（48/64=75%），是一个合理的经验值，但并非绝对。最佳值需要通过监控（如观察`SHOWENGINEINNODBSTATUS`中的缓冲池命中率、系统剩余内存等）来最终确定。10.使用`mysqldump`进行逻辑备份时，以下哪个选项组合可以确保得到一个一致性的备份，并且备份文件中包含存储过程和函数的定义？A.`--single-transaction--routines`B.`--lock-all-tables--triggers`C.`--master-data=2--events`D.`--quick--add-drop-table`答案：A解析：A正确。`--single-transaction`：对于支持事务的存储引擎（如InnoDB），此选项会在一个单独的事务中导出数据，利用可重复读隔离级别来确保备份数据的一致性，而不需要对表加锁（或只在开始时加一个短暂的锁）。这是对线上业务影响最小的全库一致性备份方法之一。`--routines`：此选项会导出存储过程和函数。B：`--lock-all-tables`会对所有表加读锁，直到备份完成。这能保证一致性，但在备份期间会阻塞所有写操作，对线上业务影响大。`--triggers`选项默认是启用的，它导出触发器，但不包含存储过程。C：`--master-data=2`用于记录二进制日志位置，主要用于搭建复制环境。`--events`用于导出事件调度器的事件。这个组合没有包含保证一致性的选项（如`--single-transaction`或`--lock-all-tables`），也没有包含`--routines`。D：`--quick`用于逐行检索数据，有助于避免大表导出时内存溢出。`--add-drop-table`会在`CREATETABLE`前添加`DROPTABLE`语句。两者均不保证一致性，也不包含存储过程。11.考虑以下SQL查询及其执行计划（部分）：```sqlSELECTe.emp_no,e.first_name,s.salaryFROMemployeeseJOINsalariessONe.emp_no=s.emp_noWHEREe.hire_dateBETWEEN'1990-01-01'AND'1995-12-31'ANDs.salary>60000ANDs.from_date<=CURDATE()ANDs.to_date>=CURDATE();```假设`employees`表在`hire_date`上有索引，`salaries`表在`emp_no`上有主键/外键索引，在`salary`上也有独立索引。执行计划显示对`employees`表使用了`hire_date`索引，然后对`salaries`表进行了Nested-LoopJoin。但查询性能仍然不佳。以下哪种索引策略最有可能显著提升性能？A.在`employees`表上创建`(hire_date,emp_no)`复合索引B.在`salaries`表上创建`(salary,emp_no)`复合索引C.在`salaries`表上创建`(emp_no,salary,from_date,to_date)`复合索引D.在`salaries`表上创建`(from_date,to_date)`复合索引答案：C解析：这是一个典型的关联查询，连接条件是`e.emp_no=s.emp_no`，并且`salaries`表有额外的过滤条件`salary>60000`和日期范围条件。当前计划：先通过`employees.hire_date`索引找到90-95年入职的员工，然后对于每一个找到的`emp_no`，去`salaries`表中查找对应的、当前有效的、且工资>60000的记录。问题瓶颈：对于每个`emp_no`，需要在`salaries`表中进行的查找可能效率不高。虽然`salaries`表有`emp_no`上的索引（用于连接），但查询还需要过滤`salary`和日期。如果使用`emp_no`索引找到所有该员工的薪水记录，然后再在结果集中过滤`salary`和日期，可能会涉及大量回表操作和过滤。C选项的索引`(emp_no,salary,from_date,to_date)`是一个覆盖索引（coveringindex），并且列的顺序经过精心设计：1.`emp_no`作为第一列，完美匹配连接条件（等值查询）。2.`salary`作为第二列，可以高效过滤`salary>60000`（范围查询）。由于`emp_no`是等值，复合索引中`emp_no`相同的行在物理上是相邻的，`salary`作为第二列可以在这个“块”内进行高效的范围筛选。3.`from_date`和`to_date`包含在索引中，使得索引可以覆盖查询（即查询所需的`emp_no`,`salary`,`from_date`,`to_date`都来自索引，无需回表读取数据行），进一步加快查询速度。日期条件也可以作为索引筛选的一部分。这个索引能让连接操作中对`salaries`表的访问变得极其高效。A：`(hire_date,emp_no)`索引对驱动表`employees`的筛选有帮助，但问题瓶颈在`salaries`表，此索引优化作用有限。B：`(salary,emp_no)`索引，第一列是`salary`。如果优化器选择先扫描这个索引找出`salary>60000`的记录，然后再与`employees`表关联，这可能会改变连接顺序，可能有效也可能无效，取决于数据分布。但该索引没有包含日期字段，无法覆盖日期条件，且连接列`emp_no`在第二列，对于Nested-LoopJoin中根据`emp_no`查找的效率不如C选项的索引。D：`(from_date,to_date)`索引对连接条件没有帮助，优化器很可能不会使用。12.关于MySQL8.0中的角色（Role）管理，以下说法正确的是？A.角色创建后会自动激活，并立即对所有授予该角色的用户生效B.一个角色不能授予给另一个角色C.使用`SETDEFAULTROLE`语句可以设置用户下次登录时自动激活的角色D.撤销（REVOKE）用户的角色权限时，该用户通过角色获得的权限会立即失效，即使当前会话已激活该角色答案：C解析：A错误。在MySQL8.0中，角色创建并授予用户后，角色默认是不激活的。用户（或会话）需要执行`SETROLE`来激活角色，或者使用`SETDEFAULTROLE`设置默认角色使其在登录时自动激活。B错误。MySQL8.0支持角色的嵌套，即一个角色可以授予给另一个角色。C正确。`SETDEFAULTROLE`用于指定一个或多个角色作为用户的默认角色。当用户连接服务器时，这些默认角色会自动激活。例如：`SETDEFAULTROLEadminTO'user1'@'localhost';`D错误。当从用户撤销角色或修改角色权限时，对于当前已经激活该角色的会话，权限的变更不会立即生效。用户需要重新激活角色（先`SETROLENONE`，再`SETROLE`）或者重新登录，新的权限设置才会生效。这是出于会话状态的考虑。13.计算题：假设一个InnoDB表，每行数据（包括主键和所有列）的平均大小是1KB。该表的主键是自增的BIGINT。表上有三个辅助索引（SecondaryIndex），每个辅助索引条目的大小平均为0.5KB（包含主键值）。如果该表有1亿（100,000,000）行数据，且InnoDB的页大小是16KB。请估算仅数据部分（不包括辅助索引）占用的磁盘空间大约是多少GB？忽略页头、页尾、碎片等开销进行近似计算。要求：写出计算过程，使用LaTeX格式公式。答案：计算过程如下：1.计算每页能存放的数据行数：R2.计算存储所有数据行需要的页数：T3.计算数据部分总空间（GB）：TTTT解析：这是一个简化的理论计算。实际占用空间会更大，因为需要考虑：页内部碎片：页不可能被行数据完全填满。页管理开销：每个页有约100字节的页头、页尾等信息。B+树结构开销：数据存储在聚簇索引（主键索引）的叶子节点，还有非叶子节点（虽然数量相对少）。辅助索引占用独立空间，未计入本题所求。表碎片：删除、更新操作可能导致页内或页间碎片。因此，实际磁盘占用通常比这个简单计算值高20%-50%甚至更多。此计算题旨在考察对InnoDB存储基本单元（页）和空间估算的理解。14.在MySQL高可用架构中，关于使用MySQLRouter进行读写分离，以下描述错误的是？A.MySQLRouter可以基于端口将读写请求路由到不同的MySQL服务器实例B.当后端数据库发生故障转移后，MySQLRouter需要重启才能识别新的主节点C.MySQLRouter的配置中可以定义多个读写（rw）和只读（ro）目标D.MySQLRouter本身是一个轻量级中间件，不存储数据答案：B解析：A正确。MySQLRouter通常配置两个端口，例如3306用于读写请求（路由到主库），3307用于只读请求（路由到从库）。B错误。现代版本的MySQLRouter支持动态状态感知。当与MySQLInnoDBCluster或GroupReplication配合使用时，Router可以通过元数据缓存动态感知集群拓扑变化（如主库故障切换）。Router可以定期（可配置）刷新元数据，从而自动将写请求路由到新的主库，通常不需要重启。对于主从复制环境，可能需要借助像`mysql_innodb_cluster_metadata`这样的元数据或外部工具来实现动态感知，但“需要重启”不是普遍要求。C正确。配置文件中可以指定多个后端服务器，并标记其角色（rw,ro）。D正确。Router主要负责连接路由和负载均衡，是无状态的，不持久化应用数据。15.执行以下一系列SQL语句：```sqlSTARTTRANSACTION;UPDATEaccountsSETbalance=balance100WHEREid=1;此时在另一个会话中执行：UPDATEaccountsSETbalance=balance+50WHEREid=1;(该语句被阻塞)SAVEPOINTsp1;UPDATEaccountsSETbalance=balance50WHEREid=2;ROLLBACKTOSAVEPOINTsp1;COMMIT;```请问，当第一个会话的`COMMIT`执行后，账户1（id=1）的余额变化是多少？（假设初始余额为1000）A.减少了100，余额为900B.减少了50，余额为950C.减少了150，余额为850D.余额不变，仍为1000答案：A解析：需要逐步分析第一个会话的事务操作：1.`STARTTRANSACTION;`开始事务。2.`UPDATEaccountsSETbalance=balance100WHEREid=1;`将id=1的账户余额减少100（假设原1000，变为900）。该操作会获取id=1记录的行锁（写锁）。第二个会话的`UPDATE`试图修改同一行（id=1），由于第一个事务持有该行的写锁且未提交，第二个会话的`UPDATE`被阻塞，进入锁等待。3.`SAVEPOINTsp1;`设置一个保存点。4.`UPDATEaccountsSETbalance=balance50WHEREid=2;`修改id=2的账户，与本题问题无关。5.`ROLLBACKTOSAVEPOINTsp1;`回滚到保存点`sp1`。这会撤销步骤4对id=2账户的修改。但不会撤销步骤2对id=1的修改，因为保存点是在步骤2之后设置的。对id=1的修改依然有效。6.`COMMIT;`提交事务。事务的所有修改（即对id=1账户扣款100）被永久保存，并释放所有锁。此时，第二个会话的`UPDATE`（加50）获得锁并执行，将id=1的余额从900增加50，变为950。但问题问的是第一个会话`COMMIT`后账户1的余额变化。第一个会话只做了扣款100的操作，所以第一个会话提交后，余额是900。第二个会话的操作是独立的，其提交后的结果不影响对第一个会话自身操作的判断。因此，从第一个会话的视角，它提交后账户1的余额是900，即减少了100。16.关于MySQL的查询缓存（QueryCache），以下说法正确的是？（注：MySQL8.0已移除查询缓存）A.任何对表的写操作（INSERT/UPDATE/DELETE）都会使涉及该表的所有查询缓存失效B.查询缓存对于包含不确定函数（如`NOW()`）的查询语句是有效的C.查询缓存以数据库（schema）为粒度进行管理D.设置`query_cache_type=DEMAND`后，只有在SQL语句中明确添加`SQL_NO_CACHE`提示的查询才会使用缓存答案：A解析：A正确。这是查询缓存失效机制的核心。一旦某个表发生任何数据修改，所有与该表相关的查询缓存条目都会被标记为失效并从缓存中清除。这是导致查询缓存在写频繁场景下效率低下的主要原因。B错误。查询语句中包含不确定函数（如`NOW()`、`CURRENT_TIMESTAMP`、`RAND()`、`UUID()`等）时，其结果是不确定的，MySQL查询缓存不会缓存此类查询的结果。C错误。查询缓存是以整个查询语句的哈希值（以及数据库、客户端协议版本等）为键进行管理的，失效是以表为粒度的，但缓存条目本身关联到具体的SQL字符串。D错误。`query_cache_type=DEMAND`表示查询缓存默认关闭。只有那些在SQL语句中明确添加了`SQL_CACHE`提示的查询，才会尝试使用查询缓存。`SQL_NO_CACHE`提示是在查询缓存开启时，用于强制特定查询不走缓存。17.在MySQL8.0中，执行以下窗口函数查询：```sqlSELECTdep_id,emp_id,salary,SUM(salary)OVER(PARTITIONBYdep_idORDERBYemp_id)ASrunning_totalFROMemployees;```对于同一部门（`dep_id`）内的数据，`running_total`列的计算规则是？A.当前行及之前所有行（按`emp_id`排序）的`salary`累计值B.当前行及之后所有行（按`emp_id`排序）的`salary`累计值C.整个部门的`salary`总和D.从部门第一行到当前行的`salary`平均值答案：A解析：窗口函数`SUM(salary)OVER(PARTITIONBYdep_idORDERBYemp_id)`定义了一个窗口：`PARTITIONBYdep_id`：将数据按部门分区，计算在每个部门内独立进行。`ORDERBYemp_id`：在部门内，按`emp_id`排序。当在`SUM()`等聚合窗口函数中使用`ORDERBY`时，其默认的窗口框架（frame）是`RANGEBETWEENUNBOUNDEDPRECEDINGANDCURRENTROW`。这意味着计算范围是从分区的第一行（UNBOUNDEDPRECEDING）到当前行（CURRENTROW）。因此，对于每一行，`running_total`计算的是：在同一个部门内，从`emp_id`最小的那一行开始，到当前行（按`emp_id`顺序）为止，所有行的`salary`累计和。这就是一个典型的“运行总计”或“累计和”。18.为了监控MySQL数据库的性能，你打算收集一段时间内的关键指标。以下哪项组合最适合用于分析数据库的负载特征和瓶颈？A.慢查询日志、`SHOWGLOBALSTATUS`中的`Com_select`和`Com_insert`计数器差值、`SHOWPROCESSLIST`快照B.错误日志、`SHOWENGINEINNODBSTATUS`输出、数据库磁盘空间使用量C.`SHOWVARIABLES`中的内存相关设置、操作系统CPU使用率、网络带宽D.二进制日志大小、表数量、用户连接数上限答案：A解析：A是最直接针对数据库负载和性能瓶颈的分析组合。慢查询日志：直接定位执行时间长的SQL语句，是性能调优的首要信息来源。`SHOWGLOBALSTATUS`计数器差值：通过计算两个时间点`Com_select`,`Com_insert`,`Com_update`,`Com_delete`等命令计数器的差值，可以了解统计周期内的各类操作频率，量化负载类型（读多还是写多）。`SHOWPROCESSLIST`快照：查看