。整理了大厂高频真题，分职级给出标准答案模板 + 实操命令，帮你直击考点，面试从容应答！

一、初级岗（0-2 年）：基础运维 + 命令实操

核心考点：MySQL/Oracle 基础命令、慢查询开启、索引设计、主从基础配置，侧重“会用、会查、会配”。

真题 1：如何开启 MySQL 慢查询日志，写出核心命令，并说明如何分析慢查询日志？

解析 + 答题模板 + 实操命令：

慢查询日志是 MySQL 性能优化的核心工具，默认关闭，核心命令分临时开启（重启失效）+ 永久开启（配置文件），分析工具常用
mysqldumpslow/pt-query-digest：

bash

运行

# 1. 临时开启（登录MySQL执行，重启失效）
showvariableslike'slow_query_log'; # 查看慢查询日志状态
setglobal slow_query_log=ON; # 开启慢查询日志
setglobal slow_query_log_file='/var/log/mysql/slow.log'; # 指定日志路径
setglobal long_query_time=1; # 设置慢查询阈值，超过1秒记录
setglobal log_queries_not_using_indexes=ON; # 记录未使用索引的查询

# 2. 永久开启（修改my.cnf配置文件，重启MySQL生效）
[mysqld]
slow_query_log=ON
slow_query_log_file=/var/log/mysql/slow.log
long_query_time=1
log_queries_not_using_indexes=ON

# 3. 慢查询日志分析命令
mysqldumpslow -s t -n 10 /var/log/mysql/slow.log # 按查询时间排序，取前10条
pt-query-digest /var/log/mysql/slow.log # 专业工具，生成详细分析报告

分析核心要点：重点看查询时间、锁等待时间、扫描行数、是否使用索引，针对未用索引、扫描行数过多的 SQL 做优化。

真题 2：Oracle 中如何查询当前会话的锁等待情况，写出核心 SQL？

解析 + 实操 SQL：

Oracle 锁等待是线上高频故障，核心查询锁持有方、等待方、锁类型，定位后释放无效锁，核心 SQL：

sql

-- 查询Oracle锁等待详情
SELECT
  s.sid,
  s.serial#,
  p.spid,
  s.username,
  s.osuser,
  o.object_name,
  l.locked_mode,
  l.blocking_session,
  s.program
FROM
  v$locked_object l,
  dba_objects o,
  v$session s,
  v$process p
WHERE
  l.object_id = o.object_id
AND l.session_id = s.sid
AND s.paddr = p.addr
AND s.blocking_session ISNOTNULL;

-- 释放锁（需确认无业务影响）
ALTERSYSTEMKILLSESSION'sid,serial#';

二、中级岗（3-5 年）：性能优化 + 故障应急

核心考点：MySQL/Oracle 深度优化、高可用集群故障、锁机制排查、数据恢复，侧重“会优化、会排障、会恢复”。

真题：MySQL 线上出现锁等待雪崩，导致业务请求阻塞，你的完整排查与解决流程是什么？（STAR 法则模板）

解析 + 答题模板（企业级实战案例）：

S（情境）：公司电商秒杀场景下，MySQL 线上出现锁等待雪崩，show processlist 显示超 200 个会话处于锁等待状态，秒杀接口请求阻塞，订单提交失败，影响用户体验。

    T（任务）：作为 DBA，需 5 分钟内快速定位锁等待原因，解决阻塞问题，恢复业务正常，同时制定长效方案避免再犯。

    A（行动）：

1. 快速排查：① 执行show processlist查看阻塞会话，定位锁持有方 SID；② 执行select * from information_schema.innodb_locks查询锁类型（为行锁，因秒杀更新订单表同一行数据导致）；③ 分析业务 SQL，发现秒杀订单更新未加行锁索引，导致行锁升级为表锁。
2. 紧急解决：① 确认锁持有方无核心业务操作，执行kill [SID]释放锁；② 临时调整 MySQL 锁等待超时时间（set global innodb_lock_wait_timeout=5），避免会话长期阻塞；③ 对订单表更新字段添加联合索引，规避行锁升级。
3. 业务配合：通知研发团队优化秒杀 SQL，采用乐观锁（版本号）替代悲观锁，避免同一行数据竞争。
4. R（结果）：3 分钟内解决锁等待雪崩，业务请求恢复正常，订单提交成功率 100%；通过索引优化 + 乐观锁改造，后续秒杀场景未再出现锁等待问题，数据库并发能力提升 80%。

三、高级岗（5 年 +）：架构设计 + 容灾备份

核心考点：企业级数据库架构设计、跨机房灾备、分库分表落地、云数据库融合、数据安全体系，侧重“会设计、会规划、会落地”。

真题：请为金融交易平台设计一套高可用、高安全的数据库架构，说明设计原则、核心组件选型与容灾方案？

解析 + 答题模板（金融级架构，符合等保三级）：

金融交易平台的核心需求是数据强一致性、交易高可用、数据零丢失、满足合规审计，设计原则为“同城双活 + 异地灾备、读写分离、分层架构、安全优先”，核心架构设计如下：

1. 核心数据库层：① 交易核心用Oracle RAC 19c搭建同城双活集群，实现秒级故障切换，满足强一致性；② 非核心业务用MySQL MGR集群，开启半同步复制，保证数据不丢失；③ 读写分离：通过 MyCat 做中间件，读请求分流至从库，写请求至主库，提升并发能力。
2. 分库分表层：针对交易流水、用户日志等海量数据，采用Sharding-JDBC做分库分表，按用户 ID 分库、按时间分表，解决单库数据量过大问题。
3. 容灾备份层：① 同城灾备：Oracle RAC/MySQL MGR 集群部署在同城两个机房，网络延迟＜5ms，实现秒级切换；② 异地灾备：通过 OGG 实现跨地域数据同步，异地机房延迟＜30s，满足 RTO＜1 小时、RPO=0 的灾备要求；③ 数据备份：全量备份 + 增量备份 + 日志备份，每天全量备份，每小时增量备份，实时日志备份，备份文件异地存储，保留 30 天。
4. 安全监控层：① 数据安全：做数据脱敏（用户手机号 / 身份证）、数据库审计（记录所有操作）、权限管控（最小权限原则）；② 监控告警：搭建 Prometheus+Grafana+Zabbix 监控平台，覆盖数据库 CPU/IO/ 内存、锁等待、慢查询、同步状态，多级告警（短信 / 邮件 / 企业微信）；③ 合规审计：保留数据库操作日志 180 天，满足金融等保三级要求。