DBA面试真题目表面看上去形态各异变化多端，然而实际上其关键核心考点极为高度地往一处聚集，初级考查基础的运维以及相关命令的实际操作，中级考查性能的优化以及故障的解决，高级考查架构的设计以及容灾备份。对大厂高频出现的真题进行了整理，按照职级给出标准的答案样式以及实际操作的命令，辅助你直接命中考点，在面试时能够从容地进行应对作答！
一、初级岗（0-2 年）：基础运维 + 命令实操
关键考点在于，MySQL基础命令，Oracle基础命令，慢查询开启操作，索引设计要点，主从基础配置内容，重点偏向能够运用，能够进行查阅，能够予以配置。
真题 1：怎样去开启 MySQL 的慢查询日志，把核心命令给写出来，并且还要说明怎样去分析慢查询日志呢？
解析 + 答题模板 + 实操命令：
慢查询日志，乃是 MySQL 性能优化里头占据核心地位的工具，它默认处于关闭状态，其核心命令涵盖临时开启这一情况（重启之后便会失效）以及永久开启这种方式（依托配置文件），并且它还是分析工具里常常会用到的。
MySQL慢查询日志分析工具mysqldumpslow，性能分析工具pt - query - digest：
bash
运行
# 1. 临时开启（登录MySQL执行，重启失效）
show variables like 'slow_query_log'; # 查看慢查询日志状态
set global slow_query_log=ON; # 开启慢查询日志
set global slow_query_log_file='/var/log/mysql/slow.log'; # 指定日志路径
set global long_query_time=1; # 设置慢查询阈值，超过1秒记录
set global 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：
甲骨文数据库锁等待属于线上出现频率较高的故障，关键在于查询出锁的持有一方，还有那位等待的一方，以及锁的类型究竟是什么，在确定位置之后对无效的锁实施释放操作，核心的结构化查询语言如下：
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 IS NOT NULL;
-- 释放锁（需确认无业务影响）
ALTER SYSTEM KILL SESSION 'sid,serial#';
二、中级岗（3-5 年）：性能优化 + 故障应急
关键要点在于，对 MySQL以及 Oracle进行深度层面的优化，处理高可用集群出现的故障，排查锁机制方面的问题，实现数据恢复，重点在于具备会优化、会排除故障、会进行恢复的能力。
真的题目：MySQL 在网络上线的状况里呈现出锁等待状况如雪崩一般倾泻而来，致使业务所发出的请求停滞不前，你那完整的排查以及解决的流程究竟是什么呢？（STAR 法则的模板样式）
解析 + 答题模板（企业级实战案例）：
公司处于电商秒杀的情境之时，MySQL在线上弄出了锁等待雪崩这状况，show processlist表明超过200个会话正处在锁等待状态，秒杀接口的请求被阻塞住了，订单提交变为失败，对用户体验造成了影响。
担任 DBA 这个角色，要在 5 分钟之内，迅速地定位锁等待的缘由，去解决阻塞方面的问题，让业务能够恢复到正常状态，与此同时还要制定出长效的方案用以避免再次出现这种情况。
A（行动）：
赶快迅速进行排查：首先，去执行show processlist来查看阻塞会话，进而定位锁持有方即SID；接着，去执行select * from information_schema.innodb_locks查询锁的类型，此类型是行锁，是因为在举行秒杀活动更新订单表同一行数据而导致的；最后，详细分析业务SQL，发现进行秒杀订单更新时没有添加行锁索引，从而致使行锁升级为了表锁。急急解决：其一，确认锁持有方不存在核心业务操作，进而执行kill去释放锁；其二，临时去调整MySQL锁等待超时时间（即set global innodb_lock_wait_timeout=5），以此避免会话长时间阻塞；其三，针对订单表更新字段增添联合索引，从而规避行锁升级。业务需配合：通知研发团队对秒杀SQL予以优化，采用乐观锁（版本号）来替换悲观锁，防止同一行数据出现竞争。结果是，在 3 分钟内把锁等待雪崩给解决掉了，业务请求得以恢复到正常状态，订单提交成功率达到了 100%；借助索引优化以及乐观锁改造，后续的秒杀场景就再也没有出现过锁等待的问题，数据库的并发能力提升了 80%。另外，还有高级岗（5 年以上工作经验），涉及架构设计以及容灾备份。
关键要点在于，企业层面的数据库架构设计，跨机房的灾备措施，分库分表的实际落地，云数据库的融合实现，以及数据安全体系构建，着重在会进行设计，会开展规划，会达成落地。
请针对金融交易平台去设计出一套具备高可用性、高安全性的数据库架构，阐述设计原则，说明核心组件选型，讲述容灾方案？
解析 + 答题模板（金融级架构，符合等保三级）：
金融交易平台的主要需求在于，数据具备很强的一致性，交易拥有高额的可用性，数据不存在丝毫丢失，要能够符合合规审计要求，其设计原则是，“同城实施双活加上异地开展灾备、进行读写予以分离、构建分层架结构、安全始终优先”，核心架构设计情况如下：
核心数据库层：①，交易核心借助Oracle RAC 19c搭建起同城双活集群，达成秒级故障切换以满足强一致性；②，非核心业务运用MySQL MGR集群，开启了半同步复制，从而保证数据不会丢失；③，通过用MyCat来做中间件实现读写分离，将读请求分流至从库，把写请求发送至主库，由此提升并发能力。针对交易流水、用户日志这样的海量数据，存在一个分库分表层，采用Sharding - JDBC进行分库分表操作，按照用户ID来进行分库的动作，接着按时间来进行分表的动作，以此解决单库数据量过大的问题。容灾备份层，其一，同城灾备方面，Oracle RAC 与 MySQL MGR 集群在同城两个机房进行部署，网络延迟小于 5 毫秒，以此实现秒级切换；其二，异地灾备方面，借助 OGG 达成跨地域数据同步，异地机房延迟小于 30 秒，从而满足恢复时间目标小于 1 小时、恢复点目标等于 0 的灾备要求；其三，数据备份方面，采取全量备份加上增量备份再加上日志备份的方式，每天为全量备份，每小时执行增量备份，进行实时日志备份，备份文件在异地进行存储，且保留 30 天。安全监控层面，其一，数据安全板块，要针对用户手机号以及身份证做数据脱敏处理，还要开展数据库审计工作也就意味着记录所有操作这一过程，并且依据最小权限原则进行权限管控；其二，监控告警部分，得搭建起含Prometheus、Grafana以及Zabbix的监控平台，此平台要覆盖数据库CPU、IO、内存、锁等待、慢查询、同步状态这些方面，同时要进行多级告警，也就是通过短信、邮件以及企业微信来发送告警；其三，合规审计方面，需保留数据库操作日志长达180天，以此满足金融等保三级所提出的要求。
