目录
一、2026届面试发生了什么
二、为什么这三样成了“必杀题”
三、三个核心机制拆解：别背了，理解它
四、一个真实案例：会与不会，差一个零
五、你现在能落地的三件事
六、你的项目如果挂了，你能自己找到根因吗
一、2026届面试发生了什么
上周一个粉丝给我发消息，说刚面完某大厂的后端实习。三面技术，每一轮都被问到同一个模式的问题：
“你说你用过MySQL，那解释一下MVCC怎么实现幻读的”
“你说你用过Redis，那RDB和AOF混合持久化下，宕机后恢复数据会丢多少”
“你说你调过JVM，那CMS和G1在并发标记阶段有什么区别”
他说他准备了很多八股文，但这些问题一问就卡住了。
我翻了一下近两个月十几个同学发来的面经，发现一个清晰的趋势：大厂不再问“Redis有哪些数据类型”这种程度的问题了。
2026届的面试，数据库、Redis、JVM这三个点，已经从“了解”变成了“必须能画出图、讲清冲突、算得出损失”的水平。
不是面试变难了。是筛选标准变了。
二、为什么这三样成了“必杀题”
本质是：大厂的核心业务瓶颈，99%落在数据层、缓存层、运行时层。
一个高并发电商系统，订单库撑不住，是数据库问题。热点商品把缓存打穿，是Redis问题。服务频繁Full GC导致RT飙高，是JVM问题。
面试官想招的不是“会用工具的人”，而是出问题时能在一小时内定位到哪一层、给出止血方案的人。
过去问“索引失效的场景”，是考察记忆。现在问“你线上遇到过索引失效导致慢查询吗，怎么复现的”，是考察你有没有真的踩过坑。
所以这三样成为“三连杀”，因为它们是线上故障的三个最核心战区。
三、三个核心机制拆解：别背了，理解它
你不需要背一百道题。你需要理解三个机制，用一套工程思维串起来。
- 数据库：MVCC不是魔法，是版本链
核心在于：InnoDB通过隐藏字段 + undo log + Read View，实现不加锁的读。
怎么做的：每一行数据有两个隐藏列——DB_TRX_ID（修改该行的事务ID）和DB_ROLL_PTR（指向undo log的指针）。更新时不覆盖原数据，而是生成一个新版本，旧版本链在undo log里。
为什么这么做：解决读写冲突。读操作读的是“快照”，不阻塞写；写操作加行锁，不阻塞读。这就是高并发下读性能不降级的根本原因。
解决了什么问题：可重复读隔离级别下的幻读问题。配合间隙锁，能保证一个事务内两次读同一范围，结果一致。
面试官真实追问：如果两个事务同时修改同一行，MVCC怎么防止丢失更新？
答案：MVCC不解决写写冲突。写写靠行锁，先拿到锁的事务提交后，后一个事务会看到版本变了，触发重试或报错。
- Redis：持久化不是备份，是恢复时间承诺
核心在于：RDB是内存快照，AOF是操作日志，混合持久化是两者的折中。
怎么做的：RDB通过fork子进程，将内存数据序列化到磁盘。AOF将每一条写命令追加到文件，重启时重放命令。
为什么这么做：RDB恢复快但可能丢最后一次快照后的数据。AOF丢数据少但恢复慢，尤其日志大的时候。混合持久化在AOF文件里先写RDB格式的基线数据，再写增量命令，兼顾恢复速度和数据完整性。
解决了什么问题：让你在宕机后，根据业务SLA选择能接受的数据丢失窗口和恢复时间窗口。
真实面经问题：如果Redis分配了10GB内存，RDB的fork瞬间会导致响应变慢吗？
会。fork时采用copy-on-write，父进程修改内存页会先复制再改，内存压力大时可能触发swap甚至OOM。解决方案：降低fork频率或使用无盘复制。
- JVM：垃圾回收不是“自动”，是“权衡停顿与吞吐”
核心在于：GC算法的演进，本质是在做三个指标的博弈——停顿时间、吞吐量、内存占用。
怎么做的：G1将堆分成大小相等的Region，不要求物理连续。标记时记录每个Region的垃圾比例，回收时优先回收垃圾最多的Region（Garbage First名字的由来）。
为什么这么做：CMS的并发标记阶段会产生浮动垃圾，且内存碎片严重。G1通过Region和预测模型，能把停顿时间控制在预期范围内（比如200ms）。
解决了什么问题：大堆内存（几十GB）下的可控停顿。以前用Parallel GC，Full GC可能停几秒；用G1或ZGC，可以把停顿降到几十毫秒级。
面试官追问：你们线上为什么从CMS换成G1？
真实回答：CMS的Full GC会串行标记，导致服务抖动。G1的Mixed GC能逐步回收Old区，抖动更平滑。
四、一个真实案例：会与不会，差一个零
去年一个团队遇到线上故障：每天下午3点，订单查询接口RT从20ms飙到3秒，持续15分钟后恢复。
不懂的人做法：重启服务、加机器、怀疑网络。
懂的人做法：先看慢查询日志，发现某个带order by create_time limit 10的查询扫描了50万行。看执行计划，索引用了(user_id, status)，但order by字段不在索引里，导致filesort。再看监控，3点正好是定时任务批量更新订单状态的时间，大量数据被锁或标记，统计信息失效，优化器选错索引。
解决方案：重建复合索引(user_id, create_time)覆盖查询，把order by变成索引有序扫描。同时设置innodb_stats_auto_recalc为ON，避免统计信息过旧。
从发现问题到定位根因，用了40分钟。不懂的人可能要重启三次、折腾半天。
这个差距，面试时一问就知。
五、你现在能落地的三件事
说给2026届和初级工程师听。这些事不需要进大厂才能做。
第一件事：别背题，去搭一个会“坏”的环境
本地用Docker跑MySQL、Redis、Java应用。写一个脚本故意制造慢查询、缓存穿透、内存泄漏。然后自己去排查。
怎么制造慢查询：在一个千万行的表里用where name like '%xxx%'。怎么制造内存泄漏：在Java里不断往static List里add对象。然后你会真正理解explain怎么看、jmap怎么用、Redis的latency monitor怎么输出。
第二件事：每个技术点画一张“故障决策树”
比如：Redis变慢了 → 先查slowlog get → 如果没有慢命令，再查info commandstats看哪个命令调用频繁 → 再查是否频繁fork（看latest_fork_usec）→ 再查是否内存碎片过高（mem_fragmentation_ratio）。
把这棵树画出来，面试时你说“我会按这个顺序排查”，比背十篇博客有用十倍。
第三件事：把“为什么这么做”贴在自己桌面上
你不是在学Redis持久化，你是在学“怎么在磁盘性能和数据安全之间做选择”。你不是在学JVM GC，你是在学“怎么用停顿换吞吐、用内存换速度”。
每次学一个机制，问自己三个问题：
它解决了什么痛点（没有它时会怎样）
它做了什么取舍（它没解决什么）
如果我来设计，我会怎么改
这才是面试官想听到的工程思维。
六、你的项目如果挂了，你能自己找到根因吗
回到最开始那个粉丝的问题。他后来告诉我，面试官给了他一个场景：
线上某接口P99延迟突然从50ms涨到2000ms，你只有一台机器的ssh权限，不能重启，不能回滚，你怎么在三十分钟内给出结论：是数据库慢、是Redis超时、还是JVM GC导致？
他当时没答出来。
我问你一个问题，不要求立即回答：
你现在写的代码或测的系统，如果明天上线后出现同样的突增延迟，你有现成的排查工具链和步骤吗？
如果没有，那面试官问的不是技术，问的是你是否真的在工程环境里被故障教育过。
