ThreadLocal 是 一个用于存储线程私有变量的工具，它 为每个线程维护独立的变量副本，实现线程间数据隔离，避免了多线程并发访问的安全问题；还可在同一线程内完成上下文参数的隐式透传，避免方法间显式传参。 在并发编程中，我们习惯于讨论如何用“锁”来控制对共享资源的访问。但 ThreadLocal 提供了一种完全不同的思路：与其争抢，不如隔离。 ThreadLocal 的 设计初衷并非为了解决多

MySQL 最本质的特征在于其 逻辑架构与存储实现的完全解耦。这种分层架构决定了 MySQL 的生态灵活性，但也引出了独有的性能挑战与架构权衡。 分层MySQL 的 宏观架构自上而下严格划分为四层，层级间通过标准的 API 接口进行交互。 整体执行流程：客户端请求 → 网络连接层处理 → Server 层解析/优化/执行 → 存储引擎层做数据读写 → 文件系统层落地磁盘。 各层

从计算机科学的视角来看，数据库管理系统本质上是一个维护 ACID 特性的状态机。在单线程模型下，状态转换是确定的。然而，一旦引入并发，系统便陷入了混乱。 InnoDB 存储引擎的并发模块主要目的就是 在并发吞吐量与数据一致性之间寻找平衡。这是一个零和博弈——隔离性越高，并发度就越低。 并发带来的问题当多个事务同时操作同一份数据时，如果没有合适的隔离机制，可能会出现以下三种一致性问题： 脏读：一个

我们的故事从一个简单的 UPDATE 事务开始。 为了在 极致的性能（内存） 和 可靠（磁盘） 之间找到完美的平衡，InnoDB 内部有着一套复杂且环环相扣的机制。 到达引擎层之前还有很多步骤，本篇不涉及 Buffer PoolBuffer Pool 是 InnoDB 在 内存中开辟的一块区域，用来 缓存磁盘上的数据页和索引页。它是 InnoDB 性能的基石。 为什么要有 Buffer Poo