数据库运行管理员题库 ======================================== 1. 在Linux环境下安装MySQL 8.0时，若希望数据目录位于独立挂载的/data分区并启用大小写敏感的表名，初始化时应如何设置 A. 初始化前修改my.cnf设置lower_case_table_names=0并指定datadir=/data/mysql B. 初始化时加--lower-case-table-names=0并指定--datadir=/data/mysql C. 初始化后通过SET GLOBAL lower_case_table_names=0动态修改再迁移数据目录 D. 先用默认参数初始化，再把数据目录整体mv到/data/mysql并重启服务 答案：B 解析：知识点：MySQL 8.0初始化参数。lower_case_table_names只能在初始化时通过参数指定，初始化后不可动态修改，故B正确；A仅改配置文件未在初始化命令行传入不会生效；C该参数不支持SET GLOBAL动态修改；D直接mv数据目录不会改变已写入的表名大小写元数据，且可能因权限与路径配置不一致导致启动失败。 2. 某DBA对MySQL执行mysqldump做逻辑备份时，希望备份结果包含建库语句且能在恢复时先删除同名表再重建，应组合使用哪组参数 A. --databases与--add-drop-table B. --no-create-db与--replace C. --databases与--insert-ignore D. --single-transaction与--no-create-info 答案：A 解析：知识点：mysqldump常用参数。--databases会在导出中包含CREATE DATABASE语句，--add-drop-table会在每个建表语句前加DROP TABLE IF EXISTS，故A正确；B的--no-create-db不产生建库语句、--replace是替换插入语义；C的--insert-ignore是忽略冲突插入，不含删表重建；D的--no-create-info不导出表结构。 3. 对一张千万级大表执行全表统计信息收集时，为避免长时间锁表并保证统计结果可用于优化器，下列做法最合适的是 A. 在业务低峰期执行ANALYZE TABLE并配合采样比例参数 B. 在业务高峰期直接执行ANALYZE TABLE以尽快拿到新统计 C. 先执行FLUSH TABLES再执行ANALYZE TABLE强制刷新缓存 D. 关闭慢查询日志后执行ANALYZE TABLE减少写入开销 答案：A 解析：知识点：统计信息收集与锁影响。ANALYZE TABLE在低峰期执行并配合采样可降低锁与IO影响，故A正确；B高峰期执行会加剧资源争用；C的FLUSH TABLES用于关闭打开的表，与统计信息收集目的无关；D关闭慢查询日志不影响统计收集开销，属于无关操作。 4. PostgreSQL中配置流复制时，主库的wal_level参数应设置为哪一档才能支持备库接收并重放WAL日志 A. minimal B. replica C. logical D. archive 答案：B 解析：知识点：PostgreSQL WAL级别。replica（或logical）可提供流复制所需的WAL信息，故B正确；minimal不足以支持流复制；logical用于逻辑解码，虽可支持但并非流复制基本要求档位；archive不是wal_level的合法取值。 5. 在Oracle RMAN中执行全库备份后，发现某数据文件在备份期间被误删，此时最直接的恢复步骤是 A. 先还原该数据文件再应用归档日志做恢复 B. 先执行全库还原再应用全部归档日志恢复 C. 直接启动数据库由SMON自动修复该文件 D. 用备份的控制文件替换当前控制文件后开库 答案：A 解析：知识点：RMAN单文件恢复流程。数据文件缺失时先RESTORE该文件再RECOVER应用归档日志即可，故A正确；B全库还原代价过大且非必要；C实例无法自动重建被删数据文件；D替换控制文件不能补回数据文件内容。 6. 某OLTP库出现大量慢查询，执行计划显示对一张过滤性很高的列走了全表扫描，最可能的原因是 A. 该列上缺少合适的索引或统计信息过期 B. 该表所在表空间剩余空间不足 C. 数据库归档日志目录已写满 D. 客户端连接数超过了最大连接限制 答案：A 解析：知识点：执行计划与索引/统计信息。走全表扫描的常见根因是缺索引或统计信息过期导致优化器估算偏差，故A正确；B表空间不足影响写入而非选择全表扫描；C归档满会导致挂起而非改变计划；D连接数超限影响连接建立而非单条SQL计划。 7. 在MySQL主从复制中，从库Seconds_Behind_Master持续增大但IO线程正常，最应优先排查的是 A. 从库SQL线程是否因大事务或单线程回放而滞后 B. 主库binlog是否被误删除导致IO中断 C. 从库磁盘是否已满导致relay log无法写入 D. 主从server_id是否配置冲突 答案：A 解析：知识点：主从延迟定位。IO线程正常说明日志已拉取，延迟来自SQL线程回放慢，常见于大事务或并行复制未开启，故A正确；B会导致IO线程异常；C会影响relay log写入而非IO正常情况；D的server_id冲突会导致复制无法启动而非延迟增长。 8. 对SQL Server数据库执行完整备份后，事务日志文件持续增长且未截断，最可能的原因是 A. 数据库处于完整恢复模式且未执行日志备份 B. 数据库处于简单恢复模式且备份频率过低 C. 备份文件与数据文件放在同一磁盘阵列上 D. 数据库启用了自动收缩但未启用自动增长 答案：A 解析：知识点：恢复模式与日志截断。完整恢复模式下只有日志备份才会截断日志，故A正确；简单恢复模式会自动截断日志；备份文件位置不影响日志截断；自动收缩与自动增长设置不决定日志能否截断。 9. 某系统要求RPO接近0且RTO在分钟级，数据库部署方案中最能满足该要求的是 A. 同城双活加同步复制并配置自动故障切换 B. 每日一次全量备份加每小时增量备份 C. 主库本地磁盘做RAID5并开启归档 D. 异地异步复制加每周一次全量备份 答案：A 解析：知识点：RPO/RTO与容灾架构。同步复制可保证RPO接近0，自动故障切换可缩短RTO，故A正确；B的备份粒度导致RPO至少一小时；C的RAID与归档不解决实例级故障切换；D异步复制RPO大于0且备份周期长，RTO也难达分钟级。 10. 运维人员在调整数据库内存参数后实例启动失败，日志提示无法分配共享内存，下一步最合理的处置是 A. 回退该内存参数到原值并核对系统共享内存限制 B. 直接调大操作系统swap分区后重启实例 C. 删除数据目录下的临时文件后重新启动实例 D. 将数据库切换到单用户模式跳过内存检查 答案：A 解析：知识点：参数调整与系统资源限制。启动失败源于共享内存分配超出系统限制，应先回退参数并核对内核共享内存配置，故A正确；B扩容swap不能解决共享内存段分配失败；C删临时文件与共享内存无关；D单用户模式不能绕过内存分配检查。 11. 在数据库性能调优中，下列属于通过减少物理IO来提升查询效率的措施有 A. 为高频过滤列建立合适索引 B. 将热点表数据缓存在内存缓冲池 C. 对大表频繁执行全表扫描以获取最新数据 D. 定期重建碎片率过高的索引 E. 对返回大量行的查询取消排序操作 答案：A、B、D 解析：知识点：减少物理IO的调优手段。索引可减少扫描页数、缓冲池可命中内存、重建碎片索引可减少页读取，故A、B、D正确；C的全表扫描会增加物理IO；E取消排序并不能减少数据页的物理读取，且可能改变结果语义。 12. 在Linux上安装MySQL后，希望数据库服务随操作系统开机自动启动，应执行的操作是 A. systemctl enable mysqld B. systemctl start mysqld C. systemctl reload mysqld D. systemctl status mysqld 答案：A 解析：知识点是Linux服务管理。enable用于设置开机自启；start仅本次启动，reload用于重载配置，status用于查看状态，均不改变开机自启设置。 13. 某DBA为MySQL配置了binlog后，执行全量备份与binlog归档相结合的恢复策略，其主要目的是 A. 把数据库恢复到备份之后的任意时间点 B. 减少备份文件占用的磁盘空间 C. 提升备份期间数据库的写入并发度 D. 替代定期全量备份以节省备份时间 答案：A 解析：知识点是备份恢复策略。全量备份加binlog可实现时间点恢复（PITR）；减少空间、提升并发、替代全量均不是binlog归档的核心目的。 14. 某MySQL实例的innodb_buffer_pool_size长期设置为物理内存的5%，查询响应缓慢且磁盘读IOPS很高，最应优先调整的是 A. 增大innodb_buffer_pool_size B. 增大max_connections C. 增大sort_buffer_size D. 增大table_open_cache 答案：A 解析：知识点是InnoDB内存调优。缓冲池过小导致频繁磁盘读，应优先增大缓冲池；连接数、排序缓冲、表缓存不解决缓冲池不足引起的读放大问题。 15. 对MySQL执行mysqldump全量备份时加上--single-transaction参数，其作用是 A. 在InnoDB表上获得一致性快照而不锁表 B. 对MyISAM表加读锁保证一致性 C. 在备份期间禁止其他会话写入 D. 把多个表的数据导出到同一个事务日志 答案：A 解析：知识点是mysqldump一致性备份。--single-transaction对InnoDB开启可重复读事务获得一致快照；它不锁MyISAM表、不禁止其他写入，也不合并事务日志。 16. PostgreSQL中执行VACUUM与VACUUM FULL的核心区别是 A. VACUUM FULL会重写表并回收磁盘空间给操作系统 B. VACUUM FULL只更新统计信息不回收空间 C. VACUUM会重建索引而VACUUM FULL不会 D. VACUUM只能在只读事务中执行 答案：A 解析：知识点是PostgreSQL空间回收。VACUUM FULL重写表文件并将空间归还操作系统，但会加排他锁；VACUUM仅标记空间可复用，不重写表，也不重建全部索引。 17. 某数据库服务器磁盘IO等待长期偏高，经排查发现大量查询未命中索引而触发全表扫描，作为DBA下一步最合理的处置是 A. 分析慢查询日志并针对高频语句优化索引 B. 直接更换为更高转速的磁盘 C. 增大数据库连接池的最大连接数 D. 把数据库字符集改为utf8mb4 答案：A 解析：知识点是性能诊断与优化。IO高源于全表扫描，应先定位慢查询并优化索引；换磁盘治标不治本，加连接数和改字符集与IO问题无关。 18. 在MySQL主从复制环境中，从库出现Seconds_Behind_Master持续增大，主库binlog格式为ROW，最可能的原因是 A. 从库单线程回放跟不上主库并发写入 B. 主库binlog未开启sync_binlog C. 从库未开启binlog日志 D. 主库未设置server-id 答案：A 解析：知识点是MySQL复制延迟。ROW格式下从库若单线程回放，面对主库高并发写入容易滞后；sync_binlog影响主库持久性，从库binlog和主库server-id与延迟无直接关系。 19. 对Oracle执行RMAN全量备份后，为验证备份集可被恢复且数据块无损坏，应执行的操作是 A. RESTORE VALIDATE DATABASE B. BACKUP VALIDATE DATABASE C. RECOVER DATABASE D. CROSSCHECK BACKUP 答案：A 解析：知识点是RMAN备份验证。RESTORE VALIDATE用于验证备份可恢复性并检查块；BACKUP VALIDATE只校验源文件不验证备份集，RECOVER会实际恢复，CROSSCHECK只核对备份记录状态。 20. 某业务库需在每天凌晨执行逻辑备份，同时要求备份期间业务写入不被长时间阻塞，最合适的方案是 A. 使用支持一致性快照的在线逻辑备份工具 B. 停止业务后执行冷备份再启动 C. 对数据文件直接cp复制而不停库 D. 把数据库设为只读后再执行备份 答案：A 解析：知识点是在线备份方案。在线逻辑备份工具通过快照或事务机制保证一致性且不长时间阻塞写入；冷备份、不停库直接复制文件、设为只读都会影响业务或导致备份不一致。 21. MySQL中查询information_schema.tables时发现某表DATA_LENGTH远大于实际行数据量，且删除大量历史数据后空间未释放，最恰当的处置是 A. 执行OPTIMIZE TABLE回收表空间 B. 执行ANALYZE TABLE更新统计信息 C. 执行FLUSH TABLES刷新表缓存 D. 执行CHECK TABLE检查表完整性 答案：A 解析：知识点是InnoDB表空间回收。大量删除后需OPTIMIZE TABLE（或重建表）归还空间；ANALYZE只更新统计信息，FLUSH和CHECK不回收空间。 22. 在制定数据库备份恢复策略时，下列做法有助于提升恢复可靠性的有 A. 定期对备份集执行恢复演练 B. 将备份文件与数据库主机分离存放 C. 为备份文件启用校验并定期验证 D. 仅保留最近一次全量备份以节省空间 E. 对备份文件设置与数据库相同的访问权限 答案：A、B、C 解析：知识点是备份恢复可靠性。恢复演练、异地存放、校验验证均能提升可靠性；只保留一次全量备份会丧失历史恢复点，备份文件沿用数据库权限可能扩大误删或泄露风险，均不推荐。 23. 在Linux服务器上通过源码编译方式安装MySQL后，执行初始化时提示无法加载libaio.so.1，最应优先检查的是哪一项 A. 是否已安装libaio运行库依赖包 B. 是否已创建mysql系统用户 C. 是否已修改my.cnf配置文件 D. 是否已开放3306端口 答案：A 解析：知识点是数据库安装前的系统依赖检查。初始化报错直接指向缺少libaio动态库，因此优先确认该依赖包是否安装；创建mysql用户属于后续权限准备，修改my.cnf属于配置阶段，开放3306端口属于网络访问阶段，均不会导致该动态库加载失败。 24. 对MySQL执行逻辑备份时，使用mysqldump加--single-transaction选项的主要目的是什么 A. 在InnoDB表上获得一致性的备份快照 B. 把备份文件自动压缩以节省空间 C. 跳过表锁从而允许写入并保证数据一致 D. 将备份直接传输到远程服务器保存 答案：A 解析：知识点是mysqldump一致性备份机制。--single-transaction对InnoDB表开启可重复读事务以获得一致性快照，故正确；该选项不负责压缩，压缩需另行处理；它并非跳过锁来保证一致，而是避免长时间锁表；也不负责远程传输，远程传输需配合其他命令。 25. 数据库执行全量备份后，为缩短恢复时间并减少每日备份量，通常采用的备份策略组合是 A. 每周全量备份加每日增量备份 B. 每天全量备份并保留七天 C. 每月全量备份并关闭日志归档 D. 仅在业务低峰期做一次全量备份 答案：A 解析：知识点是备份策略设计。全量加增量的组合既保留完整基线又降低日常备份量和恢复时间，故正确；每天全量占用空间大且耗时；关闭日志归档会丧失时间点恢复能力；仅做一次全量无法覆盖后续变更。 26. 使用Percona XtraBackup对InnoDB进行物理备份后，在恢复前通常需要执行的操作是 A. 对备份目录执行prepare以应用redo日志 B. 对备份目录执行mysqldump导出结构 C. 对备份目录执行chown改为root属主 D. 对备份目录执行drop database清理旧库 答案：A 解析：知识点是物理备份恢复流程。XtraBackup备份的是数据文件，恢复前需prepare阶段使数据文件一致，故正确；mysqldump是逻辑导出工具不用于此；属主应按数据库运行用户设置而非root；恢复前清理旧库属于人工准备非工具必需步骤。 27. 在Linux下配置数据库服务开机自启，使用systemd管理时应执行的操作是 A. 将服务单元文件启用并设置enable B. 把启动脚本加入crontab定时任务 C. 在rc.local中追加启动命令 D. 将二进制文件复制到/usr/bin目录 答案：A 解析：知识点是systemd服务管理。启用服务单元并enable可实现开机自启，故正确；crontab定时启动不保证开机顺序且易重复；rc.local在部分发行版已废弃且时机不稳定；复制二进制只影响命令可执行性，与自启无关。 28. 某业务要求数据库发生故障后能把数据恢复到当天任意时刻，备份方案中必须包含的是 A. 定期的全量备份加持续归档的二进制日志 B. 每天一次的逻辑备份并保留一个月 C. 每周一次的全量备份并做磁盘镜像 D. 每次变更后手工导出单表数据 答案：A 解析：知识点是时间点恢复能力。任意时刻恢复需要全量基线加连续binlog重放，故正确；仅每天逻辑备份无法恢复到两次备份之间的时刻；磁盘镜像不能提供逻辑时间点；手工导出单表难以覆盖全部变更。 29. 运维人员准备在生产库上直接执行大表结构变更，为避免长时间锁表影响业务，较稳妥的做法是 A. 使用在线DDL工具在业务低峰分批执行并观察 B. 直接在业务高峰执行以便快速完成 C. 先关闭binlog再执行以加快速度 D. 将表复制到测试库改完后再手工同步数据 答案：A 解析：知识点是在线DDL与变更风险控制。使用在线DDL工具并选低峰分批可降低锁表影响，故正确；高峰执行会放大阻塞；关闭binlog破坏复制与恢复能力；手工同步数据易漏变更且不可控。 30. 关于数据库备份有效性验证，下列做法中合理的有哪些 A. 定期在隔离环境执行恢复演练并核对数据 B. 对备份文件计算校验值并记录比对 C. 仅查看备份任务返回成功即认为可恢复 D. 将备份文件与生产库放在同一块磁盘 E. 每次备份后随机抽取表做行数核对 答案：A、B、E 解析：知识点是备份有效性验证。恢复演练、校验值比对、抽样行数核对都能验证备份可用性，故正确；仅看任务成功无法发现文件损坏或不可恢复；与生产库同盘存放会在磁盘故障时同时丢失备份，属于风险做法。 31. 在Linux服务器上以RPM包安装MySQL 8.0后，需要修改默认字符集为utf8mb4并使其对后续新建库生效，应优先调整哪个配置文件中的参数 A. /etc/my.cnf 中 [mysqld] 段的 character-set-server B. /etc/my.cnf 中 [client] 段的 default-character-set C. /usr/share/mysql/my-default.cnf 中的 collation-server D. /var/lib/mysql/auto.cnf 中的 server-uuid 答案：A 解析：知识点是MySQL配置文件分段作用。[mysqld]段的character-set-server决定服务端默认字符集，对新建库生效；[client]段只影响客户端连接字符集，不影响服务端建库默认值；my-default.cnf是模板样例文件，修改它不生效；auto.cnf只存server-uuid，与字符集无关。 32. 某DBA在业务低峰期对InnoDB表执行逻辑备份，希望备份期间不锁表且能获得一致性快照，应选用的工具与参数组合是 A. mysqldump --single-transaction B. mysqldump --lock-all-tables C. mysqldump --lock-tables D. mysqldump --flush-logs 答案：A 解析：知识点是一致性逻辑备份。--single-transaction在InnoDB上开启可重复读事务获得一致性快照且不锁表；--lock-all-tables会对全库加读锁阻塞写入；--lock-tables对每张表加锁，同样阻塞写；--flush-logs只是切日志，不保证备份一致性。 33. 在PostgreSQL中执行pg_basebackup做基础备份时，希望备份过程不阻塞其他会话的写入并自动进入流复制就绪状态，应添加的参数是 A. -X stream 并配合 -P B. -Ft 并配合 -z C. -Xs 并配合 --no-sync D. -c fast 并配合 -D 答案：A 解析：知识点是pg_basebackup参数。使用-X stream可在备份同时流式传输所需WAL，配合-P显示进度，不阻塞正常写入；-Ft是输出tar格式，与阻塞无关；--no-sync只是跳过同步落盘；-c fast是checkpoint模式，与是否阻塞写入无直接关系。 34. 对一张千万级InnoDB表执行在线DDL加索引时，为尽量减少对业务写入的影响，应选择的语句是 A. ALTER TABLE ... ADD INDEX ..., ALGORITHM=INPLACE, LOCK=NONE B. ALTER TABLE ... ADD INDEX ..., ALGORITHM=COPY, LOCK=SHARED C. ALTER TABLE ... ADD INDEX ..., ALGORITHM=INPLACE, LOCK=SHARED D. ALTER TABLE ... ADD INDEX ..., ALGORITHM=COPY, LOCK=EXCLUSIVE 答案：A 解析：知识点是在线DDL的算法与锁级别。INPLACE配合LOCK=NONE允许DDL期间并发读写，影响最小；COPY算法会重建表并阻塞写入；INPLACE加SHARED仍限制写；COPY加EXCLUSIVE完全阻塞读写，影响最大。 35. PostgreSQL中执行VACUUM FULL后，表文件在磁盘上的物理大小通常会发生变化，原因是 A. 重写整表并把未使用空间归还操作系统 B. 仅标记死元组为可复用但不归还磁盘 C. 更新统计信息并重建所有索引 D. 将表数据压缩后写回原文件 答案：A 解析：知识点是VACUUM与VACUUM FULL区别。VACUUM FULL会重写整表，把空间归还操作系统，因此文件变小；普通VACUUM只标记空间可复用不归还；ANALYZE才更新统计信息；PostgreSQL不会自动压缩表文件写回原文件。 36. 某数据库服务器磁盘IO持续接近饱和，iostat显示大量随机读且队列深度很高，在不增加硬件的前提下最合理的调优措施是 A. 增大InnoDB缓冲池并优化高频查询的索引 B. 把redo log刷盘策略改为每次提交都刷 C. 将binlog与数据文件放在同一块盘上 D. 关闭操作系统的预读以降低队列深度 答案：A 解析：知识点是IO瓶颈的软件层缓解。增大缓冲池可把热点数据留在内存、减少随机读，配合索引优化降低扫描量；每次提交都刷redo会增加写压力；binlog与数据同盘会加剧竞争；关闭预读对随机读帮助有限且可能损害顺序读性能。 37. 在MySQL主从复制中，从库出现Seconds_Behind_Master持续增大且Relay_Log_Pos长时间不推进，首先应检查的是 A. 从库SQL线程是否处于运行状态及是否有大事务阻塞 B. 主库binlog是否已切换过文件 C. 从库的read_only参数是否开启 D. 主库的max_connections是否已满 答案：A 解析：知识点是复制延迟定位。Relay_Log_Pos不推进说明SQL线程可能停止或被大事务长时间占用，应先看线程状态与阻塞；binlog切换属正常操作；read_only只影响写入权限；主库连接数满影响的是新连接而非已建立的复制。 38. 某DBA计划对生产库做物理备份恢复演练，为验证备份可用性且不影响生产实例，正确做法是 A. 在隔离的测试实例上按备份时间点做完整恢复并校验数据 B. 直接在生产实例上覆盖数据目录后启动验证 C. 把备份文件复制到生产库另一目录挂载后启动 D. 仅用备份工具列出文件清单确认文件存在 答案：A 解析：知识点是恢复演练规范。应在隔离环境完整恢复并校验数据，既验证可用性又不影响生产；覆盖生产数据目录风险极高；在生产库旁挂载启动会争用资源与端口；仅列清单无法证明可恢复。 39. 在制定数据库备份策略时，以下哪些做法有助于同时满足可恢复性与存储成本控制 A. 每周一次全量备份并每日增量备份 B. 定期对备份文件做恢复性校验 C. 将多份备份长期保留在同一块磁盘上 D. 按保留策略自动清理过期备份 E. 把备份文件与数据文件放在同一存储卷 答案：A、B、D 解析：知识点是备份策略设计。全量加增量可在恢复能力与空间间取得平衡；恢复性校验确保备份可用；按策略清理避免无限增长。长期保留在同一磁盘占用空间且单点故障风险高；备份与数据同卷会在存储故障时同时丢失，均不利于目标。 40. 在Linux环境下安装MySQL 8.0时，官方推荐的二进制包解压后初始化数据目录应使用哪个命令 A. mysqld --initialize --user=mysql B. mysqld --init-file=/etc/my.cnf C. mysql_install_db --user=mysql D. mysqld_safe --initialize-insecure 答案：A 解析：知识点：MySQL 8.0初始化数据目录。mysqld --initialize会生成临时root密码并初始化数据目录，是官方推荐方式。mysqld --init-file用于启动时执行SQL文件而非初始化；mysql_install_db在5.7后已被废弃；mysqld_safe是启动守护脚本，不接受--initialize-insecure参数。 41. Oracle数据库执行RMAN全量备份后，若要验证备份集是否可正常用于恢复且不实际还原数据文件，应使用哪个命令 A. RESTORE DATABASE VALIDATE B. VALIDATE BACKUP C. CROSSCHECK BACKUP D. LIST BACKUP SUMMARY 答案：B 解析：知识点：RMAN备份验证。VALIDATE BACKUP用于检查备份集完整性，确认可用于恢复而不实际还原。RESTORE DATABASE VALIDATE会读取备份并校验，但更侧重还原路径验证；CROSSCHECK仅检查备份文件是否存在及状态；LIST BACKUP SUMMARY只列出备份信息，不做完整性校验。 42. SQL Server中某查询在业务高峰期出现大量PAGEIOLATCH_SH等待，最应优先排查的环节是 A. 事务日志写入磁盘的延迟 B. 数据文件所在磁盘的读取延迟 C. 锁管理器内存分配不足 D. 网络往返导致的响应超时 答案：B 解析：知识点：SQL Server等待类型分析。PAGEIOLATCH_SH表示等待从磁盘读取数据页到缓冲池，指向数据文件读取I/O瓶颈。日志写入延迟对应WRITELOG；锁内存不足对应RESOURCE_SEMAPHORE；网络超时对应ASYNC_NETWORK_IO。 43. PostgreSQL中执行VACUUM FULL与VACUUM的主要区别在于 A. VACUUM FULL会重写表并释放磁盘空间给操作系统 B. VACUUM FULL只在从库上执行以减轻主库压力 C. VACUUM FULL会清理事务ID回卷而不重写表 D. VACUUM FULL会同时重建所有索引并更新统计信息 答案：A 解析：知识点：PostgreSQL VACUUM机制。VACUUM FULL重写整表，将空闲空间归还操作系统，但会持有排他锁。VACUUM FULL不在从库单独执行；事务ID回卷由VACUUM（含FREEZE）处理，不必然重写表；重建索引需REINDEX，更新统计信息需ANALYZE。 44. Redis执行BGSAVE时，若发生写操作，Redis采用什么机制保证数据一致性 A. 写操作直接修改RDB文件中的对应键值 B. 写操作写入AOF缓冲区，RDB完成后合并 C. 写操作复制一份被修改页，原页供子进程写盘 D. 写操作阻塞直到BGSAVE完成后统一执行 答案：C 解析：知识点：Redis持久化Copy-On-Write。BGSAVE通过fork子进程写RDB，父进程写操作触发COW复制被修改的内存页，保证子进程看到fork时刻的数据快照。写操作不直接改RDB；AOF与RDB是独立机制；写操作不会阻塞等待BGSAVE完成。 45. MongoDB副本集中，某从节点状态显示为RECOVERING且持续较长时间，最可能的原因是 A. 该节点正在执行初始同步且数据量较大 B. 该节点被选为新的主节点 C. 该节点与主节点时钟偏差超过阈值 D. 该节点开启了读写分离导致负载过高 答案：A 解析：知识点：MongoDB副本集节点状态。RECOVERING表示节点正在同步数据或进行回滚，初始同步数据量大时会持续较久。被选为主节点状态为PRIMARY；时钟偏差影响选举但不直接导致RECOVERING；读写分离在从节点读取不改变节点状态。 46. 对MySQL InnoDB表执行大事务批量删除后，表空间文件未缩小，最合理的处理方式是 A. 执行OPTIMIZE TABLE重建表并回收空间 B. 执行FLUSH TABLES释放缓存 C. 调整innodb_buffer_pool_size后重启 D. 执行ANALYZE TABLE更新统计信息 答案：A 解析：知识点：InnoDB表空间回收。删除操作只标记页为空闲，不释放文件空间，OPTIMIZE TABLE会重建表并回收。FLUSH TABLES只刷新缓存；调整缓冲池大小不影响表空间文件；ANALYZE TABLE只更新统计信息。 47. 在MySQL 8.0中安装完成后，若希望数据库服务随操作系统启动而自动运行，且系统使用systemd管理服务，应执行的操作是 A. systemctl enable mysqld B. systemctl start mysqld C. systemctl status mysqld D. systemctl restart mysqld 答案：A 解析：知识点：Linux下MySQL服务的开机自启配置。systemctl enable用于设置服务开机自启，start仅启动当前会话，status仅查看状态，restart仅重启服务。 48. 某DBA对MySQL数据库执行了全量备份后，又持续备份了二进制日志，当数据库因误删除表需要恢复到故障前状态时，正确的恢复顺序是 A. 先恢复全量备份，再重放二进制日志到误操作前的位置 B. 先重放二进制日志到误操作前，再恢复全量备份 C. 仅恢复全量备份即可，二进制日志用于主从复制 D. 先恢复全量备份，再重放二进制日志到误操作后的位置 答案：A 解析：知识点：全量备份加二进制日志的时间点恢复流程。正确做法是先还原最近一次全量备份，再按顺序重放binlog到误操作发生前的位置。先重放binlog再恢复全量会覆盖日志效果；仅恢复全量会丢失备份后的数据；重放到误操作后会重现误删除。 49. 在对生产库执行备份恢复演练时，下列做法中符合安全规范的有 A. 恢复前先对目标库做一次当前状态的完整备份 B. 在业务低峰期于独立测试环境验证恢复流程 C. 恢复时直接覆盖生产库以节省磁盘空间 D. 恢复后核对关键表的行数与校验和 E. 恢复脚本中硬编码数据库账号密码便于复用 答案：A、B、D 解析：知识点：备份恢复演练的安全操作规范。恢复前备份当前状态可在失败时回退；低峰期独立环境验证不影响生产；恢复后核对数据一致性是必要步骤。直接覆盖生产库风险极高；硬编码密码存在泄露风险且不便轮换。 50. 某MySQL 8.0实例的二进制日志保留策略为binlog_expire_logs_seconds=604800，运维人员在执行一次大批量数据归档后发现磁盘空间紧张，计划在不中断业务的前提下清理旧binlog，下列操作中既能释放空间又不会破坏主从复制或时间点恢复能力的是 A. 使用PURGE BINARY LOGS BEFORE命令删除指定时间点之前的binlog，并先确认从库已应用到位 B. 手动rm删除datadir下部分binlog文件后执行FLUSH LOGS刷新日志索引 C. 设置binlog_expire_logs_seconds为更小值并执行FLUSH LOGS使过期日志自动清理 D. 执行RESET MASTER清空全部binlog并重新开始记录，同时重置GTID序列 答案：A、C 解析：知识点是MySQL二进制日志的清理机制与主从复制安全。PURGE BINARY LOGS BEFORE可安全删除指定时间点前的binlog，前提是确认从库已应用（对应选项1），设置更小的binlog_expire_logs_seconds后由系统自动清理也是安全做法（对应选项3）。选项2手动rm删除binlog文件会破坏binlog索引与复制位点一致性，日志索引仍引用已删除文件；选项4的RESET MASTER会清空全部binlog并重置GTID，破坏从库基于GTID的复制与时间点恢复能力。 51. 在Linux服务器上通过源码编译方式安装MySQL后，执行初始化命令时指定--initialize-insecure参数，该参数的作用是什么 A. 初始化数据目录但不生成root随机密码 B. 初始化数据目录并强制使用空密码登录 C. 初始化数据目录同时创建默认测试数据库 D. 初始化数据目录并跳过权限表加载过程 答案：A 解析：知识点：MySQL初始化参数。--initialize-insecure初始化数据目录且root密码为空，便于后续手动设置。错误项B：该参数并非强制空密码登录而是初始为空；错误项C：初始化不会自动创建测试库；错误项D：权限表仍会创建，只是root初始无密码。 52. 某DBA执行全量备份后每天做增量备份，恢复时发现增量备份无法直接应用，最可能遗漏的操作是什么 A. 恢复前先应用最近一次全量备份 B. 恢复前将增量文件转换为全量文件 C. 恢复前关闭二进制日志写入功能 D. 恢复前对数据目录执行冷拷贝操作 答案：A 解析：知识点：增量恢复顺序。增量备份基于全量备份的时间点，必须先还原全量。错误项B：增量文件不能直接转全量；错误项C：关闭binlog与恢复无关；错误项D：冷拷贝不是增量恢复前置步骤。 53. MySQL中执行SHOW ENGINE INNODB STATUS查看锁等待时，若发现大量LOCK WAIT，优先应排查的指标是哪个 A. innodb_buffer_pool_size的命中率 B. innodb_lock_wait_timeout的取值 C. innodb_log_file_size的写入量 D. innodb_flush_log_at_trx_commit的设置 答案：B 解析：知识点：InnoDB锁等待排查。锁等待超时由innodb_lock_wait_timeout控制，先看该值是否过小或存在长事务。错误项A：缓冲池命中率影响读性能非锁等待；错误项C：日志文件大小影响写性能；错误项D：刷盘策略影响持久性。 54. 对PostgreSQL执行pg_dump备份后，需要在另一台服务器恢复为不同数据库名，正确做法是使用哪个选项 A. pg_restore的-d指定新库名 B. pg_dump的-Fc加新库名参数 C. pg_restore的-C并配合新库名 D. pg_dump的-t指定新库名恢复 答案：A 解析：知识点：pg_restore恢复目标库。pg_restore -d可指定恢复到的新数据库名。错误项B：pg_dump的-Fc只生成自定义格式不指定目标库；错误项C：-C表示创建数据库，但库名仍需-d或连接参数；错误项D：-t用于指定表，与库名无关。 55. Oracle数据库执行RMAN全库备份时，控制文件自动备份默认关闭，若需每次备份后自动备份控制文件应配置哪个参数 A. CONFIGURE CONTROLFILE AUTOBACKUP ON B. CONFIGURE RETENTION POLICY TO REDUNDANCY C. CONFIGURE BACKUP OPTIMIZATION ON D. CONFIGURE DEVICE TYPE DISK PARALLELISM 答案：A 解析：知识点：RMAN控制文件自动备份。CONTROLFILE AUTOBACKUP ON开启自动备份。错误项B：保留策略控制备份保留数量；错误项C：备份优化跳过重复备份；错误项D：设备并行度设置。 56. 某数据库执行逻辑备份期间业务写入量突然增大，备份进程报错ORA-01555快照过旧，最直接的原因是哪个 A. UNDO表空间不足或保留时间过短 B. 临时表空间被大量排序占用 C. 重做日志组数量配置偏少 D. 归档日志目录磁盘空间已满 答案：A 解析：知识点：ORA-01555快照过旧。查询需要的一致性读数据在UNDO中被覆盖，多因UNDO不足或保留时间短。错误项B：临时表空间影响排序；错误项C：重做日志组影响切换；错误项D：归档满影响写入而非一致性读。 57. 在数据库服务器上配置RAID时，为兼顾数据安全与写入性能，通常对数据文件所在盘采用哪种RAID级别最为常见 A. RAID 10 B. RAID 0 C. RAID 5 D. RAID 6 答案：A 解析：知识点：数据库存储RAID选型。RAID10兼顾镜像安全与条带性能，写惩罚低。错误项B：RAID0无冗余不安全；错误项C：RAID5写惩罚高影响性能；错误项D：RAID6冗余更高但写性能更差。 58. MySQL主从复制中从库出现Seconds_Behind_Master持续增大，检查发现从库单线程回放，优化方向正确的是哪个 A. 启用基于LOGICAL_CLOCK的并行复制 B. 增大从库innodb_buffer_pool_size C. 将从库binlog_format改为ROW D. 关闭从库的read_only参数 答案：A 解析：知识点：MySQL并行复制。开启基于LOGICAL_CLOCK的并行回放可提升从库应用速度。错误项B：缓冲池只影响读缓存；错误项C：binlog格式与回放并行度无关；错误项D：read_only与延迟无关。 59. SQL Server中执行完整备份后发现事务日志文件持续增长不收缩，最合理的处理方式是什么 A. 对数据库执行事务日志备份 B. 直接收缩日志文件到最小 C. 将恢复模式改为简单后重建日志 D. 分离数据库后删除日志文件 答案：A 解析：知识点：事务日志管理。完整恢复模式下日志需通过日志备份截断。错误项B：未备份直接收缩治标不治本；错误项C：改模式会破坏日志链；错误项D：分离删除日志会导致数据库损坏。 60. 某生产库凌晨执行全量备份后随即做结构变更，次日需恢复到变更前状态，下列操作中属于正确恢复步骤的有哪些 A. 先还原最近一次全量备份 B. 再应用全量备份之后的二进制日志 C. 恢复前确认备份文件校验完整可用 D. 直接使用最新一次增量备份覆盖数据目录 E. 恢复过程中停止业务写入避免数据冲突 答案：A、B、C 解析：知识点：基于全量+binlog的时间点恢复。步骤为还原全量、应用binlog到目标时间点、恢复前校验备份。错误项D：无增量备份时不能用增量覆盖；错误项E：恢复流程本身要求停写，但它是操作规范而非恢复步骤的核心顺序，且题目问恢复步骤，停写属于前置保障，不应与还原步骤并列作为恢复动作。 61. 在Linux上以源码方式安装MySQL后，首次初始化数据目录时应使用哪个命令生成临时root密码并完成初始化 A. mysqld --initialize --user=mysql B. mysql_install_db --user=mysql C. mysqld --init-file=/etc/my.cnf D. mysqladmin -u root password 答案：A 解析：知识点为MySQL 5.7及以后版本的数据目录初始化方式。mysqld --initialize会创建系统表并生成临时root密码，正确。mysql_install_db是5.6及以前的旧方式，5.7后已废弃。--init-file是启动时执行SQL文件，不用于初始化数据目录。mysqladmin改密码需要数据库已启动且能连接，初始化阶段不适用。 62. 对MySQL执行逻辑备份时，若希望备份文件包含建库建表语句并能一致性导出InnoDB表，应选用哪个工具及参数组合 A. mysqldump --single-transaction B. cp /var/lib/mysql/ibdata1 C. mysqlpump --skip-innodb D. xtrabackup --backup 答案：A 解析：知识点为逻辑备份工具与一致性选项。mysqldump配合--single-transaction可在不锁表情况下获得InnoDB一致性快照，正确。直接复制ibdata1属于冷备份且不完整，无法单独恢复。mysqlpump跳过InnoDB引擎数据会导致数据缺失。xtrabackup是物理备份工具，不是逻辑备份。 63. Oracle数据库处于归档模式，执行RMAN全备后需恢复到某时间点，下列哪个操作顺序正确 A. startup mount→restore database→recover database→alter database open resetlogs B. startup nomount→recover database→restore database→alter database open C. startup→restore database→alter database open→recover database D. startup mount→recover database→restore database→alter database open 答案：A 解析：知识点为RMAN不完全恢复流程。正确顺序是启动到mount、restore还原数据文件、recover应用归档日志到目标时间点、再以resetlogs打开。先recover后restore会因数据文件未还原而失败。数据库open后再recover不成立。先recover再restore顺序颠倒同样错误。 64. SQL Server中某数据库需设置每周日凌晨完整备份、每天凌晨差异备份，差异备份的基准是 A. 最近一次完整备份 B. 最近一次差异备份 C. 最近一次事务日志备份 D. 数据库创建时的初始状态 答案：A 解析：知识点为SQL Server差异备份原理。差异备份基于最近一次完整备份以来的所有变化页，正确。差异备份之间不互为基准。事务日志备份不影响差异备份基准。数据库初始状态仅在从未做过完整备份时才作为基准，实际运维中不这样使用。 65. 某DBA执行mysqldump全库备份时加上--single-transaction参数，其核心作用是 A. 保证InnoDB表备份期间获得一致性快照而不锁表 B. 将备份文件压缩为单个事务日志文件 C. 把备份操作放入一个事务中以便失败回滚 D. 使MyISAM表也支持无锁一致性读取 答案：A 解析：知识点：mysqldump一致性备份参数。--single-transaction在InnoDB上开启可重复读事务，获得一致性快照，避免全局读锁。它不负责压缩文件；备份失败回滚并非该参数作用；MyISAM不支持事务，该参数对MyISAM无一致性读取效果。 66. 数据库出现大量慢查询且innodb_buffer_pool命中率持续偏低时，最应优先核查的指标是 A. 缓冲池读命中率与磁盘物理读次数 B. 每秒提交事务数与回滚段数量 C. 连接线程缓存命中率与最大连接数 D. 二进制日志写入量与同步刷盘频率 答案：A 解析：知识点：InnoDB缓冲池性能诊断。命中率低且物理读高说明缓冲池不足或SQL扫描过多，应优先核查这两项。提交事务数与回滚段反映并发写压力；连接缓存与最大连接数反映连接层；binlog写入与刷盘反映持久化开销，均非命中率低的直接指标。 67. 某业务库误删一张核心表，binlog_format为ROW且已开启binlog，最合适的恢复方式是 A. 用最近全备加binlog按时间点恢复到误删前 B. 直接重启实例让InnoDB自动回滚该删除 C. 从从库执行反向DELETE把数据补回主库 D. 用undo日志把已提交的删除操作撤销 答案：A 解析：知识点：基于时间点的数据恢复。误删属已提交操作，需用全量备份加binlog做PITR恢复到删除前时点。重启无法回滚已提交事务；从库数据同样被同步删除；undo日志不能撤销已提交事务。 68. 为减少大批量导入对主从复制延迟的影响，较为合理的做法是 A. 分批提交并在每批之间做适当休眠 B. 把从库的同步模式改为异步并行 C. 导入前临时关闭主库的binlog写入 D. 将导入会话的事务隔离级别设为读未提交 答案：A 解析：知识点：大事务与复制延迟控制。分批提交加休眠可降低单事务体积、缓解从库回放压力。改从库同步模式不解决大事务回放慢；关闭主库binlog会导致从库无法同步；改隔离级别与复制延迟无直接关系。 69. 某实例配置了max_connections为500，业务高峰期频繁出现连接被拒，排查发现大量连接处于Sleep状态且长时间未释放，最有效的处置是 A. 检查应用连接池配置并设置空闲连接回收 B. 把max_connections直接调高到5000 C. 重启数据库实例释放全部空闲会话 D. 关闭wait_timeout让会话永不过期 答案：A 解析：知识点：连接数问题定位。Sleep连接堆积多因连接池未正确回收空闲连接，应先修连接池。盲目调大上限会掩盖问题并耗尽内存；重启只临时缓解；关闭超时会让空闲连接永久占用。 70. 在配置MySQL主从复制时，从库执行CHANGE MASTER TO需要指定的关键参数不包括 A. relay_log_purge B. MASTER_HOST C. MASTER_LOG_FILE D. MASTER_LOG_POS 答案：A 解析：知识点：主从复制配置参数。CHANGE MASTER TO需指定主库地址、binlog文件与位点等。relay_log_purge是控制中继日志清理的独立变量，不属于CHANGE MASTER TO的连接参数。 71. 针对OLTP库的慢查询优化，为某高频等值查询列建立索引后写入性能下降明显，最可能的原因是 A. 索引维护增加了每次写入的额外开销 B. 索引把查询计划强制改为全表扫描 C. 索引导致缓冲池命中率降为零 D. 索引使事务隔离级别被自动提升 答案：A 解析：知识点：索引的读写权衡。每增加一个索引，INSERT/UPDATE/DELETE都要维护对应B+树，写入开销上升。索引不会强制全表扫描，也不会使命中率归零或改变隔离级别。 72. 某企业要求核心库备份满足可恢复到任意时间点，且备份期间业务影响尽可能小，最合理的组合方案是 A. 周期性全备加持续binlog归档并定期演练恢复 B. 每天停库冷备一次并长期保留备份文件 C. 仅在每月初做一次逻辑全备不保留日志 D. 只依赖存储层快照且从不做恢复演练 答案：A 解析：知识点：备份策略设计。全备加binlog归档可实现PITR，定期演练验证可恢复性。每天停库冷备影响业务且无法恢复到任意点；每月一次逻辑备且不保留日志无法PITR；只靠快照不演练无法保证可恢复。 73. 以下关于数据库运行监控与日常巡检的做法中，合理的有 A. 定期采集慢查询日志并分析TOP SQL B. 对表空间与磁盘使用率设置阈值告警 C. 每天检查主从复制延迟与错误日志 D. 为省资源关闭错误日志只保留慢日志 E. 巡检发现锁等待后直接杀掉所有会话 答案：A、B、C 解析：知识点：数据库日常巡检与监控。采集慢日志、容量告警、检查复制与错误日志都是标准巡检项。关闭错误日志会丢失故障线索；发现锁等待应定位根因，直接杀全部会话会误伤正常业务。 74. 在Linux环境下为MySQL配置二进制日志以实现基于时间点的恢复，my.cnf中应设置的参数是 A. log-bin=mysql-bin B. binlog-format=ROW C. expire-logs-days=7 D. sync-binlog=1 答案：A 解析：知识点是二进制日志的启用参数。log-bin用于开启二进制日志并指定前缀，是基于时间点恢复的前提；binlog-format只决定记录格式，不负责开启日志；expire-logs-days仅控制日志过期清理；sync-binlog控制刷盘时机，也不开启日志。 75. 某DBA对生产库执行全量备份后，又需要恢复到当天下午误删数据前的状态，此时还应依赖下列哪类备份文件 A. 全量备份文件加二进制日志文件 B. 全量备份文件加错误日志文件 C. 全量备份文件加慢查询日志文件 D. 全量备份文件加表结构定义文件 答案：A 解析：知识点是基于时间点恢复的组成。全量备份提供基线，二进制日志记录备份后的所有变更，二者结合才能前滚到误删前一刻；错误日志只记录运行异常；慢查询日志记录执行慢的语句；表结构定义文件不含数据变更，均无法前滚数据。 76. 对MySQL执行mysqldump时希望备份结果包含建库语句且保证InnoDB表数据一致，应使用的参数组合是 A. --databases --single-transaction B. --no-create-db --lock-tables C. --databases --flush-logs D. --no-create-info --single-transaction 答案：A 解析：知识点是mysqldump一致性备份参数。--databases会生成CREATE DATABASE语句，--single-transaction在InnoDB上开启一致性快照且不锁表；--no-create-db反而不建库；--lock-tables会锁表且不保证跨表一致点；--no-create-info不导出建表语句。 77. PostgreSQL中要让归档日志持续可用以支持基于时间点恢复，postgresql.conf里必须把wal_level设置为 A. replica B. minimal C. logical D. archive 答案：A 解析：知识点是PostgreSQL的WAL级别。wal_level=replica及以上才保留归档所需的完整WAL信息；minimal会省略部分信息无法归档恢复；logical用于逻辑复制，虽可归档但并非必须项；archive不是合法取值。 78. 对InnoDB表执行大批量删除后表空间文件未缩小，正确的回收磁盘空间做法是 A. 执行OPTIMIZE TABLE重建表并释放空间 B. 执行ANALYZE TABLE更新统计信息 C. 执行FLUSH TABLES刷新表缓存 D. 调整innodb_file_per_table为OFF 答案：A 解析：知识点是InnoDB空间回收。删除只标记页可复用，需重建表才能归还操作系统，OPTIMIZE TABLE即做重建；ANALYZE TABLE只更新统计信息；FLUSH TABLES只刷新缓存；把innodb_file_per_table设为OFF会让新表共用系统表空间，更不利于回收。 79. 数据库服务器内存充足但频繁发生物理读，查看缓冲池命中率偏低，最有效的调优措施是 A. 适当增大innodb_buffer_pool_size B. 增大innodb_log_file_size C. 增大max_connections D. 开启query_cache_size 答案：A 解析：知识点是缓冲池调优。命中率低说明热数据未充分缓存，增大缓冲池可提升命中；日志文件大小影响写性能与恢复时间，不直接提升读命中；连接数上限与缓存无关；查询缓存已在新版本移除且不解决物理读问题。 80. 某运维在凌晨对核心库执行了全量备份，上午发现备份文件大小明显小于历史同期，正确的下一步处置是 A. 校验备份完整性与日志并重新执行一次备份 B. 直接把该备份文件归档留存备用 C. 仅记录该异常并等待下次例行备份 D. 将该备份复制到异地容灾中心保存 答案：A 解析：知识点是备份有效性验证。文件异常偏小提示备份可能不完整或失败，应先校验并重做；直接归档、仅记录、异地复制都会把不可用备份当可用，风险极高。 81. 数据库运行中监控到大量Waiting for table metadata lock，最可能的原因是 A. 存在未提交的长事务持有该表元数据锁 B. 磁盘剩余空间不足触发写入阻塞 C. 缓冲池过小导致页换出频繁 D. 二进制日志文件数量超过上限 答案：A 解析：知识点是元数据锁等待。长事务未提交会持续持有MDL，导致后续DDL或访问排队；磁盘不足表现为写错误；缓冲池过小表现为IO等待；binlog数量上限触发的是清理而非MDL等待。 82. 为保证MySQL备份可恢复，日常运维中应当落实的做法包括哪些 A. 定期做恢复演练验证备份可用性 B. 备份文件与数据库主机分开存放 C. 开启binlog并定期归档保存 D. 仅保留最近一次全量备份其余删除 E. 备份完成后立即用生产库覆盖验证 答案：A、B、C 解析：知识点是备份可恢复性保障。恢复演练能验证备份真实可用；异地分开存放避免同故障域损毁；binlog归档支持时间点恢复。只保留最近一次全量会失去回退点；用生产库覆盖验证会破坏生产数据，均不可取。 83. 在Linux服务器上通过源码编译方式安装MySQL 8.0后，执行初始化命令时指定的--initialize参数与--initialize-insecure参数的核心区别是什么 A. 前者生成随机root密码并写入错误日志，后者生成空密码root账户 B. 前者生成空密码root账户，后者生成随机root密码并写入错误日志 C. 前者仅创建系统表空间，后者同时创建系统表空间和用户表空间 D. 前者要求已存在数据目录，后者会自动创建数据目录 答案：A 解析：知识点：MySQL 8.0初始化参数区别。--initialize生成随机临时密码写入error log，--initialize-insecure生成空密码root账户。错误项B把两者功能对调；错误项C混淆了表空间创建逻辑，两个参数都会创建系统表空间；错误项D错误，两个参数都要求数据目录为空且会自动创建。 84. 某DBA对MySQL执行mysqldump全库逻辑备份时添加了--single-transaction参数，该参数在InnoDB表上保证备份一致性的原理是什么 A. 在备份开始时开启一个可重复读事务并导出该事务快照 B. 对所有表逐个加表级读锁后依次导出数据 C. 在备份期间禁止其他会话写入以保证数据静止 D. 将InnoDB表临时转换为MyISAM表再导出 答案：A 解析：知识点：mysqldump一致性快照原理。--single-transaction在REPEATABLE READ隔离级别下启动事务，利用MVCC获得一致性快照。错误项B描述的是--lock-tables行为；错误项C描述的是--lock-all-tables效果，会阻塞写入；错误项D是错误做法，转换存储引擎会导致丢失事务特性。 85. PostgreSQL中执行pg_basebackup进行基础备份时，若希望备份期间数据库仍可正常读写且备份包含所有WAL日志，应配合使用哪个参数组合 A. -Ft -z -P B. -Xs -P -R C. -Fp -c fast D. -Xf -z -v 答案：B 解析：知识点：pg_basebackup参数。-Xs表示在备份中流式传输所需WAL，-P显示进度，-R自动生成recovery配置。错误项A使用tar格式打包且未流式传输WAL；错误项C的-c fast是pg_dump参数不适用于pg_basebackup；错误项D的-Xf会在备份结束时才取WAL，若期间WAL被回收则备份不可用。 86. Oracle数据库中，当执行RMAN备份时发现控制文件自动备份未生效，需要检查哪个参数确保控制文件随备份自动保存 A. CONTROL_FILE_RECORD_KEEP_TIME B. CONFIGURE CONTROLFILE AUTOBACKUP ON C. DB_RECOVERY_FILE_DEST_SIZE D. LOG_ARCHIVE_DEST_STATE_2 答案：B 解析：知识点：RMAN控制文件自动备份配置。CONFIGURE CONTROLFILE AUTOBACKUP ON是RMAN命令用于开启控制文件自动备份。错误项A是控制文件记录保留天数参数；错误项C是快速恢复区大小限制；错误项D是归档日志目标状态参数，均与控制文件自动备份开关无关。 87. 数据库性能监控中发现InnoDB缓冲池命中率持续低于90%，经排查物理内存充足，此时最应优先调整哪个参数来提升命中率 A. innodb_log_file_size B. innodb_buffer_pool_size C. innodb_flush_log_at_trx_commit D. innodb_io_capacity 答案：B 解析：知识点：InnoDB缓冲池调优。命中率低说明缓冲池容量不足以缓存热点数据，应增大innodb_buffer_pool_size。错误项A调整重做日志文件大小影响写入性能但不直接提升命中率；错误项C控制事务提交刷盘策略，影响持久性；错误项D控制后台IO吞吐量，与缓存命中率无直接关系。 88. SQL Server中某查询执行计划显示出现Key Lookup操作且开销占比很高，最有效的优化手段是什么 A. 为该查询涉及的过滤列创建非聚集索引并包含输出列 B. 将该查询涉及的表改为堆表以消除聚集索引 C. 增加max server memory参数值扩大缓冲池 D. 对该查询使用OPTION (MAXDOP 1)限制并行度 答案：A 解析：知识点：SQL Server Key Lookup优化。Key Lookup是因为非聚集索引未覆盖查询所需列，需回聚集索引取数据，创建覆盖索引（INCLUDE输出列）可消除。错误项B改为堆表会引入RID Lookup，问题依旧；错误项C扩大内存不解决索引覆盖问题；错误项D限制并行度不影响查找方式。 89. 某MySQL从库出现主从复制延迟持续增大，检查发现relay log应用线程状态为Waiting for dependent transaction to commit，最可能的原因是什么 A. 从库开启了并行复制但事务间存在依赖等待 B. 主库binlog格式为STATEMENT导致从库无法并行 C. 从库磁盘IO性能不足导致relay log写入缓慢 D. 主从之间网络带宽不足导致binlog传输延迟 答案：A 解析：知识点：MySQL并行复制依赖等待。该状态出现在多线程复制（MTS）场景，表示工作线程等待依赖事务提交。错误项B若为STATEMENT格式仍可并行但效率不同，不是该状态原因；错误项C会导致IO线程延迟而非该等待状态；错误项D影响的是IO线程传输，与SQL应用线程依赖等待无关。 90. 在Redis中执行BGSAVE时，子进程因写时复制机制导致内存占用突增，为避免触发OOM Killer，运维中最合理的预防措施是什么 A. 设置maxmemory并预留约一半内存用于COW开销 B. 关闭RDB持久化仅使用AOF方式保存数据 C. 将save参数调整为每秒钟触发一次快照 D. 把appendfsync设置为no以减少磁盘写入 答案：A 解析：知识点：Redis BGSAVE写时复制内存开销。COW机制在写操作频繁时可能使内存接近翻倍，应预留内存并设置maxmemory。错误项B关闭RDB改用AOF不能避免AOF重写时的类似COW问题；错误项C提高快照频率会加重COW；错误项D调整appendfsync影响的是AOF刷盘策略，与BGSAVE内存无关。 91. MongoDB副本集中，某次要节点持续处于RECOVERING状态无法转为SECONDARY，检查oplog发现其落后主节点超过oplog窗口，正确的恢复处置是什么 A. 对该节点执行rs.syncFrom指定主节点强制同步 B. 停止该节点清空数据目录后重新加入副本集进行全量同步 C. 在主节点执行rs.stepDown触发重新选举 D. 增大该节点oplogSizeMB后重启等待自动追平 答案：B 解析：知识点：MongoDB副本集落后节点恢复。当节点落后超过oplog窗口无法增量同步时，需清空数据目录重新初始同步。错误项A的rs.syncFrom仅改变同步源不能弥补缺失的oplog；错误项C主节点降级不影响落后节点同步；错误项D增大oplog只对将来有效，已丢失的历史oplog无法恢复。 92. 数据库备份策略中采用全量备份加增量备份加差异备份组合时，差异备份与增量备份的本质区别是什么 A. 差异备份基于上次全量，增量备份基于上次任意类型备份 B. 差异备份基于上次任意类型备份，增量备份基于上次全量备份 C. 差异备份和增量备份均基于上次全量备份，仅压缩算法不同 D. 差异备份仅备份数据文件，增量备份仅备份日志文件 答案：A 解析：知识点：差异备份与增量备份定义。差异备份始终基于最近一次全量备份，增量备份基于最近一次任意备份（全量或增量）。错误项B将两者定义对调；错误项C错误认为两者都基于全量；错误项D混淆了备份内容与备份类型的区别，差异和增量都可包含数据和日志。 93. 在制定数据库备份恢复策略时，以下哪些做法有助于满足恢复点目标RPO和恢复时间目标RTO的要求 A. 根据业务重要性对数据库分级并设置不同的备份频率 B. 定期执行恢复演练验证备份文件的可恢复性 C. 将备份文件与数据库主机放置在同一物理存储上 D. 对关键库采用全量加日志备份并保留足够长的日志链 E. 仅依赖数据库自带的快照功能而不做逻辑备份 答案：A、B、D 解析：知识点：备份恢复策略与RPO/RTO。分级备份、恢复演练、全量加日志链均有助于缩短恢复时间并减少数据丢失。错误项C将备份与数据库同存储，一旦存储故障备份同时丢失，不满足容灾要求；错误项E仅依赖快照无法应对逻辑损坏，且快照不能替代逻辑备份的灵活性。 94. 在MySQL 8.0中安装完成后，要查看当前实例的错误日志文件路径，应优先使用哪条命令 A. SHOW VARIABLES LIKE 'log_error' B. SHOW VARIABLES LIKE 'general_log_file' C. SHOW VARIABLES LIKE 'slow_query_log_file' D. SHOW VARIABLES LIKE 'binlog_error_action' 答案：A 解析：知识点是MySQL错误日志参数定位。log_error变量记录错误日志文件路径，是排查启动与运行故障的首要入口；general_log_file是通用查询日志路径，记录所有语句而非错误；slow_query_log_file是慢查询日志路径；binlog_error_action是二进制日志写入失败时的行为策略，不是日志文件路径。 95. 某DBA对MySQL执行mysqldump时只加了--single-transaction，未加--master-data，在InnoDB表上做一致性快照备份时仍可能遗漏哪类内容 A. 备份期间新建表的DDL变更 B. 已提交事务的数据行 C. 未提交事务的脏数据 D. InnoDB缓冲池未刷盘页 答案：A 解析：知识点是一致性快照备份的边界。--single-transaction对InnoDB开启可重复读事务保证已提交数据一致，但不阻塞DDL，备份期间新建表或改表结构可能不会出现在dump中；已提交事务数据在快照内一致；未提交事务本就不会写入备份；缓冲池未刷盘页由InnoDB自身一致性保证。 96. Oracle数据库运行在ARCHIVELOG模式，某表空间数据文件所在磁盘损坏，恢复时提示需要应用归档日志，此时正确的介质恢复顺序是 A. 启动到MOUNT，还原数据文件，再RECOVER DATABASE B. 启动到OPEN，还原数据文件，再RECOVER DATABASE C. 启动到NOMOUNT，还原数据文件，再RECOVER DATABASE D. 启动到MOUNT，RECOVER DATABASE，再还原数据文件 答案：A 解析：知识点是归档模式下介质恢复流程。需先MOUNT加载控制文件，再还原受损数据文件，然后RECOVER应用归档与在线日志；OPEN状态无法还原数据文件；NOMOUNT阶段控制文件未加载无法定位文件；先RECOVER再还原数据文件会导致恢复找不到还原后的文件。 97. MySQL从库出现Seconds_Behind_Master持续为0但业务读到旧数据，经查从库SQL线程正常，最可能的原因是 A. 从库开启了多线程复制且未等待所有worker执行完 B. 从库relay log损坏导致SQL线程跳过事务 C. 主库binlog格式为ROW导致无法复制 D. 从库read_only参数未开启 答案：A 解析：知识点是多线程复制的一致性观察。Seconds_Behind_Master为0只表示SQL线程已消费完当前relay log，多线程复制下worker可能尚未全部提交，导致读到旧数据；relay log损坏会报错而非静默为0；ROW格式是正常复制格式；read_only只影响写入，不影响读到旧数据。 98. 某生产库在业务高峰期出现大量latch free等待，AWR显示shared pool争用严重，作为DBA首先应考虑的调优动作是 A. 检查绑定变量使用情况并减少硬解析 B. 增大db_cache_size以缓存更多数据块 C. 调整db_writer_processes提升写盘并发 D. 修改optimizer_mode切换优化器模式 答案：A 解析：知识点是shared pool争用与硬解析关系。大量latch free伴随shared pool争用通常由硬解析过多引起，检查绑定变量、减少硬解析是首要动作；db_cache_size针对数据块缓冲，与shared pool争用无直接关系；db_writer_processes影响写盘；optimizer_mode改变执行计划生成策略，不解决解析争用。 99. 某MySQL实例的InnoDB缓冲池命中率长期低于90%，经查物理内存充足且未发生swap，在不改变SQL语句的前提下，下列调优措施中最先应评估的是 A. 适当增大innodb_buffer_pool_size并观察命中率变化 B. 开启innodb_buffer_pool_dump_at_shutdown减少预热时间 C. 将innodb_flush_log_at_trx_commit调整为0以降低刷盘 D. 增大innodb_log_file_size以减少日志切换次数 答案：A 解析：知识点：InnoDB缓冲池命中率低通常说明热数据无法充分驻留内存，在物理内存充足时应优先评估增大innodb_buffer_pool_size。A正确：缓冲池过小是命中率低的常见根因，扩容后命中率会直接改善。B错在dump/load机制只影响重启后的预热速度，不改变运行期命中率。C错在降低刷盘安全性只影响日志写入，与缓冲池命中率无直接关系。D错在日志文件大小影响检查点频率，不解决数据页缓存不足问题。 100. 某生产库每日凌晨2点执行全量逻辑备份，运维人员发现近一周备份耗时从40分钟逐步增至3小时且未报错，下列排查与处置措施中合理的有 A. 检查备份期间是否有大批量导入或统计任务与备份窗口重叠 B. 确认备份输出目录所在磁盘的可用空间与写入延迟 C. 查看数据库慢查询日志中备份语句是否出现全表扫描异常 D. 将备份时间改到业务高峰以利用缓存加速导出 E. 直接关闭binlog以降低备份期间日志写入开销 答案：A、B、C 解析：知识点：备份耗时逐步增长属于性能劣化，应从并发负载、存储I/O和SQL执行计划三方面排查。A合理：备份窗口与其他批量任务重叠会争抢I/O和锁资源。B合理：输出目录磁盘空间不足或写入延迟升高会显著拖慢导出。C合理：逻辑备份语句若执行计划劣化会出现异常扫描，直接拉长耗时。D错在改到业务高峰会加重锁竞争与I/O压力，通常使备份更慢。E错在关闭binlog会破坏恢复链与主从复制，且并非耗时增长的合理处置。 101. 在Linux上安装MySQL 8.0后，希望数据目录使用独立挂载的/data分区并启用二进制日志，下列配置组合最合理的是 A. datadir=/data/mysql，log-bin=/data/mysql/binlog，并确保/data分区属主为mysql B. datadir=/var/lib/mysql，log-bin=/data/binlog，并确保/data分区属主为root C. datadir=/data/mysql，log-bin=/var/lib/mysql/binlog，并确保/data分区属主为mysql D. datadir=/data/mysql，log-bin=/data/binlog，并确保/data分区属主为root 答案：A 解析：知识点：MySQL数据目录与二进制日志路径配置及权限要求。正确项将datadir和log-bin都放在独立数据分区并赋予mysql属主，符合安装规范并保证写入权限。错误项B的datadir仍在系统盘且属主root会导致初始化失败；错误项C把二进制日志留在系统盘，未达到独立分区的目的；错误项D属主为root，mysql进程无写权限。 102. 某业务库慢查询日志显示大量语句在等待innodb行锁，查询执行计划本身走索引正常，优先排查的方向是 A. 长事务未提交导致锁持有时间过长 B. 缓冲池命中率是否偏低 C. redo log文件是否过小 D. 是否开启了查询缓存 答案：A 解析：知识点：InnoDB锁等待的定位。执行计划正常却等行锁，通常是事务未及时提交使锁长期持有。缓冲池命中率影响物理读，不直接造成行锁等待；redo log过小影响刷盘效率；查询缓存与行锁等待无直接关系。 103. 对MySQL全量备份加binlog实现时间点恢复时，恢复顺序的正确做法是 A. 先恢复最近一次全量备份，再按顺序重放该备份之后的binlog B. 先重放binlog到故障点，再导入全量备份覆盖 C. 先恢复全量备份，再重放故障点之前任意一段binlog D. 先重放所有历史binlog，再导入最近一次全量备份 答案：A 解析：知识点：基于全量备份加binlog的时间点恢复流程。必须以全量备份为基线，再按binlog顺序增量重放至目标时间点。先重放binlog会被全量覆盖丢失增量；只重放任意一段无法连续；先重放再导入全量等于丢弃增量。 104. Oracle数据库中执行RMAN备份时，希望归档日志在备份完成后自动删除已备份的部分，应使用 A. BACKUP ARCHIVELOG ALL DELETE INPUT B. BACKUP ARCHIVELOG ALL KEEP INPUT C. BACKUP DATABASE PLUS ARCHIVELOG SKIP INACCESSIBLE D. BACKUP ARCHIVELOG ALL NOT BACKED UP 答案：A 解析：知识点：RMAN归档日志备份后的清理选项。DELETE INPUT表示备份成功后删除已备份的归档日志。KEEP INPUT是保留不删；SKIP INACCESSIBLE是跳过不可访问文件；NOT BACKED UP是只备份尚未备份过的归档，三者都不实现备份后删除。 105. 数据库服务器内存充足但InnoDB缓冲池命中率持续偏低，排查时首先应确认 A. 缓冲池大小是否与实际热数据量匹配 B. redo log是否设置为循环写入 C. 表是否全部使用MyISAM引擎 D. 二进制日志格式是否为ROW 答案：A 解析：知识点：InnoDB缓冲池命中率影响因素。命中率低最直接的原因是缓冲池容量小于热数据规模。redo log写入方式影响持久化性能；MyISAM不使用InnoDB缓冲池；binlog格式影响复制与日志量，均不直接决定缓冲池命中率。 106. 对生产库执行DDL变更前，DBA先检查information_schema中表的数据量与是否存在长事务，这一操作的主要目的是 A. 评估DDL可能持锁时间及对业务的影响 B. 确认表字符集是否需要统一 C. 验证备份文件是否可以解压 D. 检查磁盘剩余空间是否够归档 答案：A 解析：知识点：DDL变更前的风险评估。数据量和长事务直接决定DDL加锁与元数据锁等待时长，进而影响业务。字符集、备份解压、磁盘空间虽需关注，但不是该检查的核心目的。 107. 某MySQL实例的innodb_log_file_size设置过小，在高并发写入场景下最可能出现的现象是 A. 频繁检查点导致写入性能波动 B. 缓冲池中脏页无法刷新 C. binlog写入被阻塞 D. 临时表空间持续增长 答案：A 解析：知识点：redo log大小对写入性能的影响。log file过小会触发更频繁的检查点与刷脏，造成性能抖动。缓冲池刷脏由多种机制控制，并非无法刷新；binlog写入与redo大小无直接阻塞关系；临时表空间增长多与排序、大查询相关。 108. 在PostgreSQL中执行pg_basebackup做基础备份时，希望备份过程不阻塞其他会话的写入，应确保 A. 数据库处于归档模式且使用普通备份模式 B. 数据库处于非归档模式且使用快速模式 C. 数据库处于归档模式且使用排他备份模式 D. 数据库处于非归档模式且关闭WAL写入 答案：A 解析：知识点：PostgreSQL基础备份与归档模式。pg_basebackup在归档模式下以非排他方式运行，不阻塞写入。非归档模式下无法完成可用于恢复的基础备份；排他备份模式会阻塞其他连接；关闭WAL写入不可行。 109. 生产库夜间执行全量逻辑备份时磁盘空间告警，备份文件写到一半失败，正确的后续处置是 A. 清理无用文件释放空间后重新执行完整备份并校验 B. 直接对失败文件做压缩后当作可用备份保留 C. 从失败点继续追加写入剩余表数据 D. 删除失败文件后仅依赖该库的binlog恢复 答案：A 解析：知识点：备份失败后的处置原则。备份不完整即不可用，应释放空间后重做并校验。压缩失败文件不能补齐缺失数据；追加写入无法保证一致性；仅靠binlog缺少基线无法完整恢复。 110. 在Linux服务器上通过源码方式完成MySQL初始化后，首次启动前需要确认数据目录的属主，通常应设置为哪个用户 A. mysql B. root C. nobody D. daemon 答案：A 解析：知识点：数据库安装配置中的目录权限。MySQL数据目录必须由运行数据库进程的专用用户mysql拥有，才能正常读写表空间和日志。root属主会导致以mysql身份启动时无写权限；nobody和daemon是系统内置低权限账户，并非数据库服务账户，无法保证服务正常访问数据文件。 111. 某DBA为生产库配置物理备份时，将备份集与数据库数据文件放在同一块物理磁盘上，这种做法最直接的风险是 A. 备份时锁表时间变长 B. 磁盘故障导致数据与备份同时丢失 C. 备份文件校验速度下降 D. 恢复时无法使用增量备份 答案：B 解析：知识点：备份恢复的存储隔离原则。备份与数据同盘时，一旦该磁盘损坏，原始数据和备份会一起损毁，失去容灾意义。锁表时间取决于备份方式和事务，与存放位置无直接关系；校验速度主要受I/O和算法影响；增量备份能否使用取决于备份类型与日志，与存放磁盘无关。 112. 对一张千万级大表做全表扫描的统计查询，发现执行计划走了顺序扫描而非索引扫描，最可能的原因是 A. 索引被设置为不可见 B. 该查询返回的行数占表比例很高 C. 表的统计信息被关闭 D. 数据库处于只读模式 答案：B 解析：知识点：执行计划与索引选择。当查询需要返回大部分数据行时，优化器评估顺序扫描比走索引再回表成本更低，属于合理选择。索引不可见、统计信息关闭、只读模式都会影响计划，但题干已说明是统计类大范围查询，比例高才是走顺序扫描的典型原因。 113. 某数据库每日凌晨做全量备份，某天上午误删了一张表，最合适的恢复思路是 A. 直接用前一天全量备份覆盖当前实例 B. 用全量备份加归档日志恢复到误删前的时间点 C. 只恢复被删表的表空间文件 D. 重启实例让数据库自动回滚恢复 答案：B 解析：知识点：时间点恢复。全量备份加归档日志可恢复到误操作前的精确时间点，最大限度减少数据丢失。直接用前一天备份覆盖会丢失当天所有变更；只恢复表空间文件无法保证一致性；重启不能恢复已被提交的删除操作，回滚只处理未提交事务。 114. 在Oracle中调整SGA_TARGET启用自动共享内存管理后，还需要手动设置的最小参数是 A. SGA_MAX_SIZE B. DB_CACHE_SIZE C. SHARED_POOL_SIZE D. LOG_BUFFER 答案：A 解析：知识点：内存参数配置。启用自动共享内存管理时，SGA_MAX_SIZE决定SGA可扩展的上限，需要设置。DB_CACHE_SIZE、SHARED_POOL_SIZE在自动管理下由系统动态调整，无需手动指定；LOG_BUFFER有默认值且不参与自动共享内存调整。 115. 监控发现数据库磁盘I/O等待时间持续偏高，而CPU使用率不高，首先应排查的方向是 A. 增加应用连接池大小 B. 检查慢查询与缺失索引 C. 调大排序缓冲区 D. 重启数据库释放内存 答案：B 解析：知识点：性能瓶颈定位。I/O等待高而CPU低，常见原因是低效查询导致大量物理读，应先查慢查询和缺失索引。增大连接池会加重I/O压力；排序缓冲区只影响排序操作，未必是主因；重启只是临时缓解，无法解决根因。 116. 为数据库配置定时逻辑备份脚本时，将备份文件命名为固定名称并每天覆盖，这种做法的主要问题是 A. 备份文件体积会不断增大 B. 无法回溯到更早的备份版本 C. 备份速度会逐日下降 D. 备份文件权限会被重置 答案：B 解析：知识点：备份策略与保留周期。固定文件名每天覆盖后只剩最新一份，一旦最新备份损坏或数据被污染，就没有历史版本可回退。体积、速度、权限不会因固定命名而必然恶化，核心风险是失去多版本保留能力。 117. 在MySQL主从复制环境中，从库出现Seconds_Behind_Master持续增大，首先应检查的是 A. 从库磁盘剩余空间是否充足 B. 主库是否开启了binlog C. 从库是否开启了慢查询日志 D. 主从server_id是否相同 答案：A 解析：知识点：复制延迟排查。从库磁盘空间不足会导致relay log写入或SQL线程应用受阻，是延迟增大的常见原因。主库未开binlog则复制根本无法建立；慢查询日志只是记录，不直接导致延迟；server_id相同会导致复制启动报错而非延迟累积。 118. 某电商大促前，DBA对订单库做压测，发现连接数达到上限后新请求被拒绝，此时最合理的处置是 A. 直接把最大连接数调到极高值 B. 结合业务评估调整连接数并优化连接复用 C. 关闭慢查询日志释放资源 D. 将数据库切换为只读模式 答案：B 解析：知识点：情境案例中的连接数治理。盲目调高最大连接数会耗尽内存和CPU，应结合业务评估并优化连接池复用。关闭慢查询日志对连接数帮助有限；只读模式会中断下单业务；直接调到极高值属于治标不治本且可能引发更严重故障。 119. 在Linux环境下安装MySQL 8.0时，需要指定数据目录为/data/mysql且禁止符号链接，应使用哪个初始化参数组合 A. mysqld --initialize --datadir=/data/mysql --no-symlinks B. mysqld --initialize-insecure --basedir=/data/mysql --skip-symbolic-links C. mysqld --install --datadir=/data/mysql --disable-symlinks D. mysqld --initialize --basedir=/data/mysql --skip-symbolic-links 答案：A 解析：知识点：MySQL初始化参数。--initialize生成随机root密码，--datadir指定数据目录，--no-symlinks禁止符号链接。错误项：--initialize-insecure不设密码且basedir指向数据目录错误；--install是注册服务不执行初始化且--disable-symlinks参数不存在；--initialize正确但basedir应为软件安装目录而非数据目录，--skip-symbolic-links非初始化参数。 120. 某DBA在配置PostgreSQL的pg_hba.conf时，希望允许192.168.1.0/24网段通过md5认证访问所有数据库，应写入的规则是 A. host all all 192.168.1.0/24 md5 B. host all all 192.168.1.0 255.255.255.0 md5 C. local all all 192.168.1.0/24 md5 D. host all all 192.168.1.0/24 trust 答案：A 解析：知识点：pg_hba.conf规则格式。正确格式为TYPE DATABASE USER ADDRESS METHOD，CIDR可直接写。错误项：PostgreSQL的pg_hba.conf不支持点分掩码写法；local仅用于Unix域套接字不能带IP；trust为免密认证非md5。 121. 对MySQL执行逻辑备份时，需要保证备份数据与binlog位置一致以支持时间点恢复，mysqldump应搭配哪个参数 A. --single-transaction --master-data=2 B. --lock-all-tables --flush-logs C. --single-transaction --flush-privileges D. --quick --hex-blob --events 答案：A 解析：知识点：mysqldump一致性备份。--single-transaction在InnoDB下提供一致性快照，--master-data=2将binlog位置以注释写入备份文件。错误项：--lock-all-tables会全程锁表，且未记录binlog位置；--flush-privileges只重载权限表；--quick/--hex-blob/--events与binlog位置记录无关。 122. SQL Server完整恢复模式下，日志文件持续增长且空间告急，业务要求仍能恢复到任意时间点，应优先执行的操作是 A. 执行事务日志备份以截断不活动日志 B. 将恢复模式改为简单模式收缩日志 C. 直接收缩日志文件释放未使用空间 D. 分离数据库后删除日志文件再附加 答案：A 解析：知识点：SQL Server日志截断机制。完整恢复模式下只有日志备份才会截断不活动VLF，从而支持时间点恢复。错误项：改为简单模式会破坏日志链无法时间点恢复；直接收缩日志不截断不活动部分效果有限；删除日志文件会破坏数据库一致性。 123. 在Redis中执行BGSAVE生成RDB快照期间，主进程对写命令的处理方式是 A. 将写命令追加到AOF缓冲区并继续服务 B. 阻塞所有写命令直到快照完成 C. 将写命令写入临时文件待快照后合并 D. 拒绝写命令并返回错误给客户端 答案：A 解析：知识点：Redis持久化机制。BGSAVE通过fork子进程写RDB，主进程继续处理写命令并记录到AOF缓冲区（若开启AOF）。错误项：阻塞写命令是SAVE的行为；写临时文件合并不是Redis快照机制；BGSAVE期间不会拒绝写命令。 124. MongoDB副本集中主节点写入数据后，从节点通过什么机制同步oplog并应用操作 A. 从节点持续拉取主节点oplog并按时间戳应用 B. 主节点主动推送变更到所有从节点 C. 从节点定期全量复制整个数据集 D. 仲裁节点转发主节点写入到从节点 答案：A 解析：知识点：MongoDB复制机制。从节点通过tailable cursor持续拉取主节点local.oplog.rs并按ts应用。错误项：主节点不主动推送；全量复制仅在初次同步时发生；仲裁节点不参与数据同步只参与选举投票。 125. 凌晨2点某生产库误执行DELETE未带WHERE条件删除了整张表且已提交，数据库开启binlog格式为ROW，正确的恢复步骤是 A. 用最近全备+binlog恢复到误删前的时间点 B. 用最近全备+redo日志前滚到误删后 C. 直接对表执行闪回查询恢复删除行 D. 用从库延迟复制数据覆盖主库 答案：A 解析：知识点：基于时间点恢复。ROW格式binlog记录了行变更，可通过全备加binlog回放到误删前。错误项：redo日志不能跨备份恢复误删；闪回查询依赖undo且已提交删除可能超保留期；从库延迟复制需预先配置且会覆盖最新数据。 126. 某DBA对生产库执行了全量备份后，又持续归档了binlog，当需要恢复到昨天下午3点的状态时，正确的恢复顺序是 A. 先恢复全量备份，再按时间点重放binlog到指定时刻 B. 先重放binlog到指定时刻，再恢复全量备份覆盖 C. 只恢复全量备份即可，binlog用于主从同步不做恢复 D. 先恢复全量备份，再重放全部binlog到最新时刻 答案：A 解析：知识点：基于备份加binlog的时间点恢复（PITR）。正确项：先还原全量备份作为基线，再用mysqlbinlog按时间范围重放至目标时刻，才能精确恢复到指定时间点。错误项B：顺序颠倒，binlog重放必须在备份还原之后。错误项C：忽略binlog会导致只能恢复到备份时刻，丢失后续数据。错误项D：重放到最新时刻会包含目标时刻之后的误操作，无法精确回退。 127. 使用mysqldump备份InnoDB表时，为保证备份数据的一致性，通常需要配合使用的参数是 A. --lock-tables --single-transaction B. --single-transaction --master-data C. --skip-lock-tables --flush-logs D. --lock-all-tables --quick 答案：B 解析：知识点：mysqldump一致性备份参数。正确项：--single-transaction利用InnoDB的MVCC快照保证一致性且不锁表，--master-data记录binlog位点便于搭建从库或PITR。错误项A：--lock-tables会对每张表加读锁，与--single-transaction语义冲突且阻塞写入。错误项C：--skip-lock-tables不保证一致性，--flush-logs只是切日志。错误项D：--lock-all-tables会全局锁表，生产环境影响大，且与--quick组合并非一致性首选。 128. 在MySQL中执行SHOW ENGINE INNODB STATUS查看锁等待时，发现大量事务处于LOCK WAIT状态，最应优先排查的方向是 A. 检查innodb_buffer_pool_size是否过小导致页换入换出 B. 检查是否存在未提交的长事务或缺失索引导致的行锁升级 C. 检查binlog_format是否为ROW影响锁粒度 D. 检查max_connections是否达到上限引发连接排队 答案：B 解析：知识点：InnoDB锁等待的常见成因。正确项：长事务不提交会持续持有行锁，缺失索引会使扫描范围扩大从而锁住更多行，是锁等待最直接的原因。错误项A：buffer pool过小影响的是IO性能，不直接造成LOCK WAIT。错误项C：binlog_format影响日志内容与复制，不改变InnoDB行锁等待。错误项D：连接数上限导致的是连接被拒，而非锁等待。 129. 某数据库服务器磁盘IO持续100%但CPU利用率很低，慢查询日志中大量出现全表扫描语句，最有效的优化措施是 A. 增加innodb_buffer_pool_size并针对WHERE列建立索引 B. 提高max_connections并开启查询缓存 C. 调整innodb_flush_log_at_trx_commit为2以减少刷盘 D. 将binlog_format从ROW改为STATEMENT 答案：A 解析：知识点：IO瓶颈与慢查询的联合诊断。正确项：全表扫描导致大量物理读，扩大buffer pool提高缓存命中，配合索引减少扫描行数，是针对性措施。错误项B：查询缓存已被MySQL 8.0移除，且与IO瓶颈无直接关系。错误项C：调整刷盘参数降低的是日志写入频率，不能解决全表扫描的读放大。错误项D：binlog格式影响日志体积与复制，不改变查询的IO模式。 130. 数据库服务器内存充足但innodb_buffer_pool命中率长期低于90%，且业务查询以范围扫描为主，优先调整的参数组合是 A. 增大innodb_buffer_pool_size并延长innodb_old_blocks_time B. 减小innodb_buffer_pool_instances以减少竞争 C. 增大innodb_log_file_size并降低innodb_io_capacity D. 关闭innodb_adaptive_hash_index以节省内存 答案：A 解析：知识点：buffer pool命中率优化。正确项：扩大buffer pool可缓存更多数据页，延长old_blocks_time可减少全表扫描等一次性读取对热数据的冲刷，提升命中率。错误项B：减少instances会加剧并发访问竞争，不利于命中率。错误项C：日志文件大小与IO容量影响的是写入性能，不直接提升读命中率。错误项D：自适应哈希索引对等值查询有帮助，关闭它不会提升命中率。 131. 在Linux环境下安装MySQL后，首次启动服务前需要初始化数据目录，以下关于初始化命令与参数配合的描述中正确的是 A. mysqld --initialize会生成随机root密码并写入错误日志 B. mysqld --initialize-insecure会生成随机root密码并写入错误日志 C. mysqld --initialize会创建空密码root账户并允许直接登录 D. mysqld --initialize-insecure会拒绝启动直到手动设置root密码 答案：A 解析：知识点：MySQL数据目录初始化方式。--initialize生成临时随机root密码并记录到错误日志，故A正确；--initialize-insecure创建空密码root账户，不会生成随机密码，故B错；--initialize并非创建空密码账户，故C错；--initialize-insecure不会因未设密码而拒绝启动，故D错。 132. 对MySQL执行逻辑备份时，若希望导出结果中包含建库语句且保证主从复制位点信息一致，应选择的mysqldump参数组合是 A. --databases --single-transaction --master-data=2 B. --all-databases --lock-tables --master-data=1 C. --databases --single-transaction --flush-logs D. --all-databases --lock-all-tables --source-data=2 答案：A 解析：知识点：mysqldump备份参数。--databases会生成CREATE DATABASE语句，--single-transaction配合--master-data=2可在不锁表情况下记录位点，故A正确；--lock-tables会逐表锁且与一致性位点配合不佳，故B错；--flush-logs只切日志不记录位点，故C错；--lock-all-tables会全库锁表，不符合单事务一致性备份意图，故D错。 133. MySQL中执行START SLAVE后从库长期处于Connecting状态，且错误日志提示认证失败，最合理的下一步处置是 A. 在从库执行CHANGE MASTER TO更新复制账号与密码后重新启动复制 B. 在从库执行RESET SLAVE ALL清除中继日志后直接重启复制 C. 在主库执行FLUSH PRIVILEGES并重启主库服务 D. 在从库调整relay_log_recovery参数为ON后重启复制 答案：A 解析：知识点：MySQL复制认证故障处理。认证失败需更新复制账号凭据，故A正确；RESET SLAVE ALL只清元数据，不解决认证问题，故B错；主库刷新权限不会修复从库使用的错误凭据，故C错；relay_log_recovery处理中继日志损坏恢复，与认证无关，故D错。 134. 对数据库执行全量备份后，为缩短恢复时间同时保留按时间点恢复能力，通常应配套采用的备份策略是 A. 全量备份加持续归档的二进制日志 B. 全量备份加定期增量备份且关闭二进制日志 C. 全量备份加每日差异备份且关闭二进制日志 D. 全量备份加逻辑导出且仅保留最近一次 答案：A 解析：知识点：备份恢复策略。全量加持续归档binlog可实现任意时间点恢复，故A正确；关闭binlog会失去时间点恢复能力，故B错；关闭binlog同样无法按时间点恢复，故C错；仅保留最近一次逻辑导出无法回溯到中间时间点，故D错。 135. PostgreSQL中执行pg_basebackup进行基础备份时，若希望备份过程不阻塞其他会话的写入，应确保实例处于的工作模式是 A. 归档模式且wal_level为replica或更高 B. 归档模式且wal_level为minimal C. 非归档模式且开启hot_standby D. 非归档模式且关闭full_page_writes 答案：A 解析：知识点：PostgreSQL基础备份前提。pg_basebackup要求归档模式且wal_level至少replica，故A正确；wal_level为minimal不支持所需WAL信息，故B错；非归档模式无法完成基础备份，故C错；非归档且关闭full_page_writes既无法备份也影响崩溃恢复，故D错。 136. 某业务库出现大量慢查询，分析发现某条SQL在WHERE条件列上存在隐式类型转换，最直接的优化措施是 A. 统一应用传入参数与列定义的数据类型 B. 为该列增加前缀索引以减小索引体积 C. 调大sort_buffer_size以加快排序 D. 将该查询拆分为多条子查询分别执行 答案：A 解析：知识点：隐式类型转换导致索引失效。统一参数类型可恢复索引使用，故A正确；前缀索引不解决类型转换引起的失效，故B错；sort_buffer_size影响排序而非条件过滤，故C错；拆分子查询通常加重开销且不解决类型转换，故D错。 137. MySQL主从复制中，从库的Seconds_Behind_Master持续增大，而主库写入量并未明显上升，首先应排查的方向是 A. 从库是否存在大事务或单线程回放瓶颈 B. 主库是否误将sync_binlog设为0 C. 从库是否将read_only设为ON D. 主库是否开启了半同步复制插件 答案：A 解析：知识点：复制延迟诊断。大事务或单线程回放是常见延迟原因，故A正确；sync_binlog影响主库持久化而非从库回放速度，故B错；read_only限制从库写入，与回放延迟无直接关系，故C错；半同步影响提交确认，不直接导致回放延迟增大，故D错。 138. 对Oracle数据库执行RMAN全库备份时，若希望备份包含归档日志且能用于不完全恢复，应选择的命令是 A. BACKUP DATABASE PLUS ARCHIVELOG B. BACKUP DATABASE SKIP INACCESSIBLE C. BACKUP DATABASE NOT BACKED UP D. BACKUP DATABASE FILESPERSIST 答案：A 解析：知识点：RMAN备份命令。PLUS ARCHIVELOG会在备份数据库同时归档当前日志并备份归档日志，故A正确；SKIP INACCESSIBLE跳过不可访问文件，不保证包含归档，故B错；NOT BACKED UP只备份从未备份过的文件，故C错；FILESPERSIST控制备份片数量，与是否含归档无关，故D错。 139. 在SQL Server中，将数据库恢复模式从完整改为简单后，最直接的后果是 A. 无法再进行日志备份以实现时间点恢复 B. 事务日志文件会被立即收缩到最小 C. 数据库将无法执行完整备份 D. 已提交事务会在检查点时被回滚 答案：A 解析：知识点：SQL Server恢复模式。简单模式不支持日志备份，故A正确；改模式不会立即收缩日志文件，故B错；完整备份仍可执行，故C错；检查点不会回滚已提交事务，故D错。 140. 在Linux系统上通过源码编译方式安装MySQL后，需要初始化数据目录，下列哪项是初始化时推荐使用的mysqld参数 A. --initialize-insecure B. --skip-grant-tables C. --initialize-with-root D. --bootstrap-root 答案：A 解析：知识点：MySQL 5.7及以上版本初始化数据目录。--initialize-insecure会创建root@localhost空密码账户，便于首次登录后设置密码，是官方推荐初始化方式之一。--skip-grant-tables用于跳过权限验证启动，其作用是临时绕过权限表而非初始化数据目录。--initialize-with-root并非真实存在的mysqld参数。--bootstrap-root也不是mysqld的参数，bootstrap是另一套通过SQL脚本初始化的机制。 141. 某生产库的innodb_buffer_pool_size配置为物理内存的80%，但监控发现磁盘读IOPS持续偏高，最可能的原因是 A. 缓冲池仍不足以覆盖热点数据 B. redo log文件过大 C. binlog格式为ROW D. 表空间使用独立表空间 答案：A 解析：知识点：InnoDB缓冲池与磁盘IO关系。缓冲池即使占比高，如果热点数据总量超过池容量，仍会频繁从磁盘读取，表现为IOPS高。redo log文件大小主要影响检查点频率与恢复时间，不会直接导致大量读IO。binlog格式ROW影响写入日志量，与磁盘读IOPS无直接关系。独立表空间只影响文件组织方式，不改变缓冲池命中率。 142. 对MySQL执行FLUSH TABLES WITH READ LOCK后，下列哪项操作仍然可以正常进行 A. SELECT查询 B. INSERT插入 C. UPDATE更新 D. DELETE删除 答案：A 解析：知识点：全局读锁的作用范围。FLUSH TABLES WITH READ LOCK加全局读锁后，所有表的写操作被阻塞，但读操作仍可执行，因此SELECT可以正常进行。INSERT属于写操作会被阻塞。UPDATE属于写操作会被阻塞。DELETE属于写操作会被阻塞。 143. 在MySQL中执行OPTIMIZE TABLE对InnoDB表的主要效果是 A. 整理表空间碎片并重建表 B. 重建所有索引的统计信息 C. 将表数据压缩存储 D. 把表转换为MyISAM引擎 答案：A 解析：知识点：OPTIMIZE TABLE对InnoDB的作用。该命令对InnoDB表实际执行的是重建表（类似ALTER TABLE ... FORCE），回收删除产生的碎片空间。重建索引统计信息是ANALYZE TABLE的作用。压缩存储需要显式指定压缩相关参数，不是OPTIMIZE TABLE的默认效果。OPTIMIZE TABLE不会改变存储引擎。 144. 数据库配置了基于binlog的主从复制，从库出现Seconds_Behind_Master持续增大，最先应检查的环节是 A. 从库SQL线程是否被大事务阻塞 B. 主库binlog是否开启 C. 从库server_id是否唯一 D. 主库是否使用InnoDB引擎 答案：A 解析：知识点：主从延迟排查。Seconds_Behind_Master持续增大说明从库应用binlog的速度跟不上，常见原因是从库SQL线程被大事务或慢SQL阻塞，应优先检查。主库binlog未开启则复制根本无法建立，不会表现为延迟增大。server_id重复会导致复制报错而非延迟。主库存储引擎与从库延迟无直接因果关系。 145. 某DBA对生产库执行了全量备份后，又连续执行了多份binlog备份，若要恢复到某次误删除之前的状态，正确的恢复顺序是 A. 先恢复全量备份，再按时间顺序重放binlog B. 先重放binlog，再恢复全量备份覆盖 C. 先恢复全量备份，再重放最后一次binlog即可 D. 先恢复最近一次增量备份，再重放binlog 答案：A 解析：知识点是备份恢复流程。正确顺序是先还原全量备份作为基线，再按binlog生成的时间顺序依次重放，才能重建到误操作前状态。先重放binlog再覆盖备份会丢失binlog效果；只重放最后一次binlog会缺失中间变更；题干未说明有增量备份，且增量也需在全量基础上应用。 146. 在PostgreSQL中执行VACUUM FULL的主要效果是 A. 回收死元组占用空间并将表文件重写压缩 B. 仅更新统计信息供优化器使用 C. 清理WAL日志释放磁盘 D. 重建所有索引但不改动表数据 答案：A 解析：知识点是PostgreSQL空间回收。VACUUM FULL 会重写表文件，把死元组清除并压缩空间，但会持排他锁。仅更新统计信息是ANALYZE；清理WAL由检查点或归档策略处理；重建索引是REINDEX，与VACUUM FULL不同。 147. 某表数据量约2亿行，业务只需按时间范围查询最近一个月数据，为提升查询性能最有效的措施是 A. 按时间字段做分区并配合分区裁剪 B. 在该表时间字段上建普通B+树索引 C. 增大sort_buffer_size D. 把该表改为MyISAM引擎 答案：A 解析：知识点是大表查询优化。按时间分区后查询最近一个月可只扫描对应分区，配合分区裁剪效果显著。普通索引在2亿行上仍可能回表量大；sort_buffer_size只影响排序；MyISAM不支持事务且不解决范围扫描问题。 148. 以下关于数据库备份策略的描述中，符合生产实践的有哪些 A. 全量备份与增量备份结合可平衡恢复时间与存储成本 B. 备份文件应定期做恢复演练验证可用性 C. binlog应保留足够时长以支持时间点恢复 D. 备份应与生产库放在同一块磁盘以方便管理 E. 备份频率越高越好，无需考虑对生产性能的影响 答案：A、B、C 解析：知识点是备份策略。全量加增量、定期演练、保留足够binlog都是生产实践。备份与生产库同盘会因磁盘故障同时丢失；盲目提高频率会加重生产负载，需权衡。 149. 在Linux平台上以源码方式安装MySQL后，首次启动前必须完成的初始化操作是 A. 执行mysqld --initialize生成数据目录并记录临时密码 B. 执行mysql_install_db脚本并手工设置root空密码 C. 直接启动mysqld服务再用mysqladmin设置root密码 D. 执行mysql_secure_installation完成数据目录初始化 答案：A 解析：知识点：MySQL 5.7及以后版本源码安装后的初始化流程。正确项对：mysqld --initialize会创建数据目录、系统表并生成临时root密码，是官方推荐的初始化方式。错误项一：mysql_install_db在5.7后已被弃用且不会生成临时密码。错误项二：未初始化数据目录时mysqld无法正常启动。错误项三：mysql_secure_installation是初始化之后的安全加固脚本，不能代替数据目录初始化。 150. 某DBA对生产库执行物理备份后，为验证备份可用性，在测试机上还原时最先应执行的操作是 A. 用mysqlbinlog解析备份中的二进制日志确认完整性 B. 将备份文件复制到测试机并校验文件大小与校验和 C. 直接把备份文件覆盖到测试机数据目录后启动实例 D. 先执行FLUSH TABLES WITH READ LOCK再还原备份 答案：B 解析：知识点：备份还原前的可用性校验流程。正确项对：还原前先校验备份文件的完整性和大小，确认文件未损坏，这是还原的第一步。错误项一：mysqlbinlog针对二进制日志，不用于校验物理备份文件本身。错误项二：未校验直接覆盖数据目录，若备份损坏会造成测试机实例也无法启动。错误项三：FLUSH TABLES WITH READ LOCK是备份前加锁操作，与还原阶段无关。 151. 在Oracle数据库中，归档模式下执行热备份时对表空间加锁的正确命令是 A. ALTER TABLESPACE users BEGIN BACKUP B. ALTER DATABASE BEGIN BACKUP users C. ALTER TABLESPACE users READ ONLY D. ALTER DATABASE ARCHIVELOG users 答案：A 解析：知识点：Oracle热备份的表空间加锁语法。正确项对：热备份需先对表空间执行BEGIN BACKUP，使数据文件进入备份模式，复制完再END BACKUP。错误项一：BEGIN BACKUP是表空间级子句，不能这样加到ALTER DATABASE上。错误项二：READ ONLY会阻止写入，与热备份所需的可写状态不符。错误项三：ALTER DATABASE ARCHIVELOG用于切换归档模式，不是表空间备份命令。 152. MySQL中InnoDB的innodb_flush_log_at_trx_commit参数设置为0时，其行为是 A. 每次事务提交都把日志刷盘并同步到磁盘 B. 每秒把日志刷盘一次，提交时只写日志缓冲 C. 每次事务提交只把日志写入操作系统缓冲 D. 由操作系统决定何时把日志缓冲写入磁盘 答案：B 解析：知识点：innodb_flush_log_at_trx_commit三种取值的持久性差异。正确项对：取值为0时每秒将日志缓冲刷入磁盘并fsync，事务提交仅写日志缓冲，不触发刷盘。错误项一：描述的是取值1的行为，每次提交都刷盘同步，持久性最强。错误项二：描述的是取值2的部分特征，但0不是写入操作系统缓冲。错误项三：该参数不由操作系统决定刷盘时机，那是OS层面的缓冲策略。 153. 对执行计划中出现全表扫描的高频查询，在确认该列选择性很高后最应优先考虑的措施是 A. 对该查询涉及的列建立合适的索引 B. 增大InnoDB缓冲池的容量参数 C. 把该表改为分区表以减少扫描量 D. 调整查询缓存大小以复用结果 答案：A 解析：知识点：SQL性能调优中索引的适用场景。正确项对：列选择性高时建立索引可显著减少扫描行数，是针对性最强的优化手段。错误项一：缓冲池只影响数据缓存命中率，不能解决全表扫描本身。错误项二：分区表在查询条件未命中分区键时仍会扫描多个分区，不是首选。错误项三：查询缓存已在新版本中移除，且与扫描方式优化无直接关系。 154. SQL Server中查看某数据库最近一次完整备份时间的正确方式是查询 A. sys.dm_db_index_usage_stats视图 B. msdb库中backupset表的backup_finish_date列 C. sys.databases的create_date列 D. sys.dm_exec_query_stats视图 答案：B 解析：知识点：SQL Server备份历史记录的查询位置。正确项对：备份历史保存在msdb的backupset表中，backup_finish_date记录完成时间。错误项一：该视图统计索引使用情况，与备份无关。错误项二：create_date是数据库创建时间，不是备份时间。错误项三：该视图记录查询执行统计，不含备份信息。 155. MySQL主从复制中，从库出现Seconds_Behind_Master持续增大且SQL线程正常，最可能的原因是 A. 从库的relay log被意外删除导致重放中断 B. 主库binlog格式为ROW导致重放变慢 C. 从库单线程重放速度跟不上主库写入速度 D. 从库的server_id与主库设置相同 答案：C 解析：知识点：MySQL主从延迟的常见成因判断。正确项对：SQL线程正常但延迟持续增大，典型原因是单线程重放能力低于主库并发写入。错误项一：relay log被删会导致SQL线程报错停止，而非正常却延迟。错误项二：ROW格式本身不必然导致重放变慢，且格式影响的是日志内容。错误项三：server_id相同会导致复制无法建立，不会表现为延迟增大。 156. 在PostgreSQL中执行pg_basebackup进行基础备份时，参数-Ft的作用是 A. 以tar格式输出备份文件 B. 以纯文本格式输出备份 C. 启用流式复制协议传输 D. 对备份文件进行压缩输出 答案：A 解析：知识点：pg_basebackup输出格式参数。正确项对：-Ft指定以tar格式打包输出，便于归档和传输。错误项一：纯文本是默认的plain格式，对应-Fp。错误项二：流式传输由-X参数控制wal的传输方式，与格式无关。错误项三：压缩需配合-z参数，单独-Ft不启用压缩。 157. 某运维在业务高峰期对一张千万级表执行ALTER TABLE加索引，发现锁等待严重，正确的处置是 A. 立即kill掉该DDL会话并改用在线DDL工具 B. 增大锁等待超时时间让DDL继续执行 C. 把该表的存储引擎临时改为MyISAM D. 重启数据库实例释放被占用的表锁 答案：A 解析：知识点：大表DDL的在线变更方法与锁冲突处置。正确项对：高峰期阻塞业务的DDL应终止，改用pt-online-schema-change或gh-ost等在线工具降低锁影响。错误项一：延长超时只会让更多业务会话堆积等待。错误项二：改存储引擎本身也是DDL且风险更大。错误项三：重启实例会中断全部业务，代价极高且不解决根本问题。 158. 数据库备份策略中，采用“每周日全备、周一到周六增量备份”方案，若周四数据文件损坏，恢复时需要的备份集是 A. 仅周四当天的增量备份 B. 周日全备加周一到周四的增量备份 C. 周日全备加周四当天的增量备份 D. 周四增量备份加周三的增量备份 答案：B 解析：知识点：增量备份的恢复链依赖关系。正确项对：增量备份基于上一次备份的差异，恢复需从最近全备起按顺序应用所有增量。错误项一：单独增量备份缺少基线全备无法恢复。错误项二：跳过了周二、周三的增量，恢复链断裂。错误项三：遗漏周日全备和周二、周三增量，数据不完整。 159. 对数据库执行逻辑备份时，为保证备份数据的一致性，InnoDB表应配合使用的参数是 A. --single-transaction以获取一致快照 B. --lock-all-tables以锁住所有表 C. --flush-logs以刷新二进制日志 D. --master-data以记录位点信息 答案：A 解析：知识点：mysqldump一致性备份参数。正确项对：--single-transaction在InnoDB上开启可重复读事务，获得一致性快照而不阻塞写入。错误项一：--lock-all-tables会锁全库，影响业务且非InnoDB首选。错误项二：--flush-logs仅切换日志，不保证数据一致性。错误项三：--master-data记录复制位点，与一致性快照无直接关系。 160. 数据库性能调优中，属于连接数与线程层面可优化项的有哪些 A. 调整最大连接数并与应用连接池上限匹配 B. 启用线程池减少高频短连接创建开销 C. 增大sort_buffer_size到超过物理内存 D. 把wait_timeout设为0使连接永不超时 E. 为慢查询配置long_query_time阈值 答案：A、B 解析：知识点：连接与线程相关的性能参数优化。正确项一对：最大连接数应与应用连接池上限匹配，避免连接被拒或资源浪费。正确项二对：线程池可复用线程，降低高频短连接的创建销毁开销。错误项一：sort_buffer_size是每连接排序缓冲，设成超过物理内存会导致内存耗尽。错误项二：wait_timeout为0使空闲连接永不释放，会耗尽连接资源。错误项三：long_query_time用于慢查询日志记录阈值，属于日志监控而非连接线程优化。 161. 在Linux服务器上通过源码编译方式安装MySQL后，首次初始化数据目录时，用于生成临时root密码并初始化系统表的命令是哪个 A. mysqld --initialize --user=mysql B. mysql_install_db --user=mysql --random-password C. mysqld_safe --skip-grant-tables --initialize D. mysqladmin -u root password --initialize 答案：A 解析：知识点是MySQL 5.7及以后源码安装后的初始化方式。mysqld --initialize会初始化数据目录并在错误日志中生成临时root密码，正确。mysql_install_db是5.6及以前的老工具且无--random-password参数，错。mysqld_safe --skip-grant-tables是跳过权限验证的启动方式，不能用于初始化，错。mysqladmin用于修改已存在实例的密码，无法初始化数据目录，错。 162. 对MySQL执行逻辑备份时，若希望备份文件包含建库语句并保证同一时刻数据一致性，同时避免锁表影响业务写入，应优先选择的工具与参数组合是 A. mysqldump --single-transaction --databases B. mysqldump --lock-all-tables --databases C. mysqlpump --single-transaction --no-create-db D. mysqldump --flush-logs --master-data=2 答案：A 解析：知识点是InnoDB一致性快照备份。--single-transaction在可重复读隔离级别下开启一致性事务快照且不锁表，配合--databases输出建库语句，正确。--lock-all-tables会对所有表加读锁，阻塞写入，错。mysqlpump的--no-create-db不输出建库语句，与需求不符，错。--flush-logs与--master-data=2用于记录binlog位点，本身不保证不锁表的一致性快照，错。 163. Oracle数据库处于归档模式下，RMAN执行全库备份后，某数据文件所在磁盘损坏且无该文件的单独备份，此时正确的恢复流程是 A. restore datafile后recover datafile再打开数据库 B. 直接recover database后open database C. restore database后recover database再resetlogs D. switch datafile后recover datafile再open 答案：A 解析：知识点是RMAN数据文件级恢复流程。先从备份restore该数据文件，再用归档日志recover，最后打开数据库，正确。recover database前未restore损坏文件，恢复无法进行，错。restore database做整库还原超出必要范围，且resetlogs会重置日志序列，错。switch datafile只是切换文件副本位置，并非从备份还原，错。 164. 使用Redis做缓存时，某键设置了过期时间但仍持续占用内存，经排查发现该键在同一秒内被大量重复写入且每次写入都重置了TTL，最可能导致的现象是 A. 键的过期时间被不断推迟导致长期驻留 B. 键被自动转为持久键并写入RDB C. 键触发了惰性删除立即释放内存 D. 键被移动到其他数据库编号下 答案：A 解析：知识点是Redis过期策略。每次写入都重设TTL会把过期时间不断往后推，使键长期驻留，正确。仅重设TTL不会把键变为持久键，错。惰性删除在访问时才判断过期，此处键未过期不会删除，错。重设TTL不会改变键所在的数据库编号，错。 165. 在MongoDB副本集中，主节点写入后从节点尚未同步，此时主节点宕机，选举产生的新主节点上可能缺少刚写入的数据，这体现了MongoDB的哪个特性 A. 写关注级别较低时存在回滚可能 B. 读关注为majority时会出现幻读 C. 副本集无法保证最终一致性 D. 分片键选择不当导致数据倾斜 答案：A 解析：知识点是MongoDB写关注与回滚。写关注为1时主节点确认即返回，主节点宕机后未同步的写入可能被回滚，正确。读关注majority是读取已多数确认的数据，与题目场景不符，错。副本集本身保证最终一致性，错。分片键导致的是数据分布问题，与主从同步回滚无关，错。 166. 对Oracle表执行ALTER TABLE ... SHRINK SPACE COMPACT后再执行ALTER TABLE ... SHRINK SPACE，两次操作的主要区别是 A. COMPACT只移动行不释放空间，第二次才调整高水位并释放 B. COMPACT释放空间，第二次仅重建索引 C. COMPACT需要排他锁，第二次只需共享锁 D. COMPACT针对分区表，第二次针对非分区表 答案：A 解析：知识点是Oracle段收缩两阶段。COMPACT阶段只做行移动不调整高水位，第二个命令才重置高水位释放空间，正确。COMPACT不释放空间，错。两阶段都需相应锁，但区别不在锁类型，错。是否分区表不是两次操作的区别依据，错。 167. MySQL主从复制中，从库执行SHOW SLAVE STATUS发现Seconds_Behind_Master持续增大，且Relay_Log_Space快速增长，最可能的原因是 A. 从库单线程回放跟不上主库并发写入 B. 主库binlog格式为ROW导致日志过大 C. 从库开启了log_slave_updates D. 主从server_id配置相同 答案：A 解析：知识点是主从延迟诊断。从库SQL线程单线程回放，主库并发高时容易堆积，导致延迟增大，正确。ROW格式本身不必然导致延迟，错。log_slave_updates只是记录到从库binlog，不直接导致延迟，错。server_id相同会导致复制无法建立，而非延迟，错。 168. 在某Linux服务器上通过包管理器安装MySQL后，希望服务随系统启动自动运行，应优先执行哪项操作 A. 执行systemctl enable mysqld并检查服务单元是否生效 B. 执行systemctl start mysqld后手工加入rc.local C. 将mysqld可执行文件路径写入当前用户的bash配置文件 D. 执行service mysqld restart并观察启动日志 答案：A 解析：知识点是Linux下MySQL服务的开机自启配置。systemctl enable会创建服务单元的启动链接，使服务随系统启动，且可用is-enabled校验。systemctl start只影响本次运行；写入rc.local属于旧式做法且易被systemd忽略；写入bash配置文件只对交互式登录shell生效；service restart只是重启服务，不配置自启。 169. 对MySQL执行逻辑备份时，希望导出所有库的结构与数据并保证导出文件可被另一台同版本服务器直接导入，应使用哪个命令 A. mysqldump --all-databases --single-transaction --routines --events B. mysqldump --all-databases --lock-all-tables --no-create-info C. mysqldump --databases mysql --skip-triggers --no-data D. mysqlpump --exclude-databases=% --users 答案：A 解析：知识点是mysqldump全库逻辑备份的常用参数组合。--single-transaction在InnoDB上提供一致性快照，--routines和--events保证存储程序与事件被导出。--no-create-info会丢失表结构；--no-data只导结构；--exclude-databases=%会排除所有库导致无数据可导。 170. 数据库实例运行中误删了一张InnoDB表的数据行且未开启binlog，最可能可用的恢复途径是什么 A. 从最近一次全量备份加增量备份中恢复到误删前的时间点 B. 从数据字典中直接反查被删行的原始值 C. 利用undo表空间回滚已提交的删除事务 D. 从操作系统页缓存中提取被删行的页镜像 答案：A 解析：知识点是恢复途径依赖备份与日志。未开binlog时无法做基于时间点的不完全恢复，只能依赖全量备份加已有增量备份恢复到误删前状态。数据字典只存元数据不存行数据；undo表空间只服务未提交事务回滚；页缓存中的页镜像不保证可提取且非正规恢复手段。 171. 在Oracle中执行RMAN备份时，希望备份集能够只备份已使用过的数据块以减小备份体积，应启用哪个特性 A. 备份优化与块变更跟踪配合增量备份 B. 开启归档模式后执行全库全量备份 C. 设置控制文件自动备份并保留多份副本 D. 使用备份集压缩并指定maxpiecesize参数 答案：A 解析：知识点是RMAN增量备份与块变更跟踪。块变更跟踪记录自上次备份以来变化的块，增量备份只读这些块，配合备份优化可显著减小体积。归档模式全量备份仍备份全部块；控制文件自动备份只保护控制文件；压缩与分片只影响存储形式，不减少需读取的块数量。 172. PostgreSQL中执行VACUUM后表文件物理大小并未减小，最合理的解释是什么 A. 普通VACUUM只标记空间可复用，不把页返还操作系统 B. VACUUM需要先执行REINDEX才能回收表空间 C. autovacuum未关闭导致VACUUM被阻塞 D. 表的fillfactor被设置为100阻止空间回收 答案：A 解析：知识点是PostgreSQL的MVCC空间回收机制。普通VACUUM把死元组空间标记为可复用，但通常不缩小文件；VACUUM FULL才会重写表并返还空间。REINDEX针对索引；autovacuum不会阻塞手动VACUUM；fillfactor为100是默认值，并非阻止回收的原因。 173. 某数据库服务器内存充足但innodb_buffer_pool_size设置偏小，导致磁盘读增多，调整该参数后最应同步关注什么 A. 实例重启后缓冲池预热情况与命中率变化 B. binlog文件大小是否随之自动调整 C. redo log的写入位置是否改变 D. 表的自增主键步长是否被重置 答案：A 解析：知识点是缓冲池大小调整后的验证。增大缓冲池需重启实例，重启后缓冲池为空，需要关注预热与命中率是否改善。binlog大小、redo写入位置、自增步长均不随缓冲池大小改变。 174. 在Linux上以RPM包安装MySQL 8.0后，需要修改默认数据目录到新挂载的独立磁盘，下列操作顺序中最稳妥的是 A. 停止服务→修改配置文件datadir→初始化新目录→启动服务 B. 初始化新目录→停止服务→修改配置文件datadir→启动服务 C. 停止服务→初始化新目录→修改配置文件datadir→启动服务 D. 修改配置文件datadir→初始化新目录→停止服务→启动服务 答案：C 解析：知识点是MySQL数据目录迁移的标准流程。正确项先停服务避免数据写入，再初始化新目录保证权限与系统表完整，最后改配置启动。错误项A在改配置后未初始化新目录，服务启动会失败；错误项B未停服务就初始化，旧实例仍可能写入造成不一致；错误项D在服务运行时改配置并初始化，存在配置被缓存和目录冲突风险。 175. 某库执行逻辑备份时使用mysqldump --single-transaction，对该参数作用描述正确的是 A. 对InnoDB表开启一致性快照读，不阻塞写入 B. 对所有存储引擎加全局读锁，阻塞写入 C. 对MyISAM表开启事务快照，阻塞写入 D. 对InnoDB表加表级锁，允许并发写入 答案：A 解析：知识点是mysqldump一致性备份机制。正确项--single-transaction对InnoDB在可重复读隔离级别下开启事务保证快照一致且不锁表。错误项B是--lock-all-tables的效果；错误项C混淆了MyISAM不支持事务快照；错误项D把InnoDB的MVCC误认为表级锁。 176. 为数据库配置备份保留策略时，采用全量加增量备份组合，下列描述符合常见恢复需求的是 A. 只需保留最近一次全量，增量可长期保留 B. 保留最近一次全量及之后所有增量即可恢复 C. 保留多次全量与对应增量链，按恢复点选择 D. 增量备份可独立恢复，无需依赖全量 答案：C 解析：知识点是备份链与恢复点目标。正确项需保留多次全量及其增量链以支持不同时间点恢复。错误项A只留最近全量无法恢复更早时间点；错误项B未说明增量与全量的对应关系，容易因链断裂无法恢复；错误项D增量必须依赖其基线全量。 177. 使用Percona XtraBackup对InnoDB做热备后，应用日志到备份目录的正确步骤是 A. prepare阶段执行apply-log，将redo应用到数据文件 B. prepare阶段执行copy-back，将redo应用到数据文件 C. restore阶段执行apply-log，将undo应用到数据文件 D. backup阶段执行apply-log，将binlog应用到数据文件 答案：A 解析：知识点是XtraBackup的prepare与copy-back分工。正确项prepare阶段用--apply-log把redo日志前滚到一致状态。错误项B把copy-back与apply-log混淆，copy-back是恢复回数据目录；错误项C把apply-log放到restore阶段且误写undo；错误项D在backup阶段执行apply-log不符合流程且binlog不参与该步。 178. 某OLTP库出现大量查询等待，执行计划显示对一张大表频繁全表扫描，最应优先排查的是 A. 该表是否缺少合适索引或索引失效 B. 磁盘IOPS是否达到硬件上限 C. 数据库连接池最大连接数是否过小 D. binlog格式是否为ROW 答案：A 解析：知识点是执行计划与索引诊断。正确项全表扫描通常源于缺索引或索引未命中，应优先分析。错误项B虽是性能因素但非全表扫描直接原因；错误项C影响并发接入而非单条扫描；错误项D影响复制与日志量，不影响该查询是否走索引。 179. 在MySQL中观察到InnoDB缓冲池命中率持续偏低，下列调整措施最直接相关的是 A. 增大innodb_buffer_pool_size并评估内存余量 B. 减小innodb_log_file_size以降低刷盘 C. 增大max_connections以提升并发 D. 将innodb_flush_log_at_trx_commit改为0 答案：A 解析：知识点是缓冲池命中率与内存配置。正确项增大缓冲池可缓存更多数据页从而提升命中率。错误项B减小日志文件与命中率无直接关系；错误项C增大连接数可能加剧内存竞争；错误项D降低持久性换性能，不解决缓存不足。 180. 对数据库进行统计信息收集后，某查询计划由索引扫描变为全表扫描且性能下降，较合理的处置是 A. 回退统计信息并重新评估收集策略 B. 立即删除该表所有索引重建 C. 将该查询强制走主键索引 D. 关闭优化器的统计信息自动更新 答案：A 解析：知识点是统计信息与执行计划稳定性。正确项先回退并分析收集方式是否采样不足或时机不当。错误项B删索引破坏其他查询；错误项C强制索引可能不适用该查询；错误项D关闭自动更新会加剧计划漂移。 181. 某业务要求RPO接近0且允许少量RTO，数据库部署在同城双机房，较合适的方案是 A. 异步复制加每日全量备份 B. 半同步复制加定期全量备份 C. 同步复制加定期全量备份 D. 逻辑备份加异地增量归档 答案：C 解析：知识点是RPO/RTO与复制模式匹配。正确项同步复制保证主库提交前备库已接收，RPO接近0，配合备份满足恢复。错误项A异步复制存在数据丢失窗口；错误项B半同步在超时后可能退化为异步；错误项D逻辑备份恢复慢且RPO较大。 182. 执行数据库版本升级前，最应优先完成的准备动作是 A. 在测试环境做全量恢复与升级演练 B. 直接在生产库执行升级脚本 C. 先升级从库再切换主库 D. 关闭所有监控告警避免误报 答案：A 解析：知识点是变更前的演练与回退准备。正确项在测试环境验证升级与恢复流程可降低生产风险。错误项B跳过验证风险极高；错误项C未验证兼容性就切换可能引入故障；错误项D关闭监控会掩盖问题。 183. 在Linux服务器上以RPM包安装MySQL后，需要将服务设置为开机自启动并立即启动，应执行的命令组合是 A. systemctl enable mysqld 与 systemctl start mysqld B. chkconfig mysqld on 与 service mysqld start C. systemctl daemon-reload 与 mysqld --initialize D. rpm -ivh mysqld 与 mysql_secure_installation 答案：A 解析：知识点是Linux系统服务管理。正确项用systemd的enable设置开机自启、start立即启动，符合现代发行版管理MySQL服务的标准做法。错误项chkconfig/service属于SysVinit体系，在systemd系统上虽可能兼容但非本题环境下的规范组合；daemon-reload只是重载单元文件、initialize是初始化数据目录，都不完成启动；rpm安装与安全初始化脚本不能实现开机自启与启动服务。 184. 为MySQL配置主从复制时，主库需要产生二进制日志并拥有唯一server-id，下列参数配置组合中正确的是 A. log-bin=mysql-bin 与 server-id=1 B. log-bin=mysql-bin 与 server-id=0 C. log_error=mysql-bin 与 server-id=1 D. general_log=ON 与 server-id=1 答案：A 解析：知识点是MySQL复制的基础参数。正确项启用二进制日志并设置非零唯一server-id，满足主库复制前提。错误项server-id=0表示禁用复制功能；log_error记录的是错误日志而非二进制日志；general_log记录通用查询日志，与复制所需的binlog无关。 185. 某DBA对MySQL执行逻辑备份后，需要恢复到误删表之前的状态，下列恢复步骤中操作顺序正确的是 A. 先执行全量备份恢复 再应用二进制日志到误删时间点前 B. 先应用二进制日志 再执行全量备份恢复 C. 先执行全量备份恢复 再应用二进制日志到误删时间点后 D. 只执行全量备份恢复 忽略二进制日志 答案：A 解析：知识点是时间点恢复流程。正确项先恢复全量备份，再用binlog回放到误操作之前，才能回到误删前状态。错误项顺序颠倒会导致binlog被全量覆盖；回放到误删之后会包含误删操作；只恢复全量会丢失备份点之后的数据。 186. MySQL使用mysqldump导出InnoDB表数据时，为保证备份期间数据一致，通常应添加的参数是 A. --single-transaction B. --lock-all-tables C. --flush-logs D. --no-create-info 答案：A 解析：知识点是mysqldump一致性备份。正确项--single-transaction在InnoDB上开启一致性快照而不阻塞写入。错误项--lock-all-tables会锁全库影响业务；--flush-logs只是切换日志；--no-create-info不导出建表语句，与一致性无关。 187. 在SQL Server中，若数据库处于完整恢复模式，要支持日志备份并允许还原到某个时间点，必须执行的操作是 A. 先做一次完整备份 B. 先将恢复模式改为简单 C. 先收缩事务日志 D. 先分离数据库 答案：A 解析：知识点是SQL Server恢复模式与备份链。正确项完整恢复模式下时间点还原依赖完整备份作为起点。错误项改为简单模式会截断日志链；收缩日志不建立备份链；分离数据库更无法进行日志备份。 188. Oracle数据库归档模式下，RMAN执行全库备份前需要确保数据库处于的正确状态是 A. MOUNT或OPEN状态且已开启归档 B. NOMOUNT状态且未开归档 C. OPEN状态且处于NOARCHIVELOG D. MOUNT状态且已关闭归档 答案：A 解析：知识点是Oracle归档与RMAN备份前提。正确项要求数据库已开归档，且可在MOUNT或OPEN下做全库备份。错误项NOMOUNT无法访问数据文件；NOARCHIVELOG不支持联机一致性全备；关闭归档与归档模式要求矛盾。 189. 数据库服务器出现大量物理读且缓存命中率持续偏低，排查时首先应关注的方向是 A. 检查共享缓冲池大小与慢查询执行计划 B. 检查备份作业是否在凌晨执行 C. 检查网络带宽是否达到上限 D. 检查操作系统用户口令是否过期 答案：A 解析：知识点是性能调优的排查思路。正确项命中率低通常与缓冲池不足或SQL执行计划不佳导致全表扫描有关。错误项备份作业时间与命中率无直接关系；网络带宽影响传输而非缓冲命中；口令过期与性能无关。 190. 对一条执行时间很长的SQL，使用EXPLAIN分析后发现type列为ALL，最可能的问题是 A. 查询未使用索引而进行了全表扫描 B. 查询使用了覆盖索引 C. 查询触发了临时表排序 D. 查询使用了哈希连接 答案：A 解析：知识点是EXPLAIN执行计划解读。正确项type=ALL表示全表扫描，通常因缺少合适索引或条件未命中索引。错误项覆盖索引通常显示index/range等；临时表排序对应Using temporary/filesort；哈希连接属于连接算法，与type列含义不同。 191. 某企业要求数据库备份满足RPO接近零，且主库故障时能快速切换，最符合该要求的方案是 A. 搭建同步复制的主备集群并配置自动故障转移 B. 每天凌晨做一次全量逻辑备份 C. 每小时做一次增量物理备份 D. 每周做一次差异备份并异地存放 答案：A 解析：知识点是RPO与高可用架构。正确项同步复制使备库与主库数据一致，自动切换满足快速恢复。错误项每天全备RPO为一天；每小时增量RPO为一小时；每周差异RPO更长，均无法接近零。 192. 对MySQL执行逻辑备份时，希望导出包含建库语句且保证备份期间数据一致，应选用的命令是 A. mysqldump --single-transaction --databases db1 > db1.sql B. mysqldump --lock-tables --databases db1 > db1.sql C. mysqldump --no-create-db db1 > db1.sql D. mysqlpump --exclude-databases db1 > db1.sql 答案：A 解析：知识点为逻辑备份一致性。--single-transaction在InnoDB上开启一致性快照且不锁表，--databases会生成CREATE DATABASE语句；--lock-tables会逐表加读锁，对InnoDB一致性支持有限且阻塞写入；--no-create-db不生成建库语句；--exclude-databases是排除指定库，与导出目标相反。 193. 某PostgreSQL实例的wal_level当前为minimal，需要支持流复制和归档恢复，应调整为 A. wal_level = replica B. wal_level = logical C. wal_level = minimal D. wal_level = archive 答案：A 解析：知识点为PostgreSQL WAL级别。replica级别会记录足够WAL用于归档和流复制；logical在replica基础上增加逻辑解码所需信息，超出当前需求但可行，然而题目问支持流复制与归档的最低合适级别应为replica；minimal不支持归档恢复；archive不是合法的wal_level取值。 194. Oracle数据库执行RMAN全备后，为验证备份集可恢复性而不实际还原数据文件，应使用的命令是 A. RESTORE DATABASE VALIDATE B. VALIDATE BACKUP C. CROSSCHECK BACKUP D. LIST BACKUP SUMMARY 答案：A 解析：知识点为RMAN备份验证。RESTORE DATABASE VALIDATE会读取备份集并模拟还原，验证其可用性且不写入数据文件；VALIDATE BACKUP仅校验备份集块完整性，不模拟还原路径；CROSSCHECK检查备份记录与物理文件是否匹配；LIST仅列出备份信息。 195. 在SQL Server中配置数据库镜像时，主体服务器与镜像服务器之间传输日志的端点默认使用哪种协议端口通信 A. TCP 5022 B. TCP 1433 C. TCP 135 D. TCP 445 答案：A 解析：知识点为SQL Server数据库镜像端点。镜像端点默认使用5022端口通过TCP通信；1433是数据库引擎默认监听端口；135是RPC端点映射器；445是SMB文件共享端口，均不用于镜像日志传输。 196. MySQL实例出现大量Waiting for table metadata lock，最可能的原因是 A. 某长事务持有表元数据锁未提交 B. InnoDB缓冲池命中率过低 C. 二进制日志文件写满磁盘 D. 自适应哈希索引冲突增多 答案：A 解析：知识点为元数据锁等待。长事务未提交时会持有MDL，导致DDL或其他会话等待；缓冲池命中率低表现为物理读高；binlog写满表现为写入报错；自适应哈希索引冲突影响的是索引查找性能，均不直接产生MDL等待。 197. 对MongoDB副本集执行备份时，为保证备份点一致，推荐的操作顺序是 A. 在从节点上执行fsyncLock后复制数据文件再unlock B. 在主节点上执行fsyncLock后复制数据文件再unlock C. 在仲裁节点上执行fsyncLock后复制数据文件再unlock D. 在任意节点上直接复制数据文件不执行fsyncLock 答案：A 解析：知识点为MongoDB一致性备份。应在从节点执行db.fsyncLock()冻结写入后复制文件，再解锁，避免影响主节点服务；主节点冻结会阻塞业务写入；仲裁节点不存储数据；不冻结直接复制会得到不一致的数据文件。 198. 某业务库在每日凌晨2点执行全量逻辑备份，备份期间业务写入明显变慢，排查发现备份会话持有全局读锁，最可能使用的备份工具是 A. mysqldump配合--lock-all-tables B. xtrabackup配合--backup C. pg_dump配合--format=c D. RMAN配合BACKUP DATABASE 答案：A 解析：知识点为备份工具锁机制。mysqldump的--lock-all-tables会在备份期间对全库加读锁，阻塞写入导致业务变慢；xtrabackup为物理热备基本不锁表；pg_dump的c格式属于逻辑备份，不涉及MySQL全局锁；RMAN为Oracle工具。 199. 某PostgreSQL数据库执行VACUUM后表文件大小未减小，最合理的解释是 A. VACUUM只标记空间可重用而不归还操作系统 B. VACUUM需要重建索引才会收缩文件 C. VACUUM必须配合ANALYZE才能释放空间 D. VACUUM在事务提交前不会生效 答案：A 解析：知识点为PostgreSQL空间回收。普通VACUUM将死元组空间标记为可重用，不归还操作系统，文件不缩小；VACUUM FULL才会重写表并收缩文件；ANALYZE只更新统计信息；VACUUM在事务提交后即生效，与文件收缩无关。 200. 数据库运行管理员在制定备份策略时，下列做法有助于提升恢复可靠性的有 A. 定期对备份集执行恢复演练验证可用性 B. 将备份文件与数据库主机放在同一块物理磁盘 C. 对备份文件计算校验值并在恢复前核对 D. 保留多份不同时间点的备份副本 E. 仅保留最近一次全量备份以节省空间 答案：A、C、D 解析：知识点为备份可靠性保障。恢复演练能提前发现备份不可用；校验值可检测备份文件损坏；多时间点副本可应对逻辑错误回溯。将备份与数据库放同一磁盘会随磁盘故障一起丢失；仅保留最近全量备份无法应对误删或逻辑损坏后的时间点恢复。 201. 在Linux服务器上完成MySQL 8.0二进制方式安装后，首次启动前需要初始化数据目录，以下初始化命令中能正确设置root密码并生成临时随机密码记录的是 A. mysqld --initialize --user=mysql B. mysqld --initialize-insecure --user=mysql C. mysqld --init-file=/tmp/init.sql --user=mysql D. mysql_install_db --user=mysql --random-pass 答案：A 解析：知识点是MySQL 8.0数据目录初始化方式。--initialize会生成一个临时随机root密码并写入错误日志，符合要求；--initialize-insecure生成空密码root，不满足设置密码要求；--init-file是自定义初始化SQL脚本，不是标准初始化方式；mysql_install_db在8.0已被移除，且参数不存在。 202. Oracle数据库运行在归档模式下，执行RMAN全库备份时希望备份期间数据文件保持一致，应使用的最小附加配置是 A. alter database begin backup 逐文件拷贝 B. RMAN backup database 并启用控制文件自动备份 C. RMAN backup database 并加上backup archivelog all D. RMAN backup database 并配置retention policy 答案：B 解析：知识点是RMAN一致性备份。RMAN在归档模式下备份时会自动处理块一致性，无需手工begin backup，并应配置控制文件自动备份；逐文件拷贝属于用户管理备份方式；备份归档日志是额外动作，不是保持一致性的最小配置；retention policy只影响保留策略。 203. 某MySQL实例的慢查询日志显示大量语句处于Sending data状态且扫描行数远大于返回行数，最应优先检查的调优方向是 A. 增大sort_buffer_size B. 为相关过滤与连接列补充合适索引 C. 调大max_connections D. 关闭binlog以减少写入 答案：B 解析：知识点是慢查询诊断。扫描行数远大于返回行数通常是缺少合适索引导致全表或大范围扫描，应优先补索引；sort_buffer_size只影响排序阶段；max_connections与单条查询扫描无关；关闭binlog影响的是写入与复制，不解决扫描放大问题。 204. PostgreSQL中某表数据量很大且查询条件固定为按create_time范围过滤，希望减少顺序扫描开销，最合适的索引类型是 A. HASH索引 B. BRIN索引 C. GIN索引 D. GiST索引 答案：B 解析：知识点是PostgreSQL索引类型适用场景。BRIN按块范围存储摘要，适合与物理顺序相关的大表范围过滤；HASH只支持等值查询；GIN适合数组、全文检索等多值类型；GiST适合几何与范围类型等，不是时间范围过滤的首选。 205. 某数据库服务器内存充足但InnoDB缓冲池命中率长期偏低，检查发现缓冲池大小配置远小于物理内存，最直接的优化措施是 A. 增大innodb_buffer_pool_size并重启实例 B. 增大innodb_log_file_size并重启实例 C. 增大table_open_cache并重启实例 D. 增大innodb_io_capacity并重启实例 答案：A 解析：知识点是InnoDB缓冲池调优。命中率低且缓冲池配置远小于内存，核心是扩大缓冲池；日志文件大小影响写性能与恢复时间；表缓存影响打开表数量；IO容量影响刷脏速度，均不直接提升缓冲池命中率。 206. 在Oracle中执行RMAN备份时出现RMAN-03009与ORA-19504无法创建文件，检查发现目标目录属主为root且无写权限，正确处置是 A. 用root用户重新执行RMAN脚本 B. 调整备份目录属主与权限为Oracle用户可写 C. 改用expdp逻辑导出替代RMAN D. 在RMAN中设置backup copies为0 答案：B 解析：知识点是RMAN备份报错排查。ORA-19504通常是操作系统层面无法写入目标路径，应修正目录属主与权限；用root执行RMAN不符合规范且环境变量缺失；expdp不能替代物理备份；backup copies与文件创建权限无关。 207. 某MySQL主从复制环境从库出现Seconds_Behind_Master持续增长，检查发现从库单线程回放且主库写入并发高，最有效的缓解措施是 A. 在从库开启多线程复制并合理设置并行度 B. 在从库增大read_only并重启复制 C. 在主库关闭binlog减少写入量 D. 在从库执行flush tables清空缓存 答案：A 解析：知识点是复制延迟处理。高并发写入下单线程回放是瓶颈，开启多线程复制可提升回放能力；read_only是只读控制，不影响回放速度；主库关闭binlog会破坏复制；flush tables与复制延迟无直接关系。 208. 某Oracle数据库需要制定备份策略，以下关于RMAN备份与恢复的做法中正确的有 A. 开启控制文件自动备份以便恢复时获取备份元数据 B. 定期执行validate检查备份集是否可恢复 C. 将归档日志与数据文件备份放在同一磁盘并长期保留 D. 配置retention policy后即可不再做恢复演练 E. 对关键表空间启用块变化跟踪以加速增量备份 答案：A、B、E 解析：知识点是RMAN备份策略与可恢复性。控制文件自动备份保证元数据可用；validate可校验备份集可用性；块变化跟踪能加速增量备份。归档与数据文件同盘长期保留会增加单点故障风险且占用空间；配置保留策略不能替代恢复演练，演练是验证可恢复性的必要环节。 209. 在Linux服务器上以RPM包方式安装MySQL后，需要初始化数据目录并获取临时root密码，应执行的操作是 A. 执行mysqld --initialize --user=mysql并将错误日志中的临时密码记录下来 B. 执行mysql_install_db --user=mysql后直接使用空密码登录root账户 C. 执行mysqld --initialize-insecure --user=mysql后使用root空密码登录 D. 执行mysql_secure_installation完成数据目录初始化并设置root密码 答案：A 解析：知识点：MySQL 5.7及以上RPM安装后的初始化流程。mysqld --initialize会生成随机临时root密码并输出到错误日志，需记录后首次登录修改，故A正确。B中mysql_install_db是5.6及更早的初始化工具，5.7后已被--initialize取代，且不会自动设空密码。C中--initialize-insecure生成的是空密码root账户，虽能登录但并非题目要求的'获取临时密码'流程。D中mysql_secure_installation是初始化完成后的安全加固脚本，不能用于初始化数据目录。 210. 某DBA对MySQL执行逻辑备份时使用mysqldump --single-transaction，关于该参数的作用描述正确的是 A. 在备份期间对表加读锁以保证数据一致性 B. 通过开启一致性快照实现InnoDB表的不锁表备份 C. 将所有MyISAM表转为InnoDB后再执行备份 D. 在备份完成后自动执行一次事务提交以释放锁 答案：B 解析：知识点：mysqldump的--single-transaction参数原理。该参数在备份开始时开启一个可重复读事务，利用InnoDB的MVCC获得一致性快照，备份期间不锁表，故B正确。A描述的是--lock-tables或--lock-all-tables的行为。C中mysqldump不会自动转换存储引擎。D中备份结束时会自动提交或回滚事务以释放快照，但这不是该参数的核心作用，且描述为'加锁'相关也不准确。 211. 在对生产库执行xtrabackup全量备份后准备恢复到新实例，恢复前通常需要先执行的操作是 A. 执行xtrabackup --prepare使备份数据达到一致状态 B. 执行xtrabackup --copy-back直接覆盖数据目录 C. 执行FLUSH TABLES WITH READ LOCK锁定原库再恢复 D. 执行mysqladmin shutdown关闭原实例后再恢复 答案：A 解析：知识点：Percona XtraBackup的备份恢复流程。备份文件在--backup阶段处于非一致状态，需通过--prepare应用redo日志使数据文件达到一致，故A正确。B中--copy-back是prepare完成后的拷贝步骤，跳过prepare直接copy-back会导致数据不一致。C中FTWRL是备份时保证一致性的手段，恢复阶段不需要。D中关闭原实例与恢复流程无必然关系，且恢复目标是新实例。 212. MySQL中某查询在WHERE条件列上建立了索引但执行计划显示type=ALL，最可能的原因是 A. 该列的选择性过低导致优化器放弃使用索引 B. 该列上存在隐式类型转换使索引无法被使用 C. 该表的统计信息比索引建立时间更新 D. 该查询使用了ORDER BY导致索引被跳过 答案：B 解析：知识点：索引失效的常见原因。当WHERE条件列与查询值存在隐式类型转换（如字符串列用数字比较）时，索引无法被有效利用，执行计划会显示全表扫描，故B正确。A中选择性低确实可能让优化器放弃索引，但通常仍会显示range或index，且不是'最可能'的直接原因。C中统计信息更新只会让优化器判断更准确，不会导致索引失效。D中ORDER BY可能影响排序方式，但不会直接导致WHERE列索引被跳过。 213. 某MySQL实例的innodb_buffer_pool_size设置为物理内存的70%，但监控显示缓冲池命中率持续低于90%，下一步最应优先排查的是 A. 是否存在大量全表扫描或未命中索引的慢查询 B. 是否开启了doublewrite导致缓冲池被占用 C. 是否将innodb_log_file_size设置得过小 D. 是否将innodb_flush_method设置为O_DIRECT 答案：A 解析：知识点：InnoDB缓冲池命中率低的排查思路。命中率低通常说明工作集超出缓冲池或存在大量低效查询，优先排查慢查询和全表扫描，故A正确。B中doublewrite是写盘机制，不直接占用缓冲池页。C中redo日志大小影响写性能，与缓冲池命中率无直接关系。D中flush_method影响刷盘方式，不决定命中率。 214. 在MySQL主从复制中，从库出现Seconds_Behind_Master持续增大但Slave_IO_Running与Slave_SQL_Running均为Yes，最可能的原因是 A. 主库binlog格式为ROW导致从库解析慢 B. 从库单线程回放跟不上主库并发写入 C. 主从server_id配置冲突导致事件丢失 D. 从库未开启log_slave_updates参数 答案：B 解析：知识点：MySQL主从延迟的常见原因。IO和SQL线程均正常但延迟增大，通常是从库SQL线程单线程回放速度跟不上主库并发写入，故B正确。A中ROW格式本身不会导致解析慢到持续延迟，且与线程状态无关。C中server_id冲突会导致复制中断而非延迟。D中log_slave_updates影响级联复制，不影响回放速度。 215. 对Oracle数据库执行RMAN全量备份后，需要验证备份集是否可用于恢复，应执行的操作是 A. 执行RESTORE VALIDATE DATABASE检查备份集可恢复性 B. 执行VALIDATE BACKUP检查备份集完整性但不做恢复 C. 执行CROSSCHECK BACKUP删除失效的备份记录 D. 执行LIST BACKUP SUMMARY查看备份集列表 答案：B 解析：知识点：RMAN备份验证命令。VALIDATE BACKUP用于检查备份集的完整性和可读性，不实际执行恢复，故B正确。A中RESTORE VALIDATE DATABASE会实际模拟恢复过程，开销更大，不是'验证备份集'的首选。C中CROSSCHECK是核对备份记录与物理文件是否一致，不验证内容。D中LIST BACKUP SUMMARY仅列出备份信息，不做验证。 216. 某Redis实例内存使用率接近maxmemory且频繁触发淘汰，业务方希望优先保留最近访问的键，应将maxmemory-policy设置为 A. allkeys-lru B. volatile-lru C. allkeys-random D. volatile-ttl 答案：A 解析：知识点：Redis内存淘汰策略。allkeys-lru对所有键按最近最少使用淘汰，能优先保留最近访问的键，故A正确。B中volatile-lru只淘汰设置了过期时间的键，若大量键未设过期则无法淘汰。C中allkeys-random随机淘汰，不保留最近访问。D中volatile-ttl按剩余生存时间淘汰，与访问时间无关。 217. 在SQL Server中，某数据库设置为完整恢复模式但从未做过事务日志备份，日志文件持续增长，正确的处置是 A. 将恢复模式改为简单模式并收缩日志文件 B. 执行一次完整备份后立即执行事务日志备份 C. 直接对日志文件执行SHRINKFILE操作 D. 分离数据库后删除日志文件再附加 答案：B 解析：知识点：SQL Server完整恢复模式下的日志管理。完整恢复模式下日志需通过日志备份截断，正确做法是先做完整备份建立基线再做日志备份，故B正确。A中改为简单模式会破坏时间点恢复能力，且不是首选。C中直接收缩日志文件在未备份情况下无法真正截断日志。D中删除日志文件会导致数据库无法正常附加或数据不一致。 218. 在Linux环境下为MySQL 8.0配置二进制日志以实现基于时间点恢复，下列参数组合中能够正常启用binlog并记录完整行级变更的是 A. log_bin=mysql-bin，binlog_format=ROW，server_id=1 B. log_bin=mysql-bin，binlog_format=STATEMENT，server_id=0 C. log_bin=OFF，binlog_format=MIXED，server_id=1 D. log_bin=mysql-bin，binlog_format=ROW，server_id=0 答案：A 解析：知识点：MySQL二进制日志启用条件。正确项同时设置log_bin路径、ROW行格式及非零server_id，满足binlog启用前提。错误项binlog_format=STATEMENT在server_id=0时因复制标识缺失无法正常启用；log_bin=OFF直接关闭二进制日志；server_id=0在MySQL 8.0中会导致binlog不记录或复制异常。 219. 在PostgreSQL中查看当前数据库连接数是否接近max_connections上限，最直接的查询是 A. SELECT count(*) FROM pg_stat_activity B. SELECT count(*) FROM pg_tables C. SELECT count(*) FROM pg_locks D. SELECT count(*) FROM pg_stat_user_tables 答案：A 解析：知识点：PostgreSQL连接监控。pg_stat_activity每个连接一行，统计其行数即当前连接数。pg_tables统计表数量；pg_locks统计锁对象；pg_stat_user_tables统计用户表活动，均与连接数无关。 220. 对数据库进行性能调优时，下列措施中能够有效降低磁盘IO压力的有 A. 增大InnoDB缓冲池以缓存更多数据页 B. 为高频查询字段建立覆盖索引减少回表 C. 将随机写入的redo log放在SSD上 D. 提高max_connections以接纳更多连接 E. 定期执行ANALYZE TABLE更新统计信息 答案：A、B、C 解析：知识点：降低磁盘IO的调优手段。增大缓冲池、覆盖索引、redo log放SSD均直接减少或加速磁盘访问。提高连接数会增加并发负载；更新统计信息主要优化执行计划，不直接降低IO。 221. 在Linux上以源码方式安装MySQL 8.0后，首次初始化数据目录时使用了mysqld --initialize-insecure，与--initialize相比，其直接结果是 A. root@localhost账户生成随机临时密码并写入错误日志 B. root@localhost账户密码为空且无需首次登录后强制修改 C. 初始化过程跳过InnoDB日志文件创建以加快启动 D. 数据目录权限被自动设置为750且属主为mysql 答案：B 解析：知识点：MySQL初始化参数差异。--initialize-insecure生成空密码root账户，不强制首次改密，故B正确；A是--initialize的行为；C错误，InnoDB日志文件两种方式都会创建；D错误，权限不由该参数决定，需手动chown。 222. 某DBA对生产库执行mysqldump全量备份时希望保证备份数据的一致性快照，同时避免长时间锁表阻塞写入，应添加的参数组合是 A. --single-transaction --master-data=2 B. --lock-all-tables --flush-logs C. --single-transaction --lock-tables D. --flush-tables --skip-lock-tables 答案：A 解析：知识点：mysqldump一致性备份参数。--single-transaction在InnoDB上开启可重复读事务获得一致快照，--master-data=2记录binlog位点且不锁表，故A正确；B会全局读锁阻塞写入；C的--lock-tables仍会锁表；D无法保证一致性快照。 223. PostgreSQL中执行pg_basebackup做基础备份时，若希望备份期间数据库仍可接受写入且备份包含WAL，应使用的工作模式是 A. 在standby服务器上以--target-dir方式拉取 B. 连接主库以--wal-method=stream方式拉取 C. 先停库再以--pgdata方式复制文件 D. 以--wal-method=fetch且关闭归档 答案：B 解析：知识点：pg_basebackup备份模式。stream模式通过复制协议实时传输WAL，主库可继续写入，故B正确；A在备库拉取不能替代主库基础备份且描述不清；C需停库不符要求；D的fetch依赖归档且关闭归档会使WAL缺失。 224. 数据库服务器上innodb_buffer_pool_size已设置为物理内存的70%，但系统仍频繁发生swap，最应优先检查并调整的是 A. 将innodb_log_file_size调大以减少检查点 B. 检查vm.swappiness并适当降低其取值 C. 把innodb_flush_method改为O_DIRECT D. 增大table_open_cache以复用表句柄 答案：B 解析：知识点：内存与swap调优。频繁swap说明内核倾向于换出内存页，应检查并降低vm.swappiness，故B正确；A、C、D分别影响检查点、刷盘方式和表缓存，均不能直接抑制swap。 225. MySQL慢查询日志中出现大量语句处于Sending data状态且执行时间长，EXPLAIN显示type为ALL，最有效的优化方向是 A. 增大sort_buffer_size以减少排序开销 B. 为相关过滤或连接列建立合适索引 C. 调低long_query_time以捕获更多慢语句 D. 将查询缓存query_cache_size调大 答案：B 解析：知识点：全表扫描优化。type为ALL表示全表扫描，应针对WHERE/JOIN列建索引，故B正确；A只影响排序；C只是记录阈值；D在MySQL 8.0已移除查询缓存，方向错误。 226. 对MongoDB副本集执行备份时，为获得某一时刻一致的数据视图且不停止业务写入，通常采用的方式是 A. 在primary节点上直接mongodump全库 B. 在secondary节点上以--oplog方式mongodump C. 停止所有secondary后复制其数据文件 D. 在primary上执行fsyncLock后复制文件 答案：B 解析：知识点：MongoDB一致性备份。在secondary上用--oplog可得到含oplog的一致快照且不影响primary写入，故B正确；A在primary直接dump可能不一致且增加主库压力；C停节点影响高可用；D的fsyncLock会阻塞写入。 227. Redis作为缓存使用时出现大量key在同一时刻集中过期，导致数据库瞬时压力骤增，较合理的改进措施是 A. 将所有key的过期时间统一设为固定值 B. 为过期时间增加随机抖动以分散失效时刻 C. 关闭maxmemory-policy让内存无限增长 D. 把持久化方式由RDB改为AOF everysec 答案：B 解析：知识点：缓存雪崩防护。给过期时间加随机抖动可避免同时失效，故B正确；A正是造成集中过期的原因；C会耗尽内存；D影响持久化，与过期集中无关。 228. 某电商大促前对订单库做压测，发现TPS上不去且磁盘写延迟高，经查redo日志切换过于频繁，最应先调整的是 A. 增大innodb_log_file_size以减少切换频率 B. 将innodb_flush_log_at_trx_commit改为0 C. 把binlog_format改为STATEMENT D. 增加max_connections以接纳更多连接 答案：A 解析：知识点：redo日志与检查点。日志文件过小导致频繁切换与检查点，增大文件可缓解，故A正确；B降低持久性有丢数据风险；C改binlog格式不解决redo切换；D增加连接不解决写延迟。 229. 某DBA制定数据库备份恢复策略时，以下做法中符合运维规范的有 A. 定期做恢复演练以验证备份可用性 B. 将备份文件与数据库放在同一块物理磁盘 C. 对全量与增量备份分别保留并按周期轮转 D. 备份完成后校验文件大小与校验和 E. 仅在数据库故障时才首次测试恢复流程 答案：A、C、D 解析：知识点：备份恢复规范。恢复演练、分级保留轮转、备份校验均属规范做法，故A、C、D正确；B备份与库同盘在磁盘故障时会同时丢失；E故障时才首次测试无法保证备份可靠。 230. 在Linux环境下安装MySQL 8.0后，希望数据库服务随操作系统启动而自动运行，应执行的操作是 A. systemctl enable mysqld B. systemctl start mysqld C. systemctl restart mysqld D. systemctl status mysqld 答案：A 解析：知识点是服务开机自启配置。systemctl enable用于设置服务开机自启，正确。start仅本次启动，重启后失效；restart是重启当前服务，不改变自启状态；status仅查看状态，无配置作用。 231. 某数据库服务器磁盘IO持续接近饱和，慢查询日志显示大量全表扫描，优先考虑的调优措施是 A. 为高频查询条件字段建立合适索引 B. 增大InnoDB缓冲池容量 C. 调整数据库连接池最大连接数 D. 开启查询缓存减少磁盘读取 答案：A 解析：知识点是SQL性能调优。全表扫描导致IO饱和，建立索引可直接减少扫描的数据量，是最直接的措施。增大缓冲池对已缓存数据有效但无法解决扫描量大的问题；连接数调整不改变单条查询的扫描方式；查询缓存对全表扫描类查询命中率有限且MySQL 8.0已移除该功能。 232. 使用xtrabackup对InnoDB数据库做物理热备时，在备份完成后、恢复数据之前必须执行的关键步骤是 A. 对备份执行prepare操作使数据文件一致 B. 将备份文件复制到目标服务器的数据目录 C. 直接启动数据库实例加载备份文件 D. 对备份文件执行一次全量压缩归档 答案：A 解析：知识点是xtrabackup物理备份恢复流程。备份期间数据文件处于不一致状态，必须执行--prepare应用redo日志使数据一致后才能恢复。直接复制或启动会因数据不一致导致实例无法正常打开；压缩归档属于备份管理操作，不影响一致性。 233. 数据库配置了主从复制，从库出现Seconds_Behind_Master持续增大的情况，最不可能的排查方向是 A. 从库单线程回放跟不上主库并发写入 B. 主从之间网络延迟或带宽不足 C. 从库上存在大事务或长事务阻塞回放 D. 主库二进制日志格式设置为ROW 答案：D 解析：知识点是主从复制延迟排查。ROW格式本身不会导致复制延迟持续增大，它只是记录方式。单线程回放瓶颈、网络延迟、大事务阻塞都是常见延迟原因。 234. 某生产库误执行了DROP TABLE且未开启binlog，最可能可以恢复数据的途径是 A. 从最近一次全量备份加增量备份中恢复 B. 通过数据库回收站功能直接还原该表 C. 查询数据字典视图自动重建表结构 D. 重启数据库实例触发自动回滚恢复 答案：A 解析：知识点是误删表后的恢复策略。无binlog时无法做时间点恢复，只能依赖备份。回收站、数据字典重建、实例重启回滚都无法恢复已提交的DROP操作。 235. 为数据库配置连接池时，将最大连接数设置得远大于数据库实例实际可承载的并发数，最可能引发的后果是 A. 数据库端出现大量活跃会话争抢CPU和内存资源 B. 连接池会拒绝所有新建连接请求 C. 数据库自动降低最大连接数限制 D. 客户端连接建立时间显著缩短 答案：A 解析：知识点是连接池容量规划。连接池上限过高会将压力透传到数据库，导致会话争抢资源、性能下降。连接池不会因此拒绝连接，数据库不会自动调整限制，连接建立时间也不会因此缩短。 236. 执行数据库全量备份期间发现备份文件大小明显小于预期，排查时首先应确认的是 A. 备份命令是否因权限不足跳过了部分表 B. 数据库是否正在执行大事务回滚 C. 备份目标磁盘是否剩余空间不足 D. 备份时段是否与业务高峰重叠 答案：A 解析：知识点是备份结果校验。文件明显偏小通常意味着部分对象未被导出，权限不足导致跳过表是最常见原因。大事务回滚影响数据一致性而非文件大小；磁盘空间不足会导致备份失败而非文件偏小；业务高峰影响性能但不直接改变备份内容。 237. 数据库实例的redo日志文件组设置过小且写入频繁，最可能导致的现象是 A. 检查点频繁触发导致整体写入性能下降 B. 数据库无法启动并提示日志文件损坏 C. 备份操作无法正常读取数据文件 D. 客户端连接被数据库主动断开 答案：A 解析：知识点是redo日志配置对性能的影响。日志组过小会导致检查点频繁触发，增加磁盘刷写压力，降低写入性能。日志损坏、备份读取、连接断开与日志组大小无直接因果关系。 238. 对数据库执行备份恢复演练时，下列做法中能够有效验证备份可用性的有 A. 在隔离环境用备份文件完整恢复并校验数据一致性 B. 随机抽取若干张表对比恢复前后记录数与校验和 C. 仅检查备份文件大小与生成时间是否正常 D. 直接在生产库上覆盖恢复以验证备份有效性 E. 核对备份日志中是否出现跳过表或报错信息 答案：A、B、E 解析：知识点是备份有效性验证方法。隔离环境完整恢复、抽样比对数据、检查备份日志报错都是有效验证手段。仅看文件大小和时间无法证明内容可用；在生产库直接覆盖恢复会破坏生产数据，属于高风险错误操作。 239. 在Linux环境中为MySQL实例编写systemd服务单元时，若希望数据库进程在系统启动后自动运行且异常退出后自动拉起，服务单元中应配置的关键指令组合是 A. WantedBy=multi-user.target 与 Restart=always B. After=network.target 与 RemainAfterExit=yes C. Type=forking 与 KillMode=process D. WantedBy=graphical.target 与 Restart=on-failure 答案：A 解析：知识点：systemd服务单元的启动依赖与自动重启配置。WantedBy=multi-user.target使服务随多用户模式启动，Restart=always保证异常退出后自动拉起，二者配合满足需求。After=network.target只控制启动顺序，RemainAfterExit对常驻进程无意义；Type=forking只描述进程派生方式，KillMode只影响停止时信号范围；graphical.target依赖图形界面，服务器通常不启用，Restart=on-failure不覆盖正常退出场景。 240. 对PostgreSQL执行pg_basebackup进行基础备份时，若希望备份过程中不阻塞其他会话的写入操作，且备份文件可直接用于流复制搭建，应使用的参数是 A. pg_basebackup -Ft -z -P B. pg_basebackup -Xs -P -R C. pg_basebackup -Fp -c fast D. pg_basebackup -D dir -n 答案：B 解析：知识点：pg_basebackup的复制模式与恢复配置生成。-Xs表示通过流复制协议传输WAL日志，配合-R自动生成standby.signal和primary_conninfo，备份不阻塞写入且可直接用于搭建从库。-Ft生成tar格式仅适合归档存储，-c fast是checkpoint模式而非复制模式，-n即--no-clean会保留已存在文件，均不生成复制配置。 241. MySQL中某张日志表按天分区，运维发现查询最新一天数据时仍扫描了全部分区，执行计划中partitions列显示所有分区名，最可能的原因是 A. 分区键与查询条件字段类型不一致导致无法裁剪 B. 分区表未建立局部索引导致扫描全表 C. 查询使用了ORDER BY导致优化器放弃分区裁剪 D. 分区数量超过优化器裁剪上限自动降级 答案：A 解析：知识点：MySQL分区裁剪的前提条件。分区裁剪要求查询条件中的分区键与分区定义的类型、字符集、排序规则一致，类型不一致会隐式转换导致无法裁剪。局部索引与分区裁剪无关；ORDER BY本身不阻止裁剪；分区数量没有触发裁剪降级的机制。 242. 对Redis执行BGSAVE时，若实例内存使用量接近maxmemory上限，最可能出现的后果是 A. fork子进程时因内存不足失败并返回错误 B. 主进程被阻塞直到RDB文件写入完成 C. AOF重写被自动触发以释放内存 D. 客户端连接被批量断开以腾出内存 答案：A 解析：知识点：Redis持久化与内存管理。BGSAVE通过fork创建子进程，若物理内存不足以支撑写时复制，fork会失败并返回错误。主进程仅在fork瞬间短暂阻塞，不会全程阻塞；AOF重写由单独条件触发，与BGSAVE无直接联动；Redis不会因BGSAVE主动断开客户端。 243. 在SQL Server中配置数据库镜像时，若希望主体服务器故障后镜像服务器能自动切换，必须部署的模式是 A. 高安全性模式且带见证服务器 B. 高性能模式且不带见证服务器 C. 高安全性模式且不带见证服务器 D. 高性能模式且带见证服务器 答案：A 解析：知识点：SQL Server数据库镜像的运行模式与自动故障转移条件。自动故障转移要求高安全性模式（同步提交）并配置见证服务器形成多数派。高性能模式为异步提交不支持自动切换；高安全性模式不带见证时只能手动切换；高性能模式带见证仍为异步提交，无法自动转移。 244. Oracle数据库中某表空间的数据文件所在磁盘出现坏道，需要将该数据文件迁移到新路径，在数据库处于open状态下正确的操作顺序是 A. alter tablespace offline，复制文件，alter tablespace rename datafile，alter tablespace online B. shutdown immediate，复制文件，startup mount，alter database rename file，alter database open C. alter database datafile offline，复制文件，alter database rename file，recover datafile，alter database datafile online D. alter tablespace read only，复制文件，alter database rename file，alter tablespace read write 答案：A 解析：知识点：Oracle表空间数据文件在线迁移流程。对非系统表空间可先offline，操作系统层复制文件，再用alter tablespace rename datafile更新控制文件记录，最后online。直接shutdown需停业务；alter database datafile offline后需recover，流程更繁琐；read only不能替代offline，且rename后仍需恢复一致性。 245. MySQL主从复制中出现Slave_SQL_Running为No且错误提示为1062主键冲突，在确认从库该行数据与主库不一致后，最稳妥的处置方式是 A. 跳过该错误事务后继续复制 B. 在从库删除冲突行后重启SQL线程 C. 重做主库全量备份并重建从库 D. 将从库改为只读后等待主库同步 答案：C 解析：知识点：主从数据不一致的修复策略。1062冲突说明从库已有主库插入的主键，跳过或删行只解决当前事务，后续仍可能因数据漂移产生新冲突，最稳妥是重做全量备份重建从库。跳过错误会累积不一致；删行可能破坏其他关联数据；只读与同步无关。 246. 对MongoDB副本集执行db.collection.createIndex()时，若希望索引构建过程不阻塞其他读写操作，在4.2及以上版本中该操作默认行为是 A. 前台构建，阻塞所有读写 B. 后台构建，不阻塞读写 C. 混合构建，仅阻塞写操作 D. 滚动构建，逐节点阻塞读写 答案：B 解析：知识点：MongoDB索引构建行为。4.2版本起createIndex默认采用优化的后台构建方式，构建期间不阻塞读写。前台构建是旧版本默认行为；混合构建和滚动构建并非MongoDB索引构建的标准模式。 247. 对InnoDB表执行大量DELETE后，发现表空间文件大小未下降且查询性能变差，最合理的处置措施是 A. 执行OPTIMIZE TABLE回收空间并重建表 B. 执行ANALYZE TABLE更新统计信息 C. 调整innodb_buffer_pool_size扩大缓存 D. 对该表执行FLUSH TABLES刷新缓存 答案：A 解析：知识点：InnoDB表空间回收与碎片整理。大量DELETE只标记删除，空间不释放且产生碎片，OPTIMIZE TABLE可重建表并回收空间。ANALYZE TABLE只更新统计信息不回收空间；扩大缓冲池不解决碎片；FLUSH TABLES只刷新表缓存。 248. 在MySQL 8.0中，下列哪些操作会导致InnoDB缓冲池中的相关页被标记为脏页并最终触发刷盘 A. UPDATE语句修改了已缓存的索引页 B. INSERT语句向已缓存的聚簇索引页写入新记录 C. SELECT语句命中缓冲池中的干净页 D. DELETE语句标记已缓存页中的记录为删除 E. SELECT语句触发从磁盘读取新页到缓冲池 答案：A、B、D 解析：知识点：InnoDB脏页产生机制。UPDATE、INSERT、DELETE都会修改缓冲池中的页，使其变为脏页并最终刷盘。SELECT命中干净页不修改数据，不产生脏页；SELECT触发磁盘读只是将页加载为干净页，也不产生脏页。 249. 在Linux环境下为MySQL 8.0初始化数据目录时，mysqld --initialize与mysqld --initialize-insecure的关键区别是什么 A. 前者生成随机root密码并写入错误日志，后者生成空密码root账户 B. 前者生成空密码root账户，后者生成随机root密码并写入错误日志 C. 前者不创建root账户，后者创建带随机密码的root账户 D. 前者创建带随机密码的root账户，后者创建需要首次登录强制改密的root账户 答案：A 解析：知识点：MySQL 8.0初始化方式。--initialize会为root@localhost生成随机临时密码并记录到错误日志，--initialize-insecure则创建空密码root账户。错误项B把两者行为颠倒；错误项C误认为--initialize不创建root账户；错误项D混淆了强制改密机制，MySQL并不在初始化时设置强制改密标记。 250. 对MySQL执行物理备份时，Percona XtraBackup在备份InnoDB表的过程中仍能保持数据一致，主要依靠什么机制 A. 备份期间对InnoDB表执行FLUSH TABLES WITH READ LOCK全程持锁 B. 备份期间复制redo log并记录LSN，恢复时用redo应用未落盘事务 C. 备份期间将InnoDB表转为MyISAM再复制文件以保证一致性 D. 备份期间暂停所有写入线程并在结束后统一重放binlog 答案：B 解析：知识点：XtraBackup热备原理。它复制数据文件同时持续拷贝redo log并记录LSN，恢复时用redo前滚保证一致。错误项A是mysqldump一致性快照或冷备思路，全程持读锁会阻塞写入并非其机制；错误项C改存储引擎会破坏事务特性且不现实；错误项D暂停写入线程并重放binlog不是XtraBackup一致性实现方式。 251. 某OLTP库慢查询日志显示大量查询在等行锁，information_schema.innodb_trx中可见长事务，首先应查看哪个视图定位持锁与被阻塞关系 A. performance_schema.data_locks与data_lock_waits B. information_schema.processlist中的State字段 C. performance_schema.events_statements_summary_by_digest D. information_schema.tables中的AUTO_INCREMENT值 答案：A 解析：知识点：InnoDB锁等待诊断。performance_schema.data_locks和data_lock_waits可展示锁持有与等待链。错误项B的processlist只能看到线程状态，无法给出锁粒度与等待对象；错误项C是语句摘要统计，不含锁关系；错误项D与锁等待无关。 252. 为MySQL配置基于binlog的主从复制时，从库上设置read_only=ON后仍出现普通账号写入从库，最可能的原因是 A. read_only对拥有SUPER权限的账号不生效，需配合super_read_only B. read_only参数只在重启后生效，运行期设置无效 C. 从库的relay_log_recovery未开启导致写入被放行 D. binlog_format未设为ROW导致只读约束失效 答案：A 解析：知识点：read_only与super_read_only区别。read_only不限制具有SUPER权限的用户，super_read_only才能彻底阻止。错误项B错误，read_only为动态参数；错误项C的relay_log_recovery与只读约束无关；错误项D的binlog_format不影响只读属性。 253. Oracle数据库处于ARCHIVELOG模式时，执行热备份期间表空间被置于BEGIN BACKUP状态，此时对数据文件的读写行为是 A. 数据文件仍可正常读写，但需在END BACKUP前保存期间产生的归档日志 B. 数据文件被完全锁定，所有DML与查询均被阻塞直到END BACKUP C. 数据文件只允许查询，禁止任何DML直到END BACKUP D. 数据文件写入被重定向到临时文件，END BACKUP后合并 答案：A 解析：知识点：Oracle热备机制。BEGIN BACKUP使数据文件进入备份模式，读写照常但需归档日志配合恢复。错误项B和C错误，热备不会完全阻塞读写或仅允许查询；错误项D不存在写入重定向机制。 254. 对Redis执行RDB持久化时，bgsave相比save的主要优势在于 A. bgsave由子进程完成快照生成，主进程继续处理客户端请求 B. bgsave将快照写入AOF文件以避免阻塞 C. bgsave使用多线程并行写盘，save使用单线程 D. bgsave仅在从节点执行，save仅在主节点执行 答案：A 解析：知识点：Redis持久化。bgsave通过fork子进程生成RDB，主进程继续服务；save在主进程执行会阻塞。错误项B混淆RDB与AOF；错误项C误述写盘线程模型；错误项D与主从角色无关。 255. 在某数据库服务器上观察到innodb_buffer_pool_wait_free持续增长，最合理的调优方向是 A. 增大innodb_buffer_pool_size或降低脏页产生速率 B. 减小innodb_buffer_pool_size以加快刷脏速度 C. 关闭innodb_adaptive_flushing以减少刷脏压力 D. 将innodb_flush_method改为O_DIRECT以消除等待 答案：A 解析：知识点：缓冲池空闲页等待。该指标增长说明刷脏跟不上脏页产生，应增大缓冲池或降低脏页速率。错误项B减小缓冲池会加剧问题；错误项C关闭自适应刷脏通常更糟；错误项D改变刷盘方式不解决空闲页不足。 256. SQL Server中某查询计划出现Key Lookup且开销较高，最常见的改进措施是 A. 为查询涉及的列建立包含所需输出列的覆盖索引 B. 将该查询强制使用MAXDOP 1以降低并行开销 C. 把数据库恢复模式改为SIMPLE以减少日志等待 D. 对该表执行UPDATE STATISTICS并禁用索引 答案：A 解析：知识点：Key Lookup优化。覆盖索引可避免回表查找。错误项B并行度与回表无关；错误项C恢复模式不影响查询计划中的查找；错误项D禁用索引会加剧问题且与目标相悖。 257. 某MySQL从库出现Seconds_Behind_Master为0但业务查询结果滞后，最可能的原因是 A. 从库启用了多线程复制且存在基于不同数据库的并行回放延迟 B. 从库的relay_log空间不足导致复制中断 C. 主库binlog_format被改为STATEMENT导致复制失真 D. 从库的read_only参数被关闭导致写入冲突 答案：A 解析：知识点：复制延迟指标局限。多线程复制下Seconds_Behind_Master可能为0但仍有未回放事务。错误项B会导致复制停止而非仅滞后；错误项C会改变复制正确性但不直接解释该现象；错误项D与读取滞后无直接因果。 258. 在数据库性能调优中，下列哪些做法有助于降低InnoDB的刷脏压力并改善写入稳定性 A. 适当增大innodb_io_capacity以匹配底层存储IO能力 B. 将innodb_flush_neighbors在SSD环境下设为0 C. 把innodb_log_file_size调小以加快日志切换 D. 开启innodb_adaptive_flushing并根据脏页比例调整刷脏 E. 将innodb_buffer_pool_instances设为1以减少管理开销 答案：A、B、D 解析：知识点：InnoDB刷脏与IO调优。增大io_capacity、SSD下关闭flush_neighbors、启用自适应刷脏均有助于稳定刷脏。错误项C调小日志文件会频繁切换，增加刷脏压力；错误项E减少缓冲池实例通常不利于并发管理，与降低刷脏压力无正向关系。 259. 在Linux环境下以RPM包方式安装MySQL后，首次启动服务前必须执行初始化数据目录的操作，该操作的正确命令是 A. mysqld --initialize --user=mysql B. mysql_install_db --basedir=/usr C. service mysql start --init D. mysqld_safe --bootstrap 答案：A 解析：知识点：MySQL 5.7及以上RPM安装后需用mysqld --initialize初始化数据目录。A正确，该命令生成系统表并创建临时root密码。B错误，mysql_install_db是5.6及更早版本的初始化脚本，5.7后已废弃。C错误，service启动不会自动初始化数据目录，且--init不是合法参数。D错误，mysqld_safe是启动守护脚本，--bootstrap用于特定引导场景而非首次初始化。 260. 某DBA对生产库执行逻辑备份时希望导出所有数据库的表结构但不含数据，mysqldump应使用的参数组合是 A. --all-databases --no-data B. --all-databases --no-create-info C. --databases --skip-triggers D. --all-databases --compact 答案：A 解析：知识点：mysqldump的--no-data只导出表结构。A正确，--all-databases覆盖全部库，--no-data排除数据。B错误，--no-create-info是只导数据不导建表语句，与需求相反。C错误，--databases需指定库名，--skip-triggers只影响触发器，均不排除数据。D错误，--compact仅精简输出格式，不控制是否导出数据。 261. 在PostgreSQL中配置流复制时，主库postgresql.conf中wal_level参数应设置为哪个值才能支持物理复制 A. replica B. minimal C. logical D. archive 答案：A 解析：知识点：PostgreSQL流复制要求wal_level至少为replica。A正确，replica记录足够WAL用于物理复制。B错误，minimal仅记录崩溃恢复所需WAL，不支持复制。C错误，logical用于逻辑复制，虽包含replica信息但非物理复制的最低要求设置。D错误，archive不是wal_level的合法取值。 262. 某OLTP系统出现大量查询等待，SHOW ENGINE INNODB STATUS显示频繁的lock wait timeout，首先应排查的调优方向是 A. 检查是否存在长事务或未提交事务持有行锁 B. 调大innodb_buffer_pool_size以减少磁盘IO C. 增加max_connections以缓解连接排队 D. 开启query_cache以加速重复查询 答案：A 解析：知识点：lock wait timeout根源是锁竞争，需先定位持锁事务。A正确，长事务或未提交事务是行锁等待的常见原因。B错误，缓冲池大小影响IO性能而非锁等待。C错误，连接数与锁等待无直接因果。D错误，query_cache在MySQL 8.0已移除，且不解决锁冲突。 263. 在SQL Server中，将数据库恢复模式从FULL改为SIMPLE后，对事务日志备份能力的直接影响是 A. 无法再进行事务日志备份 B. 日志备份间隔可缩短 C. 日志链自动重建 D. 只能做差异备份 答案：A 解析：知识点：SIMPLE恢复模式下日志空间自动截断，不支持日志备份。A正确，SIMPLE模式无法做事务日志备份。B错误，SIMPLE模式根本不支持日志备份，谈不上间隔。C错误，日志链概念适用于FULL/BULK_LOGGED模式。D错误，SIMPLE模式仍支持完整和差异备份。 264. Oracle数据库执行RMAN全库备份后需要验证备份集可恢复性，且不实际还原数据文件，应使用的命令是 A. RESTORE DATABASE VALIDATE B. VALIDATE BACKUP C. CROSSCHECK BACKUP D. LIST BACKUP SUMMARY 答案：A 解析：知识点：RMAN的VALIDATE用于检查备份可恢复性而不实际还原。A正确，RESTORE ... VALIDATE模拟还原并校验。B错误，VALIDATE BACKUP仅校验备份集完整性，不验证恢复可行性。C错误，CROSSCHECK检查备份文件是否存在及状态。D错误，LIST仅列出备份信息，不做校验。 265. DBA在凌晨执行逻辑备份时发现备份任务耗时比平时长了3倍，检查发现备份期间有大批量数据导入作业在运行，正确的后续处置是 A. 将备份与批量导入作业错峰调度 B. 提高备份线程优先级抢占IO C. 改用物理备份并保持同时运行 D. 缩短备份保留周期以减少数据量 答案：A 解析：知识点：备份与大批量写入争抢IO资源导致耗时增加。A正确，错峰调度避免资源竞争。B错误，提高优先级会加剧对导入作业的影响且不解决根本问题。C错误，物理备份与批量导入同时运行仍会争抢IO。D错误，保留周期不影响单次备份耗时。 266. 在Linux环境下安装MySQL 8.0后，需要修改默认数据目录到新磁盘分区，下列操作顺序中最合理的是 A. 停止服务→修改配置文件datadir→迁移数据文件→调整目录属主→启动服务 B. 停止服务→迁移数据文件→修改配置文件datadir→调整目录属主→启动服务 C. 修改配置文件datadir→停止服务→迁移数据文件→调整目录属主→启动服务 D. 停止服务→修改配置文件datadir→调整目录属主→启动服务→迁移数据文件 答案：B 解析：知识点是MySQL数据目录迁移的标准流程。正确项先停服务保证一致性，再迁移文件、改配置、改属主后启动，顺序符合先物理后配置避免启动时找不到文件。错误项A改配置后迁移期间若有人误启动会指向空目录；错误项C未停服务即改配置可能导致运行实例与新配置不一致；错误项D启动后才迁移等于启动时仍指向旧目录或空目录。 267. PostgreSQL中执行pg_basebackup进行基础备份时，若希望备份包含WAL日志以支持时间点恢复，应使用的参数组合是 A. -Ft -z -D /backup B. -Fp -Xs -D /backup C. -Fp -Xf -D /backup D. -Ft -Xs -D /backup 答案：B 解析：知识点是pg_basebackup的WAL包含方式。正确项-Fp普通格式配合-Xs在备份中流式包含所需WAL。错误项A使用tar格式且未指定-X参数默认不包含WAL；错误项C的-Xf表示从归档获取WAL而非备份内包含；错误项D虽指定-Xs但tar格式与流式WAL的常见组合不一致，且-Xs需与-Fp配合更稳妥。 268. 数据库服务器出现大量慢查询，使用EXPLAIN分析时发现某查询type列为ALL且rows值很大，最优先的优化措施是 A. 增大innodb_buffer_pool_size B. 为该查询涉及的条件列建立合适索引 C. 调整max_connections参数 D. 开启慢查询日志并延长long_query_time 答案：B 解析：知识点是执行计划中全表扫描的优化。type=ALL表示全表扫描，rows大说明扫描行数多，建立合适索引可直接减少扫描行数。错误项A增大缓冲池只提升缓存命中不改变扫描方式；错误项C连接数参数与单条查询扫描无关；错误项D只是记录慢查询不解决扫描问题。 269. 在Oracle数据库中，RMAN执行全库备份后需要验证备份集是否可恢复，应使用的命令是 A. RESTORE DATABASE VALIDATE B. VALIDATE BACKUP C. CROSSCHECK BACKUP D. LIST BACKUP SUMMARY 答案：A 解析：知识点是RMAN备份验证。RESTORE DATABASE VALIDATE会实际读取备份集并模拟恢复以验证可用性。错误项B语法不完整，VALIDATE需指定对象；错误项C CROSSCHECK只核对备份记录与介质是否存在；错误项D仅列出备份信息不做可恢复性验证。 270. MySQL主从复制中从库出现Seconds_Behind_Master持续增大，经查从库SQL线程正常但IO线程延迟，最可能的原因是 A. 从库磁盘写入性能不足 B. 主库binlog未及时传输到从库 C. 从库存在大事务阻塞回放 D. 从库relay_log空间不足 答案：B 解析：知识点是主从复制延迟的线程定位。IO线程负责拉取binlog，其延迟说明日志传输环节慢。错误项A磁盘写入慢通常影响SQL线程回放；错误项C大事务阻塞属于SQL线程问题；错误项D relay_log空间不足会导致复制中断而非持续延迟增大。 271. 对数据库执行逻辑备份恢复到测试环境时，发现恢复后部分表数据比生产少，排查备份脚本发现mysqldump未加--single-transaction且备份期间有写入，最合理的解释是 A. 备份文件被压缩损坏导致丢行 B. 备份期间并发写入造成表间数据不一致 C. 恢复时字符集不匹配导致部分行被过滤 D. 目标库磁盘空间不足导致写入中断 答案：B 解析：知识点是一致性备份的必要性。未加--single-transaction且备份期间有写入，各表导出时点不同造成数据不一致。错误项A压缩损坏通常整表失败而非部分行少；错误项C字符集问题多表现为乱码或导入报错；错误项D空间不足会直接报错中断而非静默少行。 272. 关于数据库备份策略，下列做法中合理的有 A. 每周一次全备加每日增量备份并定期验证恢复 B. 备份文件与数据库放在同一块磁盘便于管理 C. 定期做恢复演练验证备份可用性 D. 将备份文件异地保存防止机房级故障 E. 备份任务与业务高峰重叠以保证数据最新 答案：A、C、D 解析：知识点是备份策略的可靠性设计。全备加增量并验证、恢复演练、异地保存均是合理实践。错误项B同盘存放无法抵御磁盘故障；错误项E高峰重叠会加重负载且不提升备份可靠性。 273. 在Linux环境中安装MySQL后，发现服务启动报错提示无法创建PID文件，最应优先检查的配置项是 A. pid-file路径所在目录的属主与写权限 B. innodb_buffer_pool_size是否超过物理内存 C. character-set-server是否设置为utf8mb4 D. max_connections是否超过操作系统文件句柄上限 答案：A 解析：知识点：MySQL启动时PID文件写入权限。正确项：PID文件需由mysqld运行用户写入，目录属主或权限不足会导致启动失败，应优先核查。错误项：缓冲池大小过大会导致内存分配失败而非PID创建失败；字符集设置不影响PID文件生成；连接数超限通常报错too many connections而非PID文件错误。 274. 某生产库每日凌晨2点全量备份，某日10点发生误删表，恢复时正确的处置顺序是 A. 先恢复最近全量备份，再用binlog重放到误删前一刻 B. 先重放binlog到误删前一刻，再恢复最近全量备份 C. 直接用最近全量备份覆盖生产库后立即开放业务 D. 先恢复全量备份，再重放binlog到误删之后的时间点 答案：A 解析：知识点：基于全量备份加binlog的时间点恢复。正确项：全量备份是基线，binlog重放补齐增量，重放到误删前一刻可避免重放误操作。错误项：顺序颠倒会丢失增量；仅恢复全量会丢失备份点之后的数据；重放到误删之后会把删除操作也重放进去。 275. 数据库实例出现大量慢查询，执行计划显示某查询对一张大表做全表扫描，该表在WHERE条件列上已有索引，最可能的原因是 A. 查询条件对该列使用了函数导致索引失效 B. 该索引的基数过低被优化器永久忽略 C. 表的统计信息从未收集导致索引被删除 D. 索引列的数据类型与查询参数完全一致 答案：A 解析：知识点：索引失效常见原因。正确项：对索引列施加函数或隐式类型转换会使优化器无法使用该索引，从而走全表扫描。错误项：基数低只会降低选择意愿，不会永久忽略；统计信息缺失影响估算但不删除索引；类型一致恰恰有利于走索引。 276. 为数据库配置定期全量备份策略时，若要求RPO不超过15分钟，最合理的补充措施是 A. 在全量备份基础上持续归档事务日志并支持时间点恢复 B. 把全量备份频率提高到每15分钟执行一次 C. 将全量备份文件同时复制到本地和异地存储 D. 对备份文件启用加密并限制访问账号权限 答案：A 解析：知识点：RPO与备份策略。正确项：全量备份加日志归档可实现分钟级时间点恢复，满足RPO。错误项：每15分钟全量备份对多数生产库开销过大且未必可行；异地复制和加密提升的是可靠性与安全性，不缩短RPO。 277. 对数据库进行性能调优时，发现磁盘IO长期接近饱和而CPU利用率不高，优先考虑的优化方向是 A. 优化慢查询减少物理读并调整缓冲池命中率 B. 增加应用连接池最大连接数 C. 把数据库字符集统一改为utf8mb4 D. 提高操作系统swap分区使用比例 答案：A 解析：知识点：IO瓶颈定位与优化。正确项：IO饱和通常由大量物理读引起，优化SQL和提升缓存命中率可减少磁盘访问。错误项：增大连接池会加重IO压力；字符集与IO瓶颈无关；提高swap使用会拖慢数据库性能。 278. 某数据库服务器内存充足，但InnoDB缓冲池命中率持续偏低，最不可能的原因是 A. 缓冲池配置容量远小于活跃数据集 B. 存在大量全表扫描导致缓存频繁淘汰 C. 缓冲池实例数配置与CPU核数不匹配 D. 查询参数绑定了大量不同的字面量 答案：C 解析：知识点：缓冲池命中率影响因素。正确项（最不可能）：实例数主要影响并发争用，与命中率高低无直接因果关系。错误项：容量不足、全表扫描、字面量过多导致计划缓存与数据缓存压力增大，都会拉低命中率。 279. 对生产库执行DDL变更时，为降低对业务的影响，较稳妥的做法是 A. 在业务低峰期使用在线DDL工具并先在预发环境验证 B. 直接在业务高峰期执行以尽快完成变更 C. 关闭binlog后再执行DDL以避免日志膨胀 D. 把DDL拆成多条语句在事务中一次性提交 答案：A 解析：知识点：在线DDL与变更窗口。正确项：低峰期配合在线DDL工具（如gh-ost/pt-osc）可减少锁表时间，预发验证可避免生产事故。错误项：高峰期执行风险高；关闭binlog会破坏恢复能力；DDL多为隐式提交，拆事务无法保证原子回滚。 280. 数据库备份文件校验时，除了检查文件大小和生成时间，还应重点验证的是 A. 备份文件能否在测试实例上成功恢复并查询到预期数据 B. 备份文件所在磁盘的剩余空间是否充足 C. 备份脚本的执行用户是否具有sudo权限 D. 备份文件是否与源库在同一台物理主机上 答案：A 解析：知识点：备份有效性验证。正确项：只有实际恢复并校验数据，才能确认备份可用，这是备份策略的关键环节。错误项：磁盘空间、执行权限、存放位置属于运维条件，不能证明备份内容完整可用。 281. 以下关于数据库索引维护的做法中，正确的有 A. 定期检查并重建碎片率过高的索引以提升扫描效率 B. 对频繁更新的列建立大量索引以加速所有查询 C. 删除长期未被使用且确认无业务依赖的冗余索引 D. 在查询条件列上创建索引前先分析该列的选择性 E. 为每张表的所有列都建立单列索引以保证覆盖 答案：A、C、D 解析：知识点：索引维护与设计原则。正确项：重建高碎片索引、清理无用冗余索引、按选择性建索引均是合理做法。错误项：频繁更新列建大量索引会拖慢写入；全列建索引浪费空间且增加维护成本，不能保证覆盖所有查询。 282. 在Linux服务器上通过源码方式安装MySQL后，首次启动前需要执行初始化操作，下列操作中正确的是 A. 使用mysqld --initialize生成临时root密码并记录在错误日志中 B. 使用mysql_install_db初始化并自动创建空密码root账户 C. 使用mysqld --initialize-insecure生成随机root密码 D. 使用mysqladmin -u root password直接设置初始密码 答案：A 解析：知识点：MySQL 5.7及以上源码安装的初始化方式。--initialize会生成临时随机root密码并写入错误日志，需登录后立即修改，故A正确。B是旧版5.6的做法，5.7后被废弃；C的--initialize-insecure生成的是空密码而非随机密码，描述与参数含义相反；D在数据库未初始化时无法连接，mysqladmin无法执行。 283. 在MySQL主从复制架构中，从库出现Seconds_Behind_Master持续增大且主库写入压力正常，排查时首先应检查的指标是 A. 从库的relay log回放线程是否因大事务或单线程回放而积压 B. 主库的binlog_format是否被设置为ROW C. 从库的read_only参数是否被关闭 D. 主库的max_connections是否被调小 答案：A 解析：知识点：主从延迟的常见成因定位。延迟持续增大而主库正常，通常是从库SQL线程回放慢（大事务、无主键、单线程），故A是首要检查点。B的ROW格式一般不会造成这种持续延迟；C的read_only影响写入权限而非回放速度；D只影响连接数，与回放延迟无直接因果关系。 284. 使用mysqldump对InnoDB表进行逻辑备份时，为保证备份期间数据一致性且尽量不阻塞写入，应添加的参数组合是 A. --single-transaction --master-data=2 B. --lock-all-tables --flush-logs C. --single-transaction --lock-tables D. --skip-lock-tables --hex-blob 答案：A 解析：知识点：mysqldump一致性备份参数。--single-transaction借助MVCC快照保证InnoDB一致性且不锁表，--master-data=2记录binlog位点用于搭建复制，故A正确。B的lock-all-tables会全局锁表阻塞写入；C中--lock-tables仍会逐表加锁，与--single-transaction混用并不保证跨表一致；D放弃锁机制且未记录位点，无法保证一致性快照与复制位点。 285. 在PostgreSQL中对一张频繁更新的表执行VACUUM FULL后，最直接的副作用是 A. 表上的所有索引会失效需要重建 B. 执行期间会对表加排他锁并重写整表 C. 会导致WAL日志被立即截断 D. 会重置表的统计信息为默认值 答案：B 解析：知识点：PostgreSQL VACUUM FULL机制。VACUUM FULL会重写整表并持有排他锁，期间阻塞读写，故B正确。A索引不会失效，仅会随重写被重建；C的WAL截断由checkpoint等机制决定，与VACUUM FULL无直接关系；D统计信息由ANALYZE更新，VACUUM FULL不负责重置统计。 286. 某业务库需要配置定期全量备份加增量备份策略，若使用XtraBackup实现增量备份，增量备份的基础是 A. 上一次全量备份或增量备份的LSN B. 上一次备份的binlog文件名与位点 C. 上一次备份的mysqldump输出文件 D. 上一次备份的ibdata1文件大小 答案：A 解析：知识点：XtraBackup增量备份原理。增量备份基于上次备份的LSN（日志序列号）来确定变更页范围，故A正确。B是复制位点，不用于xtrabackup增量基准；C的mysqldump是逻辑备份，与物理增量无关；D文件大小并非增量基准，无法定位变更页。 287. 在Redis中执行BGSAVE进行持久化时，关于fork子进程与内存的描述，正确的是 A. fork会立即复制全部内存数据导致内存翻倍 B. fork采用写时复制，父进程修改的页才会被复制 C. BGSAVE期间所有写命令会被阻塞至完成 D. BGSAVE生成的RDB文件包含fork时刻之后的新写入 答案：B 解析：知识点：Redis BGSAVE的fork与COW机制。fork使用写时复制，只有父进程写操作触及的页才复制，故B正确。A描述为立即全量复制，与COW机制不符；C中BGSAVE期间写命令不阻塞，仅fork瞬间有短暂停顿；D的RDB是fork时刻的数据快照，不含之后的新写入。 288. 在Linux服务器上通过源码编译方式安装MySQL后，执行初始化时提示无法加载libaio.so.1共享库，最恰当的处置是安装哪个包后重试 A. 安装libaio开发包并重新编译 B. 安装libaio运行库包后在系统库路径生效 C. 安装numactl包并重启数据库进程 D. 安装openssl-devel包并重新初始化 答案：B 解析：知识点是MySQL源码安装的依赖库。libaio.so.1由libaio运行库提供，报错是运行时找不到该so，安装运行库并让动态链接器识别即可。安装开发包只提供头文件与静态库，不解决so缺失；numactl是NUMA工具，与libaio无关；openssl-devel用于SSL编译，与异步IO库无关。 289. 某数据库设置为归档模式后，日常全量备份策略为每周一次，为满足任意时间点恢复需求，还需配合哪种机制才能实现 A. 定期导出数据字典 B. 持续归档重做日志并保留 C. 每日重建索引统计信息 D. 定期执行表空间收缩 答案：B 解析：知识点是归档模式下的时间点恢复（PITR）前提。全量备份加连续归档的重做日志才能前滚到任意时间点。导出数据字典只是元数据，不能前滚数据变更；重建索引与收缩表空间属于运维优化，不提供恢复能力。 290. 使用pg_dump对PostgreSQL做逻辑备份，在恢复时希望先清空目标库中已有对象再重建，应使用哪个选项组合 A. --clean --if-exists B. --data-only --inserts C. --schema-only --no-owner D. --format=c --compress=9 答案：A 解析：知识点是pg_dump恢复行为控制。--clean会在重建前删除已有对象，--if-exists避免对象不存在时报错。--data-only只导数据不建对象；--schema-only只导结构；自定义格式与压缩只影响备份文件形式，不清空已有对象。 291. 数据库服务器内存充足但查询响应仍慢，执行计划显示对大表做全表扫描，统计信息最近未更新，下一步最合理的操作是 A. 直接增加临时表空间大小 B. 收集该表的统计信息后重新评估计划 C. 对该表的所有列都建立单列索引 D. 关闭自动统计信息收集任务 答案：B 解析：知识点是统计信息对优化器代价估算的影响。统计信息过期会导致优化器误判选择全表扫描，应重新收集统计信息。增大临时表空间只影响排序等操作；盲目对所有列建索引会增加维护成本；关闭自动收集会加剧统计过期问题。 292. 某SQL Server实例需要将数据库恢复到故障发生前的最近状态，且数据库处于完整恢复模式，恢复流程中第一步应执行的是 A. 还原最近一次完整备份并保持NORECOVERY B. 还原最近一次差异备份并保持RECOVERY C. 还原事务日志备份并保持RECOVERY D. 分离故障数据库后直接附加原文件 答案：A 解析：知识点是完整恢复模式下的还原顺序。必须先还原完整备份并保持NORECOVERY状态，才能继续还原差异和日志备份。先还原差异需先有完整基线；直接还原日志需有完整备份作为基础；分离附加无法回滚未提交事务，不能保证一致性。 293. 在Linux下配置MySQL主从复制，从库执行START SLAVE后显示Seconds_Behind_Master持续增大，主库写入压力正常，排查时首先应确认的从库参数是 A. 从库的innodb_buffer_pool_size是否足够大 B. 从库是否开启了log_slave_updates C. 从库的relay_log_recovery是否启用 D. 从库SQL线程是否因单线程回放成为瓶颈 答案：D 解析：知识点是主从延迟定位。主库写入正常而从库延迟持续增大，常见原因是SQL线程单线程回放能力不足。缓冲池大小影响查询性能但非延迟首要因素；log_slave_updates用于级联复制；relay_log_recovery用于崩溃恢复，均不直接解释持续延迟。 294. 对数据库执行冷备份（关闭实例后拷贝数据文件）与热备份相比，其主要优势在于 A. 备份期间业务可继续读写 B. 备份文件可直接用于异机恢复 C. 备份过程无需考虑数据文件一致性 D. 可支持任意时间点恢复 答案：B 解析：知识点是冷热备份特性对比。冷备份时实例关闭，数据文件处于一致状态，拷贝后可直接用于异机恢复。热备份期间业务可读写、无需停机；冷备因停机天然一致，但一致性并非其相对优势；任意时间点恢复依赖归档日志，冷备不具备。 295. 在 Linux 上以源码方式安装 MySQL 后，首次初始化数据目录时使用 --initialize-insecure 与 --initialize 的关键区别是 A. 前者不生成 root 密码，后者生成随机临时密码 B. 前者跳过权限表创建，后者正常创建权限表 C. 前者允许 root 空密码远程登录，后者仅本地登录 D. 前者不写 binlog，后者写入初始化日志 答案：A 解析：知识点：MySQL 初始化参数。--initialize 会为 root 生成随机临时密码并写入错误日志，--initialize-insecure 生成空密码 root 账号，两者都会创建权限表，与远程登录和 binlog 无关。错误项：跳过权限表是 --skip-grant-tables 的行为；远程登录由账号 host 决定；初始化阶段均不涉及业务 binlog 写入。 296. 对 MySQL 做物理备份恢复时，把 xtrabackup 全量备份 prepare 阶段的主要作用是 A. 将备份中未提交事务回滚并前滚已提交事务使数据文件一致 B. 把备份文件从压缩格式解压成可读表空间 C. 校验备份文件与源库的校验和是否一致 D. 把 InnoDB 表空间转换为 MyISAM 便于恢复 答案：A 解析：知识点：xtrabackup prepare。prepare 利用 redo 做崩溃恢复，回滚未提交事务、前滚已提交事务，使数据文件达到一致状态。错误项：解压是 decompress 阶段；校验和是校验步骤；表引擎转换与 prepare 无关。 297. 在Linux环境下安装Oracle数据库前，关于共享内存参数的配置，以下哪项操作是安装文档要求且能避免ORA-00845错误的关键步骤？ A. 将/dev/shm大小调整为不小于MEMORY_TARGET的值 B. 将kernel.shmall设置为物理内存页数的两倍 C. 关闭透明大页并设置vm.swappiness为0 D. 把SGA_MAX_SIZE写入/etc/sysctl.conf并重启系统 答案：A 解析：知识点是Oracle安装前共享内存配置。在Linux上使用AMM时，/dev/shm必须足够大以容纳MEMORY_TARGET，否则实例启动报ORA-00845。选项B错在shmall并非决定/dev/shm挂载大小的参数，调它不能解决ORA-00845；选项C涉及透明大页与交换倾向，属于性能优化建议，不是避免该错误的关键；选项D把数据库参数写入系统配置文件属于混淆层次，且SGA_MAX_SIZE不是内核参数。 298. 某数据库采用RMAN执行全量备份后，又持续归档日志备份，现需将数据库恢复到三天前某时刻的状态，以下恢复流程中正确的下一步是？ A. 先restore控制文件再recover database until time B. 先recover database until time再restore数据文件 C. 先startup nomount再restore spfile并open resetlogs D. 先restore database再recover database until time 答案：D 解析：知识点是RMAN不完全恢复顺序。正确流程是先用restore database还原数据文件，再用recover database until time应用归档日志到目标时刻，最后open resetlogs。选项A把控制文件还原放在首位，控制文件在多数场景无需单独还原且顺序会打乱；选项B把recover放在restore之前，没有还原的数据文件无法恢复；选项C的restore spfile与open resetlogs步骤错位，缺失数据文件还原与恢复环节。 299. 某MySQL实例在业务高峰期出现大量慢查询，经查slow log中多條SQL的Rows_examined远大于Rows_sent且未使用索引，作为DBA首先应采取的处置是？ A. 立即增大innodb_buffer_pool_size以缓存更多数据 B. 用EXPLAIN分析这些SQL的执行计划并评估加索引 C. 将slow_query_log关闭以减少日志写入开销 D. 把long_query_time调大以过滤掉大部分慢查询 答案：B 解析：知识点是慢查询定位与索引优化。Rows_examined远大于Rows_sent通常意味着全表扫描或索引选择不当，应先用EXPLAIN分析执行计划，确认缺失或失效的索引再优化。选项A盲目加大缓冲池可能缓解I/O但不会改变扫描行数过多的本质；选项C关闭慢日志会丢失诊断依据；选项D调大阈值属于掩盖问题而非解决，均不能定位根因。 300. 在SQL Server中为某高频更新表配置备份策略时，以下哪些做法有助于在保证可恢复性的同时降低备份对业务的影响？ A. 每周一次完整备份配合每日差异备份 B. 对核心表启用页校验和并定期DBCC CHECKDB C. 将事务日志备份频率设为每15分钟一次 D. 把数据库恢复模式改为SIMPLE以缩小日志 E. 对大表启用表分区并单独备份文件组 答案：A、C、E 解析：知识点是备份策略与恢复模式配合。完整+差异+频繁日志备份可在控制备份窗口的同时支持时间点恢复，故A、C正确；对大表分区并单独备份文件组能减少单次备份体积与锁竞争，故E正确。选项B的页校验和与DBCC CHECKDB属于一致性检查手段，不直接降低备份对业务影响；选项D改为SIMPLE会失去日志备份能力，无法做时间点恢复，违背可恢复性要求。