文章

发布于

MySQL存储引擎之：`InnoDB`的`Page`结构：`行记录`、`Page Header`和`File Trailer`的内部布局。

InnoDB Page 结构深度剖析：行记录、Page Header 与 File Trailer 大家好，今天我们深入探讨 MySQL InnoDB 存储引擎中最基础也是最重要的概念之一：Page 结构。理解 Page 结构对于优化数据库性能、排查问题以及更深入地理解 InnoDB 的工作原理至关重要。我们将详细分析 Page 内部的行记录、Page Header 和 File Trailer 的布局，并结合代码示例进行讲解。 1. Page 的概念 InnoDB 将数据存储在磁盘上，但每次读写操作并非直接针对磁盘扇区，而是以 Page 为单位。Page 是 InnoDB 存储的最基本单元，默认大小为 16KB。这可以减少磁盘 I/O 次数，提高性能。一个 Page 可以存储多个行记录，以及其他一些元数据信息。 2. Page 的整体结构 一个 InnoDB Page 主要由以下几个部分组成： File Header (38 字节): 包含 Page 的一些通用信息，如 Page 类型、校验和等。 Page Header (56 字节): 包含 Page 的状态信息，如 Page 中 …

继续阅读“MySQL存储引擎之：`InnoDB`的`Page`结构：`行记录`、`Page Header`和`File Trailer`的内部布局。”

发布于

MySQL存储引擎之：`InnoDB`的`Undo Log`：其在事务回滚和`MVCC`中的物理结构。

MySQL InnoDB 存储引擎：Undo Log 的深入剖析 大家好，今天我们深入探讨 MySQL InnoDB 存储引擎中一个至关重要的组成部分：Undo Log。我们将从事务回滚和 MVCC 的角度，详细解析 Undo Log 的物理结构及其在这些关键流程中的作用。 1. 事务回滚与 Undo Log 的关系 事务的 ACID 特性中的原子性（Atomicity）要求事务要么全部完成，要么完全不执行。如果事务执行过程中发生错误，或者用户主动发起回滚操作，就需要将数据库恢复到事务开始之前的状态。Undo Log 正是实现这一目标的关键。 Undo Log 记录了事务执行过程中对数据库的修改操作的逻辑逆操作。例如： 如果事务插入了一行数据，Undo Log 会记录删除该行的操作。 如果事务更新了一行数据，Undo Log 会记录更新前的原始数据。 当事务需要回滚时，InnoDB 会根据 Undo Log 中的记录，执行相应的逆操作，从而撤销事务对数据库的修改。 例子： 假设我们有一个 users 表，包含 id 和 name 两列。 CREATE TABLE users ( id …

继续阅读“MySQL存储引擎之：`InnoDB`的`Undo Log`：其在事务回滚和`MVCC`中的物理结构。”

发布于

MySQL存储引擎之：`InnoDB`的`Redo Log`刷盘机制：`innodb_flush_log_at_trx_commit`的`0, 1, 2`模式。

好的，下面开始讲座。 InnoDB Redo Log 刷盘机制深度剖析：innodb_flush_log_at_trx_commit 的 0, 1, 2 模式 大家好，今天我们来深入探讨 MySQL InnoDB 存储引擎中的一个至关重要的参数：innodb_flush_log_at_trx_commit。这个参数控制着 Redo Log 的刷盘策略，直接影响着数据库的性能和数据安全性。理解它的 0、1、2 三种模式的工作原理，对于优化 MySQL 数据库至关重要。 Redo Log 的作用与必要性 在深入 innodb_flush_log_at_trx_commit 之前，我们先回顾一下 Redo Log 的作用。InnoDB 是一个支持 ACID 事务的存储引擎。为了保证事务的持久性（Durability），即使在数据库崩溃的情况下，已提交的事务也不能丢失。Redo Log 就是为了实现这个目标而存在的。 当 InnoDB 修改数据时，它首先将修改记录写入 Redo Log Buffer 中。这个 Buffer 位于内存中，写入速度非常快。然后，InnoDB 会将 Redo Log …

继续阅读“MySQL存储引擎之：`InnoDB`的`Redo Log`刷盘机制：`innodb_flush_log_at_trx_commit`的`0, 1, 2`模式。”

发布于

MySQL存储引擎之：`InnoDB`的`Adaptive Hash Index`：其在内存中的`哈希索引`创建与淘汰。

InnoDB Adaptive Hash Index：内存哈希索引的创建与淘汰 大家好，今天我们来深入探讨InnoDB存储引擎中的一个重要特性：Adaptive Hash Index (AHI)。AHI是InnoDB为了提高查询性能而设计的一种自适应的内存哈希索引。它基于InnoDB监控到的索引访问模式，动态地在内存中创建哈希索引，从而加速频繁访问的数据的查找。 1. AHI 的基本概念 AHI并非是用户可以显式创建的索引，而是InnoDB存储引擎根据实际 workload 自动创建和管理的。它的目标是为那些经常被访问的二级索引页面（或者说二级索引的前缀列）建立哈希索引，从而实现接近 O(1) 的查找效率，显著提升查询性能。 1.1 为什么需要 AHI？ InnoDB使用B+树作为其主要的索引结构。B+树在范围查询和排序方面表现出色，但在精确匹配的查找上，其效率受到树高度的限制。特别是对于深度较高的B+树，多次磁盘I/O操作会成为性能瓶颈。 AHI通过在内存中构建哈希索引，将索引键直接映射到对应的B+树叶子节点或数据页的地址。这样，对于经常访问的索引键，可以避免多次B+树的遍历，直接定 …

继续阅读“MySQL存储引擎之：`InnoDB`的`Adaptive Hash Index`：其在内存中的`哈希索引`创建与淘汰。”

发布于

MySQL存储引擎之：`InnoDB`的`Change Buffer`：其在`DML`操作中的`写入合并`机制。

好的，下面是一篇关于InnoDB Change Buffer的讲座稿，重点讲解其在DML操作中的写入合并机制。 InnoDB Change Buffer：DML 操作背后的优化利器 大家好！今天我们来深入探讨 MySQL InnoDB 存储引擎中的一个关键特性：Change Buffer。它在 DML（Data Manipulation Language，即 INSERT, UPDATE, DELETE）操作中扮演着重要的角色，尤其是在处理非唯一索引时，能够显著提升性能。 1. 什么是 Change Buffer？ Change Buffer 是一种特殊的存储区域，位于InnoDB的系统表空间中。它的主要目的是为了优化针对非唯一二级索引的DML操作。 当需要修改的数据页不在 Buffer Pool 中时，InnoDB 不会立即将这些修改写入磁盘，而是将这些变更信息（Change）缓存在 Change Buffer 中。 之所以针对非唯一二级索引，是因为唯一索引的修改需要立即检查唯一性约束，必须读取磁盘。而对于非唯一索引，可以先缓存修改，稍后再合并。 2. Change Buffer 的 …

继续阅读“MySQL存储引擎之：`InnoDB`的`Change Buffer`：其在`DML`操作中的`写入合并`机制。”

发布于

MySQL高级特性之：`MySQL`的`SET`和`ENUM`：其在`SQL`类型设计中的性能考量。

MySQL高级特性：SET 和 ENUM 在 SQL 类型设计中的性能考量 各位同学，大家好！今天我们来深入探讨 MySQL 中两个特殊的枚举类型：SET 和 ENUM。它们在数据类型设计中扮演着重要的角色，尤其是在处理有限且预定义值的字段时。然而，如何正确地使用它们，以及它们对性能的影响，是我们需要重点关注的问题。 1. ENUM 类型：单选枚举 ENUM 类型允许你定义一个字符串列表，字段的值只能是列表中的某一个。这非常适合存储状态、类别等信息。 1.1 语法与示例 CREATE TABLE products ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(255) NOT NULL, status ENUM(‘active’, ‘inactive’, ‘pending’) NOT NULL DEFAULT ‘pending’ ); INSERT INTO products (name, status) VALUES (‘Product A’, ‘active’), (‘Product B’, ‘inactive’), (‘Pro …

继续阅读“MySQL高级特性之：`MySQL`的`SET`和`ENUM`：其在`SQL`类型设计中的性能考量。”

发布于

MySQL高级特性之：`MySQL`的`CREATE TABLE … LIKE …`：其在表结构复制中的应用。

MySQL高级特性：CREATE TABLE … LIKE … 在表结构复制中的应用 大家好，今天我们来深入探讨 MySQL 中一个非常实用但可能被忽视的特性：CREATE TABLE … LIKE …，并详细讲解它在表结构复制中的应用。 1. CREATE TABLE … LIKE … 语法详解 CREATE TABLE … LIKE … 语句允许我们创建一个新表，该表拥有与现有表完全相同的表结构，包括列定义、数据类型、键（主键、外键、唯一键等）、索引、以及其他表属性（如字符集、排序规则、注释等）。它只复制表结构，不复制数据。 其基本语法如下： CREATE TABLE new_table_name LIKE original_table_name; CREATE TABLE new_table_name: 标准创建表语句的开头，指定要创建的新表的名称。 LIKE original_table_name: 关键部分，指示 MySQL 从 original_table_name 复制表结构。original_table_name 必须是已 …

继续阅读“MySQL高级特性之：`MySQL`的`CREATE TABLE … LIKE …`：其在表结构复制中的应用。”

发布于

MySQL高级特性之：`MySQL`的`EXPLAIN FORMAT=JSON`：其在获取详细执行计划时的应用。

MySQL EXPLAIN FORMAT=JSON：解构执行计划的艺术 各位好，今天我们来深入探讨MySQL中一个强大的工具：EXPLAIN FORMAT=JSON。 相信各位在优化MySQL查询时，都使用过 EXPLAIN 语句来查看执行计划。 然而，传统的 EXPLAIN 输出往往信息不够详细，难以深入理解MySQL的执行逻辑。 EXPLAIN FORMAT=JSON 则提供了一种更结构化、更详细的方式来剖析执行计划，为我们优化查询提供更精准的指导。 1. 为什么需要 FORMAT=JSON？ 传统的 EXPLAIN 输出以表格形式呈现，每一行代表一个执行计划的步骤，并包含诸如 id, select_type, table, type, possible_keys, key, key_len, ref, rows, Extra 等列。 尽管这些信息很有用，但在以下情况下，它们可能不足以满足我们的需求： 复杂查询： 对于包含子查询、UNION、视图等复杂查询，传统的 EXPLAIN 输出可能难以清晰地展示整个执行流程，各个步骤之间的关系不够明确。 多表连接： 当涉及多个表的连接时，E …

继续阅读“MySQL高级特性之：`MySQL`的`EXPLAIN FORMAT=JSON`：其在获取详细执行计划时的应用。”

发布于

MySQL高级特性之：`MySQL`的`Invisible Columns`：其在`DDL`操作和应用兼容性中的作用。

MySQL Invisible Columns：DDL操作与应用兼容性的利器 大家好，今天我们来深入探讨MySQL 8.0版本引入的一项重要特性——Invisible Columns（不可见列）。这项特性在数据库设计、数据迁移、版本升级以及应用兼容性方面都扮演着重要的角色。我们将从概念、语法、应用场景以及性能影响等多个角度进行详细分析，并辅以实例代码，帮助大家理解如何在实际项目中有效利用Invisible Columns。 1. Invisible Columns的概念与语法 Invisible Columns，顾名思义，是指默认情况下对SELECT * 查询不可见的列。 这并不意味着这些列不存在或无法访问，它们仍然是表结构的一部分，可以像普通列一样进行插入、更新、删除和查询（显式指定列名）。关键在于，它们在默认的查询行为中被隐藏，这为数据库的改造和优化提供了极大的灵活性。 1.1 语法 创建Invisible Column的语法非常简单，只需在列定义中添加 INVISIBLE 关键字即可： CREATE TABLE employees ( id INT PRIMARY KEY, na …

继续阅读“MySQL高级特性之：`MySQL`的`Invisible Columns`：其在`DDL`操作和应用兼容性中的作用。”

发布于

MySQL高级特性之：`MySQL`的`Subquery Materialization`：子查询的物化策略。

好的，我们开始今天的讲座，主题是MySQL的子查询物化策略。 什么是子查询物化？ 在SQL查询中，子查询是指嵌套在其他查询（通常是SELECT, FROM, WHERE, HAVING子句中）内部的查询。MySQL执行包含子查询的语句时，需要决定如何处理这些子查询。其中一种策略就是“物化”（Materialization）。 物化是指将子查询的结果集存储到一个临时表中。这个临时表通常存储在内存中（如果足够小）或者磁盘上。后续的查询操作可以直接访问这个临时表，而不需要重复执行子查询。 为什么要进行物化？ 物化的主要目的是优化查询性能。它可以避免重复执行子查询，尤其是在子查询的结果被多次使用时。如果没有物化，每次需要用到子查询结果的时候，都需要重新计算一次，这会大大降低查询效率。 物化策略的类型 MySQL的优化器会根据不同的情况选择不同的物化策略，主要取决于子查询的类型和大小。常见的物化策略包括： 延迟物化（Lazy Materialization）： 只有在真正需要子查询结果时才进行物化。这可以避免不必要的物化操作，尤其是在外部查询可以通过其他条件过滤掉大部分数据时。 立即物化（Eag …

继续阅读“MySQL高级特性之：`MySQL`的`Subquery Materialization`：子查询的物化策略。”