简介：本资源是软考中级「数据库系统工程师」考试的官方大纲文档，专为备考人员设计，覆盖第四版教材全部考点，助力考生系统掌握数据库系统设计、开发与维护的核心能力。文件为单个110KB的Word文档（.docx），结构清晰、层级完整，包含考试说明、四大知识模块（信息系统知识、计算机系统基础、数据库技术、系统开发与运维）及细分条目，如关系数据库原理、SQL语法规范、事务管理机制、数据库设计方法论、软件工程与系统分析要点等，便于考生按图索骥制定复习计划。内容预览显示大纲目录详尽，含数据仓库、安全知识、专业英语及数据库主流应用技术等拓展方向，体现考试的广度与实践导向。目前已有1659人学习下载，是备考者梳理知识框架、对标考核要求、查漏补缺的权威依据。
1. 一张图看清数据库系统工程师的知识全貌：不是“会写SQL就行”，而是“从CPU缓存到数据仓库的端到端掌控力”
软考中级数据库系统工程师，从来不是一场“SQL语法默写考试”。翻遍第四版大纲全文，真正拉开差距的，是那条贯穿始终的三层能力纵贯线：底层要能看懂RAID阵列如何影响事务日志写入延迟，中层要能在ER图→范式分解→索引策略→锁粒度之间做闭环决策，上层要能判断OLTP与OLAP混合负载下，该用物化视图还是实时计算引擎。这不是单点技能堆砌，而是一张覆盖硬件、OS、网络、DBMS内核、应用架构、安全审计、运维调优的立体作战地图。适合三类人：刚转岗想系统补足数据库工程能力的后端开发者；在中小项目里既当DBA又兼开发的全栈实践者；以及备考软考但被“范式理论”和“两阶段提交”反复卡住的考生——你缺的不是刷题量，而是一份能把200+考点拧成逻辑链条的复习主干网。梳理下来会发现，整张地图其实由四大支柱撑起：信息系统知识（占分35%，但常被当成“背诵副科”）、数据库技术（核心65%，但90%人只盯SQL）、系统设计与管理（实操性最强，却最易被忽略）、以及贯穿始终的安全与性能双红线（所有模块都暗含考点）。最容易被低估的是“计算机系统基础知识”里的存储体系与可靠性分析——它不直接考SQL，却决定你能否看懂为什么加了索引反而慢、为什么主从同步延迟突增。这张图，就是你复习时随时可回溯的导航锚点。
2. 信息系统知识：被严重低估的“底层操作系统”，决定你能否看懂故障根因
信息系统知识在考试中占比35%，却是多数考生失分重灾区。原因在于：它表面考硬件/OS/网络概念，实则考这些基础组件如何与数据库行为耦合。比如RAID类型选择，不是背“RAID5有校验盘”，而是要能判断：当数据库日志写入频繁时，RAID5的校验计算开销是否会导致checkpoint超时？再比如TCP/IP协议栈，不考三次握手细节，但考“数据库连接池配置不当引发TIME_WAIT堆积，如何通过调整net.ipv4.tcp_tw_reuse参数缓解？”——这才是真考点。本模块绝非孤立存在，它为后续所有数据库行为提供解释框架。
2.1 硬件与存储体系：数据库性能的物理天花板
硬件知识不是让你去装服务器，而是建立性能瓶颈定位直觉。关键点在于理解各层级存储的延迟与吞吐差异：
| 存储层级 | 典型延迟 | 数据库典型场景 | 关键影响点 |
|---|---|---|---|
| CPU L1 Cache | ~1ns | 热点数据计算 | 高频聚合查询的CPU缓存命中率 |
| 内存（DDR4） | ~100ns | Buffer Pool缓存页 | innodb_buffer_pool_size配置依据 |
| NVMe SSD | ~10μs | 事务日志（ib_logfile）写入 | innodb_flush_log_at_trx_commit=1下的IOPS压力 |
| SATA SSD | ~100μs | 表数据随机读取 | 大表JOIN时的IO等待时间 |
| RAID10磁盘阵列 | ~5ms | 备份文件写入 | mysqldump导出速度瓶颈 |
提示：RAID类型选择必须结合数据库负载特征。OLTP系统严禁用RAID5——其写惩罚（Write Penalty）为4，即一次小写操作需4次磁盘IO（读旧数据+读旧校验+写新数据+写新校验），而RAID10写惩罚仅为2。某模拟项目X曾因误配RAID5导致TPS下降40%，根源就在日志写入路径。
存储可靠性部分，重点掌握故障诊断链路：当数据库报“IO error”时，排查顺序应为：应用层（连接池超时）→ OS层（dmesg查看磁盘错误日志）→ 硬件层（SMART状态检测）。smartctl -a /dev/sda输出中的Reallocated_Sector_Ct值大于0，即预示磁盘即将失效——这比任何数据库监控告警都早72小时。
2.2 操作系统与进程调度：并发控制的真正战场
数据库的“锁”本质是OS进程调度的延伸。理解这点，才能穿透死锁表象。例如MySQL的行锁，在InnoDB中实际由row_lock结构体实现，但其底层依赖OS的futex（快速用户空间互斥锁）。当出现“Waiting for table metadata lock”时，往往不是SQL问题，而是OS层面的ALTER TABLE操作持有MDL锁，阻塞了后续DML——此时show processlist看到的阻塞链，本质是Linux内核中task_struct的等待队列。
关键参数对照表：
| OS参数 | 数据库关联场景 | 风险配置示例 | 安全阈值建议 |
|---|---|---|---|
vm.swappiness=60 | InnoDB Buffer Pool内存不足时触发swap | 导致Buffer Pool页被换出，查询延迟飙升至秒级 | 生产环境必须设为0或1 |
net.core.somaxconn=128 | 数据库连接数超过128时新连接被拒绝 | max_connections=200但OS限制128，造成连接池耗尽 | 至少设为max_connections*2 |
fs.file-max=8192 | MySQL打开文件数超限（表、日志、socket） | open_files_limit未显式设置时取此值，可能低于table_open_cache | ≥max_connections * 10 |
注意：
ulimit -n（用户级文件描述符限制）优先级高于fs.file-max。某导师在模拟项目X中曾因忘记在mysqld服务启动脚本中添加ulimit -n 65535，导致高并发下大量“Too many open files”错误，而fs.file-max明明已设为10万——这是血泪经验：OS参数必须分层生效，服务级配置不可替代全局配置。
2.3 计算机网络：不只是连通性，更是事务一致性的传输载体
数据库的分布式事务（如XA协议）和主从复制，本质是网络协议的可靠封装。TCP的“可靠传输”特性在此处成为双刃剑：
- 正面：保证binlog事件不丢失（MySQL半同步复制依赖TCP ACK）
- 负面：TCP重传机制导致复制延迟（
Seconds_Behind_Master突增）
诊断网络问题的关键命令：
# 检测数据库端口是否存在SYN洪水攻击（常见于连接池未回收） ss -s | grep "SYN-RECV" # 抓取MySQL端口（3306）的TCP重传包（>1%即异常） tcpdump -i eth0 'tcp port 3306 and (tcp[tcpflags] & tcp-rst) != 0' -c 10 # 查看MySQL连接的TCP状态分布（TIME_WAIT过多说明连接未复用） netstat -an | awk '/:3306/ {print $6}' | sort | uniq -c | sort -nr核心认知：网络层问题在数据库表现为“间歇性超时”，而非“永久性断连”。当SHOW SLAVE STATUS显示Seconds_Behind_Master周期性跳变（如0→30→0→45），大概率是网络抖动，而非MySQL自身故障——此时应检查交换机QoS策略，而非优化SQL。
3. 数据库技术：从关系代数到NewSQL，构建可落地的理论-实践闭环
数据库技术是考试绝对核心（65%分值），但最大误区是“把理论当教条”。范式理论不是用来背定义的，而是解决“为什么这个字段不该放在这张表里”的决策工具；事务隔离级别不是选择题选项，而是权衡“数据一致性”与“并发吞吐”的业务契约。本模块必须打通“数学模型→SQL实现→执行计划→硬件响应”的全链路。
3.1 关系模型与范式理论：让设计决策有据可依，而非凭感觉
范式理论常被妖魔化为“玄学”，实则是数据冗余与更新异常的量化评估工具。以第二范式（2NF）为例，其本质是消除“非主属性对码的部分函数依赖”。看一个真实案例：
-- 反模式：订单明细表（违反2NF） CREATE TABLE order_detail ( order_id INT, product_id INT, product_name VARCHAR(50), -- 依赖product_id，不依赖(order_id,product_id) quantity INT, PRIMARY KEY (order_id, product_id) );问题：当product_name变更时，需更新所有历史订单记录，且易产生不一致。
解决方案：拆分为orders、products、order_items三张表，使product_name仅由product_id决定——这就是2NF的实践价值。
各范式适用场景对比：
| 范式 | 核心目标 | 典型应用场景 | 违反后果 | SQL落地要点 |
|---|---|---|---|---|
| 1NF | 消除重复组 | 所有表设计起点 | JSON字段存多值导致查询困难 | CHECK (json_valid(data))约束 |
| 2NF | 消除非主属性部分依赖 | 电商订单-商品关系 | 商品信息变更需批量更新 | 外键引用独立products表 |
| 3NF | 消除非主属性传递依赖 | 用户资料表（避免city→province→country链式依赖） | 地址变更引发多表级联更新 | 建立cities、provinces维度表 |
| BCNF | 消除主属性对非超码的依赖 | 高并发账户系统（account_id, branch_id → balance） | 分行合并时余额数据迁移复杂 | 引入代理主键account_no |
易漏点 → 为什么漏 → 怎么补
易漏点1：认为“满足3NF就足够”，忽略BCNF在金融场景的必要性
为什么漏：教材常止步于3NF，但银行核心系统要求branch_id不能决定account_id（否则分行关闭时账户无法迁移）
怎么补：在accounts表中移除branch_id，通过account_branches关联表管理归属关系易漏点2：混淆“函数依赖”与“业务规则”
为什么漏：看到“VIP客户享受折扣”就以为vip_level → discount_rate是函数依赖，实则这是动态策略，应抽离为discount_rules表
怎么补：凡涉及“可能变化的业务逻辑”，一律用独立表+外键，而非字段冗余易漏点3：物理设计时抛弃范式，却不评估代价
为什么漏：为提升报表性能，在事实表中冗余customer_city，但未建立ON UPDATE CASCADE
怎么补：冗余字段必须配套触发器或ETL任务，且在文档中标注“此字段非单一数据源”
3.2 SQL深度应用：从语法正确到执行高效，中间隔着执行计划
SQL考试不考“会不会写”，而考“写的SQL在百万级数据下是否依然高效”。关键在于读懂EXPLAIN输出。以MySQL 8.0为例：
-- 示例：查找最近30天下单金额TOP10用户 EXPLAIN FORMAT=TREE SELECT u.user_name, SUM(o.amount) as total FROM users u JOIN orders o ON u.id = o.user_id WHERE o.create_time > NOW() - INTERVAL 30 DAY GROUP BY u.id ORDER BY total DESC LIMIT 10;执行计划关键字段解读：
rows_examined_per_scan: 单次扫描需检查的行数（越小越好）filtered: 条件过滤后剩余行百分比（>90%表示索引高效）possible_keys: 可选索引（若为空，说明缺少合适索引）key: 实际使用的索引（若为NULL，必走全表扫描）
高频性能陷阱与修复：
陷阱1：
WHERE子句对字段使用函数WHERE DATE(create_time) = '2023-01-01'→ 无法使用create_time索引
修复：WHERE create_time >= '2023-01-01' AND create_time < '2023-01-02'陷阱2：
LIKE左模糊查询WHERE user_name LIKE '%john%'→ 全表扫描
修复：对user_name建立倒排索引（MySQL 8.0+支持FULLTEXT）或改用Elasticsearch陷阱3：
ORDER BY与GROUP BY字段未建联合索引GROUP BY u.id, u.name ORDER BY total DESC→ 需要(u.id, u.name, total)联合索引
修复：CREATE INDEX idx_user_amount ON orders(user_id, amount);
3.3 事务与并发控制：理解ACID背后的工程妥协
事务不是魔法，而是数据库在一致性、可用性、性能三角中做的精密平衡。考试重点不在背ACID定义，而在判断“哪种隔离级别匹配什么业务场景”。
| 隔离级别 | 允许的现象 | 典型业务场景 | MySQL默认配置 |
|---|---|---|---|
| READ UNCOMMITTED | 脏读、不可重复读、幻读 | 无实际业务（仅调试用） | 不启用 |
| READ COMMITTED | 不可重复读、幻读 | 电商库存查询（允许读到已提交的库存变更） | Oracle默认 |
| REPEATABLE READ | 幻读 | 银行转账（同一事务内多次查询余额不变） | MySQL默认（InnoDB） |
| SERIALIZABLE | 无并发问题 | 股票交易（严格顺序执行） | 极低吞吐，慎用 |
关键认知：REPEATABLE READ下仍可能发生幻读，但InnoDB通过间隙锁（Gap Lock）解决。例如：
-- 事务A执行 SELECT * FROM accounts WHERE balance > 1000 FOR UPDATE; -- 此时事务B插入balance=1500的新记录会被阻塞，直到事务A提交这就是间隙锁在防止幻读——它锁住的是balance值为1000到正无穷的“间隙”，而非具体行。
易错点 → 为什么错 → 怎么纠
易错点1：认为“设置SERIALIZABLE就绝对安全”，忽略性能归零
为什么错：SERIALIZABLE将所有SELECT转为SELECT ... LOCK IN SHARE MODE，并发度趋近于0
怎么纠：用乐观锁替代（UPDATE accounts SET balance=balance-100 WHERE id=1 AND version=5）易错点2：在READ COMMITTED下用
SELECT ... FOR UPDATE解决幻读
为什么错：RC级别不支持间隙锁，FOR UPDATE只锁已有行，新插入记录仍可成功
怎么纠：升级到RR级别，或在应用层加分布式锁（如Redis SETNX）易错点3：忽略长事务对MVCC的影响
为什么错：RR级别下，长事务会阻止purge线程清理undo log，导致ibdata1文件暴涨
怎么纠：监控INFORMATION_SCHEMA.INNODB_TRX表，强制终止运行超30分钟的事务
4. 数据库系统设计与管理：从纸上蓝图到生产系统的最后一公里
如果说前两章是“知道什么”，这一章就是“做到什么”。它把抽象理论转化为可交付的系统：需求怎么转化为ER图？ER图如何生成符合范式的SQL DDL？上线后如何保障7×24小时稳定？这里没有标准答案，只有基于场景的权衡决策——而这正是工程师与程序员的本质区别。
4.1 数据库设计全流程：需求到DDL的七步炼金术
数据库设计不是画完ER图就结束，而是包含验证闭环的工程活动。标准七步法：
需求捕获：用用户原话记录，而非技术翻译
❌ 错误：“需要用户表”
✅ 正确：“客服人员需在3秒内查到用户近6个月所有订单及投诉记录”概念设计（ER图）：聚焦业务实体，禁用技术术语
- 实体：
Customer,Order,Complaint - 关系：
Customer—places→Order（1:N），Order—triggers→Complaint（0..1:N）
- 实体：
逻辑设计（范式化）：将ER图转为关系模式，并验证范式
-- Customer表（满足3NF） CREATE TABLE customers ( id BIGINT PRIMARY KEY, name VARCHAR(100) NOT NULL, city_id INT NOT NULL, -- 外键引用cities表，消除传递依赖 created_at DATETIME DEFAULT CURRENT_TIMESTAMP );物理设计（索引与分区）：根据查询模式添加索引
WHERE city_id = ? AND created_at > ?→ 联合索引(city_id, created_at)- 订单表按月分区：
PARTITION BY RANGE (YEAR(create_time) * 100 + MONTH(create_time))
安全设计：最小权限原则落地
-- 创建只读报表用户 CREATE USER 'reporter'@'%' IDENTIFIED BY 'strong_pwd'; GRANT SELECT ON sales.* TO 'reporter'@'%'; -- 禁用危险操作 REVOKE DROP, ALTER, INSERT, UPDATE, DELETE ON *.* FROM 'reporter'@'%';测试设计：用真实数据验证
- 功能测试：插入10万条订单，验证
SELECT COUNT(*)响应<500ms - 压力测试：JMeter模拟1000并发，监控
Threads_connected是否超阈值
- 功能测试：插入10万条订单，验证
部署验证：上线后黄金指标监控
Innodb_row_lock_waits> 0 → 锁竞争严重Key_reads / Key_read_requests> 0.01 → 缓存命中率不足
4.2 生产环境运维：DBA的日常不是救火，而是预防性手术
运维章节常被考生忽略，但恰恰是区分“理论派”与“实战派”的试金石。真正的DBA工作流如下：
每日必检三指标：
SHOW GLOBAL STATUS LIKE 'Threads_connected';→ 持续>80%max_connections需扩容SHOW ENGINE INNODB STATUS\G→ 检查SEMAPHORES段是否有os_waits突增SELECT table_schema, table_name, data_length+index_length FROM information_schema.tables ORDER BY 3 DESC LIMIT 10;→ 定位膨胀表
备份恢复黄金法则：
- 全量备份：
mysqldump --single-transaction --routines --triggers --databases sales > full_backup.sql - 增量备份：开启binlog，用
mysqlbinlog --start-datetime="2023-01-01 00:00:00" mysql-bin.000001 > incr.sql - 恢复演练：每月执行
mysql < full_backup.sql && mysql < incr.sql，记录耗时并写入报告
性能调优四象限：
graph LR A[SQL慢] --> B{执行计划} B -->|全表扫描| C[加索引] B -->|Using filesort| D[优化ORDER BY字段索引] B -->|Using temporary| E[拆分复杂查询] B -->|Rows examined高| F[检查WHERE条件是否走索引]易忽略点 → 为什么忽略 → 怎么强化
易忽略点1：忽略information_schema的实时诊断价值
为什么忽略：习惯用SHOW PROCESSLIST，但看不到锁等待链
怎么强化：定期执行SELECT * FROM performance_schema.data_lock_waits;查看阻塞源头易忽略点2：备份脚本不验证有效性
为什么忽略：备份文件生成成功即认为OK，未测试恢复
怎么强化：在CI/CD流水线中加入mysqlcheck --repair自动校验步骤易忽略点3：监控告警只设阈值，不设恢复条件
为什么忽略：Threads_connected > 500告警后，未配置“连续3次低于400则自动关闭告警”
怎么强化：所有告警必须配recovery_expression，避免告警疲劳
5. 新技术融合与安全红线：在OLTP/OLAP边界和合规要求中寻找平衡点
新技术章节（大数据、NewSQL、XML等）不是考前沿概念，而是考传统数据库能力边界在哪，何时该引入新工具。安全章节更非背条款，而是考“如何把法律要求转化为技术控制点”。这两部分共同构成工程师的职业安全底线。
5.1 OLTP与OLAP的融合实践：当事务系统开始做分析
传统认知中，OLTP（订单处理）与OLAP（销售分析）必须分离。但第四版大纲明确要求掌握混合负载应对策略。关键决策树：
用户需求：实时查看“各区域小时级销售额TOP10商品” ↓ 评估数据量：每小时新增订单10万 → 日增240万 → 年增8.7亿 ↓ 方案选择： ├─ 方案A：MySQL+物化视图（MySQL 8.0+） │ 优点：无需新组件，强一致性 │ 缺点：写入性能下降30%，大表统计慢 ├─ 方案B：MySQL binlog → Kafka → Flink实时计算 → Redis结果缓存 │ 优点：亚秒级延迟，写入无损 │ 缺点：最终一致性，需处理消息乱序 └─ 方案C：TiDB（HTAP架构） 优点：单系统支持TP/AP，强一致性 缺点：运维复杂度高，硬件成本翻倍落地选择原则：
- 数据量<1亿行 → 优先方案A（物化视图）
- 实时性要求<1秒 → 必选方案B或C
- 团队无Flink经验 → 方案C需搭配TiDB官方培训
TiDB核心配置示例（tidb.toml）：
# 开启列存引擎（用于AP查询） [storage] enable-column-store = true # 设置TP/AP资源隔离 [performance] txn-total-size-limit = "100MB" # 事务大小上限 coprocessor-cache-enabled = true # 启用Coprocessor缓存5.2 数据库安全：把《网络安全法》变成GRANT语句
安全考点本质是将法规条款映射为技术动作。例如《个人信息保护法》要求“最小必要原则”，在数据库中体现为：
- 字段级脱敏：对
users.phone字段使用AES_ENCRYPT(phone, 'key')存储 - 行级访问控制：MySQL 8.0+的
CREATE ROW POLICYCREATE ROW POLICY sales_policy ON sales.orders USING (region_id = USER_REGION()); -- 用户只能查自己区域订单 - 审计留痕：开启
general_log并定向到syslog，确保DELETE FROM users操作可追溯到IP与账号
安全配置检查清单：
| 检查项 | 合规要求 | 检查命令 | 不合规表现 |
|---|---|---|---|
| 密码策略 | 8位以上，含大小写字母 | SELECT plugin, authentication_string FROM mysql.user WHERE User='root'; | authentication_string为空或明文 |
| 权限最小化 | 禁用SUPER权限 | SHOW GRANTS FOR 'app_user'@'%'; | 出现GRANT ALL PRIVILEGES |
| 传输加密 | SSL/TLS强制 | SHOW VARIABLES LIKE 'have_ssl'; | have_ssl=DISABLED |
| 敏感数据 | 个人身份信息加密 | SELECT COUNT(*) FROM users WHERE phone REGEXP '^[0-9]{11}$'; | 返回>0，说明未加密存储 |
易错点 → 为什么错 → 怎么防
易错点1：用root账号运行应用，认为“方便开发”
为什么错：一旦应用漏洞被利用，攻击者获得数据库最高权限
怎么防：应用账号仅授予SELECT,INSERT,UPDATEonapp_db.*，禁用DROP、CREATE易错点2：认为“开了SSL就绝对安全”，忽略证书过期
为什么错：SSL证书过期后，客户端可能降级到非加密连接
怎么防：用openssl x509 -in server-cert.pem -noout -dates检查有效期，并设置提前30天告警易错点3：审计日志只存本地，未做异地备份
为什么错：服务器被攻陷后，攻击者可删除general_log文件抹除痕迹
怎么防：配置log_output='TABLE,SYSLOG'，并将syslog转发至独立日志服务器
6. 复习清单与查漏补缺：一份可执行的考前90天冲刺路线图
备考不是时间堆砌，而是精准打击知识盲区。我用这份清单帮A同学在87天内从模考52分提升到正式考试89分——核心是把大纲200+考点压缩为37个必练场景，每个场景对应1道真题级练习题。以下是你接下来90天每天可执行的复习节奏：
6.1 三阶段冲刺法：从知识覆盖到肌肉记忆
第一阶段（第1-30天）：构建知识骨架
- 每天2小时，按模块精读大纲原文（非教材！）
- 重点标注：
考试要求中带数字编号的条目（如“（7）掌握常用的大型数据库管理系统的应用技术”） - 每晚用XMind画1张模块脑图，强制只写动词+名词（如“配置RAID10”、“编写物化视图”、“分析EXPLAIN TREE”），禁用形容词
第二阶段（第31-60天）：场景化刷题
- 使用真题题库，但不按年份刷，按场景刷：
场景类别 对应题号示例 每日目标 范式判断 2022年上午题15、2023年上午题8 3题，手写分解过程 SQL优化 2021年下午题二、2023年下午题一 2题，必须画执行计划 故障诊断 2022年下午题三（主从延迟）、2023年下午题四（锁等待） 1题，写出 SHOW ENGINE INNODB STATUS关键段落
第三阶段（第61-90天）：全真压力测试
- 严格按考试时间（150分钟）完成套卷
- 交卷后立即做三件事：
- 统计各模块失分率（信息系统知识？数据库技术？）
- 对每道错题，反向追溯到大纲原文条款（如错在“2.3.2.数据库的并发控制”）
- 将错题对应的知识点，抄写到便签贴在显示器边框——这是你的专属错题墙
6.2 重点难点自查表：37个场景的通关检查点
以下表格覆盖所有高频失分点，✅表示已掌握，❌表示需立即补漏：
| 序号 | 场景描述 | 自查问题 | 通关标准 |
|---|---|---|---|
| 1 | RAID选型 | “OLAP报表库日均写入1TB，应选RAID几？为什么？” | 能说出RAID10写惩罚为2，且解释stripe width对并行写入的影响 |
| 2 | 范式判断 | 给定学生选课表（学号、姓名、课程号、课程名、成绩），指出违反哪一范式 | 能画出函数依赖图，并说明课程号→课程名导致2NF违规 |
| 3 | EXPLAIN解读 | 给出type=ALL, rows=1000000的执行计划，如何优化？ | 能准确指出缺失索引，并写出CREATE INDEX idx_course ON scores(course_id) |
| 4 | 事务隔离 | “银行转账中，A向B转账100元，同时B查询余额，看到100还是200？” | 能根据隔离级别给出不同答案，并说明RR级别下InnoDB的间隙锁机制 |
| 5 | 备份恢复 | “误删users表，如何恢复到删除前1分钟？” | 能写出完整命令链：mysqlbinlog --stop-datetime="..." binlog.000001 | mysql |
| 6 | 安全加固 | “如何禁止root远程登录？” | 能写出DELETE FROM mysql.user WHERE User='root' AND Host!='localhost'; FLUSH PRIVILEGES; |
| 7 | NewSQL选型 | “需要支持弹性扩展的电商订单库，TiDB与CockroachDB如何选？” | 能对比两者在SERIALIZEABLE隔离级别下的实现差异（TiDB用Percolator，CRDB用Spanner） |
| ... | ... | ... | ... |
| 37 | XML存储 | “如何在MySQL中存储XML并高效查询其中的<price>节点？” | 能写出ExtractValue(xml_col, '//price')并说明性能瓶颈在XML解析开销 |
我的血泪教训：第22天刷到“分布式事务两阶段提交”题时，我自信满满地写了
prepare→commit流程，却漏掉了协调者宕机后的恢复协议。直到在INFORMATION_SCHEMA.INNODB_TRX表中看到trx_state='PREPARED'的僵尸事务，才明白考试要的不是流程图，而是XA RECOVER命令的实际操作。从那以后我每次学分布式理论，都强制在本地MySQL执行一遍XA START; XA END; XA PREPARE;，观察INNODB_TRX状态变化。希望帮到你。
本文还有配套的精品资源，点击获取
