标签： innodb

发布于

MySQL架构与底层原理之：`MySQL`的`MyISAM`与`InnoDB`：其在锁粒度、事务和崩溃恢复上的核心区别。

MySQL架构与底层原理：MyISAM与InnoDB的核心区别 各位朋友，大家好！今天我们来深入探讨MySQL中两种最重要的存储引擎：MyISAM和InnoDB。虽然MySQL支持多种存储引擎，但MyISAM和InnoDB无疑是使用最广泛、最具代表性的。理解它们之间的区别，对于数据库设计、性能优化以及故障排查至关重要。 本文将以讲座的形式，围绕锁粒度、事务支持和崩溃恢复这三个核心方面，详细对比MyISAM和InnoDB，并结合代码示例，力求做到深入浅出、逻辑严谨。 1. 锁粒度：表锁 vs. 行锁 锁是数据库并发控制的重要机制。锁的粒度，指的是锁定的资源范围大小。锁粒度越小，并发度越高，但锁开销也越大。 1.1 MyISAM：表级锁 MyISAM采用的是表级锁。这意味着，当一个用户正在写（更新、插入、删除）一个表时，整个表都会被锁定，其他用户无法进行任何读写操作。同样的，当一个用户正在读一个表时，整个表会被共享读锁定，其他用户可以进行读操作，但不能进行写操作。 示例：模拟MyISAM表锁 虽然我们无法直接在MySQL客户端中模拟MyISAM的表锁行为（因为客户端本身会处理锁），但我们可 …

继续阅读“MySQL架构与底层原理之：`MySQL`的`MyISAM`与`InnoDB`：其在锁粒度、事务和崩溃恢复上的核心区别。”

发布于

MySQL架构与底层原理之：`InnoDB`的`B+Tree`索引：其在数据查找中的数据结构与存储原理。

好的，下面我将以讲座的形式，详细讲解MySQL InnoDB存储引擎的B+Tree索引，包括其数据结构、存储原理以及在数据查找中的应用。 MySQL InnoDB B+Tree索引：数据查找的基石 大家好，今天我们来深入探讨MySQL InnoDB存储引擎中至关重要的B+Tree索引。索引是数据库性能优化的关键，而B+Tree索引在InnoDB中扮演着核心角色。理解它的结构和原理，能帮助我们编写更高效的SQL，设计更优化的数据库Schema。 1. 索引的必要性：为什么需要索引？ 在没有索引的情况下，当我们执行SELECT * FROM users WHERE name = ‘Alice’这样的查询时，数据库必须扫描整个users表，逐行比较name字段是否等于’Alice’。这种全表扫描效率极低，时间复杂度为O(N)，其中N为表中的记录数。 索引的出现就是为了解决这个问题。索引本质上是一种排序的数据结构，它允许数据库快速定位到满足查询条件的记录，而无需扫描整个表。 2. B-Tree和B+Tree：索引的选型 在讨论B+Tree之前，我们先简单了解一下B-Tr …

继续阅读“MySQL架构与底层原理之：`InnoDB`的`B+Tree`索引：其在数据查找中的数据结构与存储原理。”

发布于

MySQL架构与底层原理之：`InnoDB`的`undo log`：其在事务回滚和`MVCC`中的作用。

MySQL InnoDB Undo Log：事务回滚与MVCC的基石 大家好，今天我们来深入探讨 MySQL InnoDB 存储引擎中一个至关重要的组件：Undo Log。它在事务回滚和 MVCC（Multi-Version Concurrency Control，多版本并发控制）中扮演着核心角色。理解 Undo Log 的工作机制，对于我们深入理解 MySQL 的事务特性和并发控制机制至关重要。 1. 什么是 Undo Log？ Undo Log，顾名思义，是一种用于撤销（undo）操作的日志。在 InnoDB 中，每当事务修改数据时，不仅会记录 Redo Log，还会记录 Undo Log。Undo Log 记录的是修改操作的反向操作，即如何将数据恢复到修改前的状态。 例如： 如果事务执行了 INSERT 操作，Undo Log 会记录一个对应的 DELETE 操作，用于删除该插入的数据。 如果事务执行了 UPDATE 操作，Undo Log 会记录更新前的数据值，用于将数据恢复到原始状态。 如果事务执行了 DELETE 操作，Undo Log 会记录被删除的行的所有列信息，以便重 …

继续阅读“MySQL架构与底层原理之：`InnoDB`的`undo log`：其在事务回滚和`MVCC`中的作用。”

发布于

MySQL架构与底层原理之：`InnoDB`的`redo log`：其在崩溃恢复中的`WAL`（`Write-Ahead Logging`）机制。

InnoDB Redo Log：崩溃恢复的基石 各位朋友，大家好！今天我们来深入探讨MySQL InnoDB存储引擎中一个至关重要的组件：redo log。理解redo log对于理解InnoDB的事务处理、崩溃恢复机制至关重要，它也是我们常说的WAL（Write-Ahead Logging）的核心实现。 1. 为什么需要 Redo Log？ 首先，我们思考一个问题：MySQL如何保证数据的一致性和持久性？如果每次修改数据都直接同步刷盘，性能会非常低下。磁盘I/O速度远低于内存操作速度。为了解决这个问题，InnoDB引入了缓冲池（Buffer Pool）机制。 缓冲池（Buffer Pool）： InnoDB会将数据页缓存在内存中，所有读写操作都在缓冲池中进行。这样可以显著提高性能。 但是，仅仅依靠缓冲池存在一个潜在的风险：如果数据库服务器突然崩溃，缓冲池中的数据尚未刷新到磁盘，就会导致数据丢失，破坏数据一致性。 这时候，redo log就派上用场了。它的核心作用是： 记录对数据页的修改： 当InnoDB修改缓冲池中的数据页时，会首先将修改操作记录到redo log中，然后再异步地将缓 …

继续阅读“MySQL架构与底层原理之：`InnoDB`的`redo log`：其在崩溃恢复中的`WAL`（`Write-Ahead Logging`）机制。”

发布于

MySQL架构与底层原理之：`InnoDB`存储引擎的`MVCC`（多版本并发控制）：`undo log`与`read view`的工作原理。

MySQL InnoDB MVCC深度剖析：Undo Log与Read View 各位同学，大家好！今天我们来深入探讨MySQL InnoDB存储引擎中一个非常核心的概念——MVCC（多版本并发控制）。MVCC是InnoDB实现高并发的关键技术之一，它允许事务并发地读写数据库，而无需加锁，从而显著提高系统的性能。 我们今天主要聚焦于MVCC中两个关键组件：Undo Log和Read View，彻底搞清楚它们是如何协同工作，来实现数据的一致性读取。 1. 什么是MVCC？ MVCC（Multi-Version Concurrency Control）即多版本并发控制。简单来说，它为每一行数据维护多个版本，每个版本对应一个事务对该数据的修改。当一个事务需要读取数据时，它会根据一定的规则读取特定版本的数据，而不是直接读取最新的数据。 这样，不同的事务可以同时读取同一行数据的不同版本，而无需互相阻塞。 2. MVCC解决的问题 MVCC主要解决以下问题： 读写阻塞问题： 传统的锁机制会导致读写操作相互阻塞，降低并发性能。MVCC允许读操作读取旧版本的数据，而无需等待写操作完成。 脏读问题： 事 …

继续阅读“MySQL架构与底层原理之：`InnoDB`存储引擎的`MVCC`（多版本并发控制）：`undo log`与`read view`的工作原理。”

发布于

MySQL高阶讲座之：`MySQL Heatwave`的架构：`InnoDB`和`Heatwave`引擎的混合工作模式。

各位观众老爷，大家好！我是你们的老朋友，今天咱们来聊点硬核的，说说MySQL HeatWave这玩意儿，它到底是怎么把InnoDB和HeatWave引擎揉在一起干活儿的。 开场白：MySQL的“速度与激情” 话说MySQL，这数据库界的老大哥，一直以稳定可靠著称。但随着数据量越来越大，查询越来越复杂，老大哥也开始有点力不从心了。就像一辆老式桑塔纳，虽然皮实耐用，但想跑出法拉利的速度，那是有点强人所难。 这时候，MySQL HeatWave就横空出世了。它就像给桑塔纳装了一个V12引擎，瞬间让查询速度提升了好几个数量级。而这个V12引擎，就是HeatWave引擎。 第一部分：InnoDB——MySQL的“老黄牛” 咱们先来回顾一下InnoDB，这可是MySQL的默认存储引擎，也是MySQL能成为数据存储基石的关键所在。 数据存储的基石： InnoDB负责数据的持久化存储，确保数据不丢失。 事务支持： ACID事务特性是InnoDB的看家本领，保证数据的一致性和完整性。 行级锁： InnoDB支持行级锁，并发性能更好。 索引： B+树索引是InnoDB查询优化的利器。 简单来说，InnoD …

继续阅读“MySQL高阶讲座之：`MySQL Heatwave`的架构：`InnoDB`和`Heatwave`引擎的混合工作模式。”

发布于

MySQL高阶讲座之：`MySQL`的`In-Memory`计算：`Memory`引擎与`InnoDB`缓冲池的性能对比。

各位观众老爷们，晚上好！我是老码农，今天给大家带来一场关于MySQL内存计算的“烧脑盛宴”——MySQL的In-Memory计算：Memory引擎与InnoDB缓冲池的性能对比。 准备好了吗？咱们这就开始！ 开场白：聊聊“内存”这回事 话说，在计算机世界里，速度就是生命。而内存，就像是CPU的超级跑车道，数据在里面跑得飞快。MySQL当然也深谙此道，搞出了各种内存相关的技术，目的只有一个：榨干每一滴性能！ 今天，我们就聚焦两种主要的内存计算方式： Memory引擎（原名HEAP）：一个纯粹的内存数据库引擎，数据全部加载到内存中。 InnoDB缓冲池（Buffer Pool）：InnoDB存储引擎的核心组件，用于缓存磁盘上的数据和索引。 这俩兄弟，虽然都住在内存里，但性格和用途却大相径庭。接下来，我们就好好扒一扒它们的底裤，看看谁才是真正的“内存之王”。 第一回合：引擎介绍及创建 Memory引擎：速度与激情的化身 Memory引擎最大的特点就是快！因为它把所有数据都放在内存里，读写速度几乎可以达到极限。但是，它也有一个致命的弱点：一旦MySQL服务器重启，或者发生崩溃，数据就全部丢失了 …

继续阅读“MySQL高阶讲座之：`MySQL`的`In-Memory`计算：`Memory`引擎与`InnoDB`缓冲池的性能对比。”

发布于

MySQL高阶讲座之：`InnoDB`的`AIO`（异步`IO`）：其在`Linux`和`Windows`下的实现差异。

各位朋友，大家好！我是你们的老朋友，今天咱们聊聊MySQL InnoDB里的一个重要角色——AIO（异步IO）。别看名字高大上，其实它就是提高数据库性能的一大利器。今天咱们就深入浅出地扒一扒 InnoDB 的 AIO，重点说说它在 Linux 和 Windows 下的实现差异。 开场白：IO的世界，同步与异步的爱恨情仇 在聊 AIO 之前，咱们先简单回顾一下同步 IO 和异步 IO 的区别。想象一下你去餐厅吃饭： 同步 IO: 你坐在座位上等着，服务员一道菜一道菜地上，你吃完一道才能等下一道。你必须全程等待，啥也干不了。 异步 IO: 你点完菜，跟服务员说：“好了，你们上菜吧，我先去看看风景，上好了叫我。” 然后你就可以去溜达了，等到菜上齐了，服务员会通知你。 对于数据库来说，IO 操作（读写磁盘）是非常耗时的。如果用同步 IO，数据库就得傻傻地等着数据从磁盘上读出来，CPU 就闲着没事干，这简直是资源的巨大浪费！所以，InnoDB 引入了 AIO，让数据库可以并发地处理多个 IO 请求，充分利用 CPU 的资源。 AIO的基本概念 AIO，全称 Asynchronous I/O，即异 …

继续阅读“MySQL高阶讲座之：`InnoDB`的`AIO`（异步`IO`）：其在`Linux`和`Windows`下的实现差异。”

发布于

MySQL高阶讲座之：`InnoDB`的`Page Cleaner Thread`：其工作机制与缓冲池的脏页管理。

各位观众老爷，大家好！我是今天的主讲人，给大家聊聊MySQL里InnoDB存储引擎的“清洁工”——Page Cleaner Thread，看看它如何管理缓冲池里的脏页，以及工作机制。 第一部分：啥是Page Cleaner Thread？为啥需要它？ 想象一下，你是一家餐厅的老板，后厨就是InnoDB的缓冲池（Buffer Pool），厨师（用户线程）不断地做菜（修改数据），用过的盘子（修改过的页，也就是脏页）堆积如山。如果你不及时清理，后厨就会变得乱七八糟，影响厨师的工作效率，甚至导致餐厅无法正常营业。 Page Cleaner Thread就是后厨的清洁工，它的主要任务是： 将脏页从缓冲池刷新到磁盘。 脏页是指缓冲池中被修改过但尚未同步到磁盘的页。 保持缓冲池的“干净”。 避免缓冲池被脏页占满，影响新数据的读写。 优化I/O性能。 通过合并相邻的脏页，减少磁盘I/O次数。 如果没有Page Cleaner Thread，脏页会堆积在缓冲池中，导致以下问题： 查询性能下降： 当缓冲池被脏页占满时，新的数据无法加载到缓冲池中，导致查询需要从磁盘读取，速度变慢。 事务提交延迟： 事务提交 …

继续阅读“MySQL高阶讲座之：`InnoDB`的`Page Cleaner Thread`：其工作机制与缓冲池的脏页管理。”

发布于

MySQL高阶讲座之：`InnoDB`的`Page`压缩：其压缩算法、`CPU`开销与存储收益。

各位观众老爷，晚上好！我是你们的老朋友，今天咱们来聊聊MySQL InnoDB 的 Page 压缩，这个听起来高大上，实际上就是省钱小能手。 InnoDB 的 Page 压缩，说白了，就是把数据页(Page)里面的重复内容，像打包行李一样，挤掉水分，让它体积更小。这样一来，同样的空间就能存更多的数据，省钱！而且，IO 效率也能蹭蹭往上涨，速度更快！但是，压缩是要消耗 CPU 的，所以，如何权衡压缩带来的收益和 CPU 的开销，这就是咱们今天要讨论的重点。 一、InnoDB Page 压缩算法：zlib、lz4 和 zstd InnoDB 支持多种压缩算法，最常见的有 zlib、lz4 和 zstd。 它们各有千秋，适用于不同的场景。 zlib: 经典老牌压缩算法，压缩率高，但速度相对较慢，CPU 消耗也较高。 适合对存储空间要求更高，对 CPU 消耗不敏感的场景，比如历史数据归档。 lz4: 速度快，压缩率相对较低，CPU 消耗也较低。 适合对性能要求更高，对存储空间不那么敏感的场景，比如实时数据查询。 zstd: 后起之秀，压缩率和速度都比较均衡，CPU 消耗也适中。 逐渐成为主流选 …

继续阅读“MySQL高阶讲座之：`InnoDB`的`Page`压缩：其压缩算法、`CPU`开销与存储收益。”