innodb

MySQL 的 REPEATABLE READ 到底能不能防幻读——从快照读、当前读到 Next-Key Lock“可重复读防不了幻读” 这句话，几乎每个学过数据库的人都背过。但只要你在 InnoDB 上动手做过实验，就会发现一个尴尬的事实：教科书上的结论，在这里经常对不上号——明明是可重复读级别，别的事务插进来的新行，怎么就是看不见？可换个姿势查询，它又冒出来了。同一张表、同一个隔离级别，幻读有时候防得住，有时候防不住，这中间的分界线在哪里？

二级索引与回表：一次回表到底多贵有个接口慢了很久，列表页 4 秒。SQL 长这样：city 上有索引。EXPLAIN 显示走了 idx_city，type=ref，看起来没毛病。

聚簇索引：为什么主键顺序决定插入性能去年帮一个团队看慢查询，打开数据库我就愣住了：一张 1200 万行的订单表，ibd 文件 22 GB。

聚簇索引 vs 二级索引：回表、覆盖索引、索引下推有一次帮同事看一条 SQL，4 秒。我只做了一件事：把 select * 换成了具体的三个列，然后加了一个联合索引。EXPLAIN 的 Extra 从 Using where 变成了 Using index，时间从 4 秒掉到 60 毫秒。

一条 SQL 从输入到返回，中间经历了什么三年前我在一家做 SaaS 的公司，手里有一张 800 万行的订单表。有天早上监控告警，后台的订单列表页从 200 毫秒涨到 4 秒。我先看了下 SQL，很普通：

我不会起名字322

MVCC 快照读为什么读不到刚提交的数据：ReadView 的 4 条可见性规则先复现一个让人怀疑自己学错了的现象。在 MySQL 的 InnoDB 存储引擎里，account 表中有这样一行 balance = 100，两个会话按顺序操作：

我不会起名字322

InnoDB 间隙锁与死锁：两个 UPDATE 互相等待的 3 个原因死锁日志大概是线上最容易被划过去、又最该点开看的一类告警。下面这段是我按真实格式整理出来的一个典型现场，两个 UPDATE 改的根本不是同一行数据，却一个在等另一个：

MySQL 死锁总复发？用螺旋事务相位互逆法定位加锁顺序（附 Python 诊断脚本）复盘的时候大家常说：但下周死锁又来了。用螺旋生成论的话，结论很直接：死锁不是“并发问题”，而是事务加锁相位互逆，两个事务各自拿着对方想要的锁，在相位空间里转成闭环。

MySQL 自增主键耗尽：从原理到应急恢复某天深夜，业务监控突然告警，数据库写入全部失败，错误日志显示 Duplicate entry '4294967295' for key 'PRIMARY'。DBA 紧急排查，发现核心业务表的主键 ID 已耗尽——表结构使用了 INT UNSIGNED 自增主键，最大值为 4294967295，而该表已经插入了 40 多亿行数据。由于主键无法复用，所有插入操作被拒绝，业务直接不可用。

从数组到 B+ 树：一棵树的进化史本文用因果链视角，把二叉搜索树、AVL 树、红黑树、B 树、B+ 树串成一条完整的演化线。每一环都是被上一环的副作用逼出来的——上一环的果，就是下一环的因。

MySQL-Innodb-表空间数据组织方式用MySQL的Innodb创建一个自定义用户表，会生成一个idb文件，这个文件存储了索引和用户数据，.idb文件就是表空间文件。

MySQL更新语句执行全流程：从Buffer Pool修改到二阶段提交更新语句的执行远比查询复杂。它不仅要在内存中修改数据，还要在崩溃时保证数据不丢、在主从之间保持一致。理解这条涉及undo log、redo log与binlog的写入链路，是你掌握MySQL事务与数据安全机制的必经之路。

江湖中的阿龙

【MySQL 深度进阶】从底层架构到实战调优：全面打通核心机制与底层原理标签：MySQL InnoDB 索引原理 MVCC 事务隔离 B+树数据库调优在后端日常开发与大厂面试中，MySQL 永远占据核心技术栈地位。仅停留在会写 SQL 远远不够，我们必须向下深挖，探究其底层存储模型、并发控制机制、内存管理逻辑。

MySQL存储引擎与索引深度解析MySQL采用分层插件式架构，核心分为4层，存储引擎是整个架构的核心，决定了数据的存储、读取、事务、锁等核心能力。

第六篇：Redo Log与Binlog——崩溃恢复的底层保障在前面的文章中，我们理解了事务的隔离级别和锁机制。但还有一个根本性问题没有解决：事务提交后，数据真的安全了吗？数据库突然宕机，重启后怎么恢复？

一叶飘零_sweeeet

击穿 MySQL InnoDB MVCC 底层：从 undo log、Read View 到隔离级别的全链路深度拆解在MySQL的日常使用中，我们几乎每天都在和事务隔离、并发读写打交道。当多个事务同时操作同一行数据时，为什么有的场景会出现脏读、不可重复读，有的场景却能保证数据一致性？为什么InnoDB能在高并发场景下保持远超其他存储引擎的读写性能？这一切的核心，都离不开InnoDB的多版本并发控制机制——MVCC。

InnoDB 锁机制：记录锁、间隙锁与临键锁在 MySQL 的 InnoDB 存储引擎中，锁机制是保证并发事务一致性和隔离性的核心机制。当我们谈论 InnoDB 锁时，经常会听到三个概念：记录锁（Record Lock）、间隙锁（Gap Lock）和临键锁（Next-Key Lock）。这三种锁机制共同构成了 InnoDB 的锁体系，对于解决幻读问题至关重要。

深度拆解MySQL InnoDB存储引擎架构：从内存到磁盘的全链路解析InnoDB的架构清晰分为两大核心部分：两者通过操作系统缓存（Operating System Cache）交互，核心流程为：数据先在内存中处理，再按规则刷入磁盘，兼顾性能与可靠性。

时序数据库InfluxDB应用『宝藏代码胶囊开张啦！』—— 我的 CodeCapsule 来咯！✨写代码不再头疼！我的新站点 CodeCapsule 主打一个 “白菜价”+“量身定制”！无论是卡脖子的毕设/课设/文献复现，需要灵光一现的算法改进，还是想给项目加个“外挂”，这里都有便宜又好用的代码方案等你发现！低成本，高适配，助你轻松通关！速来围观 👉 CodeCapsule官网

阅读MySQL实战45讲专栏总结这篇内容是我读完林晓斌老师的《MySQL实战45讲》的一个总结，第一次粗读了一遍，第二次精读并写了这篇总结文档。林晓斌老师的这个专栏，质量很高，感觉把以前的很多疑问都串起来了，看完对MySQL有了一个整体的认知，值得推荐！总结中也包含了自己学习时的一些思考，都有用高亮块标注。不过csdn不支持语雀的高亮块，显示成了:::info格式。