InnoDB存储引擎

wmze2025-06-19 19:07

架构图

上图是来自Mysql8.0官方文档 InnoDB存储引擎体系架构图 dev.mysql.com/doc/refman/...

内存结构（In - Memory Structures）

Buffer Pool（缓冲池）

缓冲池是主内存中的一块区域，InnoDB 在访问数据时会将表和索引数据、事务回滚信息、写优化的 Change Buffer ，以及辅助查询的自适应哈希索引、锁元数据等缓存于此。该缓冲池能够使经常使用的数据直接从内存中读取，从而加快处理速度。在专用服务器上，通常会将高达 80%的物理内存分配给缓冲池。

为了提高大量读取操作的效率，缓冲池被划分为能够容纳多行数据的页面。为了优化缓存管理，缓冲池被实现为由页面组成的链表形式；很少使用的数据会通过一种类似于最近最少使用（LRU）算法的变体从缓存中清除出去。

Buffer pool LRU算法

缓冲池是以列表的形式进行管理的，其采用了 LRU 算法的一种变体。当需要为缓冲池添加新页面时，会移除最近未被使用的页面，并将新页面插入到列表的中间位置。这种中间位置的插入策略将列表分为两个子列表：

  • 在最前面，是一组新的（"年轻"的）页面列表，这些页面是近期被访问过的。
  • 在末尾部分，是一组较早未被访问过的旧页面的子列表。

该算法将常用页面保存在新的子列表中。而旧的子列表则包含较少被使用的页面；这些页面就是需要被淘汰的候选对象。 默认情况下，该算法的运作方式如下：

  • 缓冲池的 3/8 部分被用于存放旧的子列表。
  • 列表的中间位置就是新子列表尾部与旧子列表头部相接的边界。
  • 当 InnoDB 将一页数据读入缓冲池时，它会首先将其插入到中间位置（即旧子列表的头部）。能够读取一页数据是因为它是在用户发起的操作（如 SQL 查询）中所必需的，或者是 InnoDB 自动执行的预读操作的一部分。
  • 访问旧列表中的某个页面会使该页面"变年轻"，将其移动至新列表的头部。如果该页面是因用户发起的操作而被读取的，那么首次访问会立即进行，该页面就会被标记为"年轻"。如果该页面是由于预读操作而被读取的，那么首次访问不会立即进行，甚至可能根本不会在该页面被移除之前发生。
  • 在数据库运行过程中，缓冲池中未被访问的页面会通过移动至列表尾部而"老化"。新旧子列表中的页面在其他页面变为新页面时也会老化。在旧子列表中，页面在中间位置插入时也会老化。最终，一个一直未被使用的页面会到达旧子列表的尾部并被清除。

默认情况下，通过查询读取的页面会立即被移动到新的子列表中，这意味着它们在缓冲池中的停留时间会更长。例如，进行 mysqldump 操作或带有无 WHERE 子句的 SELECT 语句时执行的表扫描，可能会将大量数据放入缓冲池，并清除等量的较旧数据，即便新数据以后再也不会被使用。同样，由预读后台线程加载并仅被访问一次的页面会被移动到新列表的头部。这些情况可能会将经常使用的页面推到旧子列表中，使其面临被清除的风险。

Buffer pool的管理

  • Free List（空闲链表 ） ：管理未被使用的缓存页。查询 / 修改数据时，若目标页不在 Buffer Pool，从 Free List 取空闲页加载磁盘数据，再移至 LRU List。

  • LRU List（最近最少使用链表 ） ：按 "热数据优先保留" 原则，分为热端（New Sublist，占约 5/8 ）和冷端（Old Sublist，占约 3/8 ） ：

    • 新加载页先入冷端头部，若后续被访问（如查询命中 ），则移至热端，避免全表扫描 "挤走" 真实热数据；
    • 内存不足时，淘汰冷端尾部的 "最少使用页"。

  • Flush List（脏页链表 ） ：记录被修改但未刷盘的缓存页（脏页 ），由后台线程按策略异步刷盘，保证数据持久化。

核心参数配置

参数名称 作用 推荐配置
innodb_buffer_pool_size Buffer Pool 总内存大小 建议设置为服务器物理内存的 50%~70%（如 32GB 内存设为 20GB）
innodb_buffer_pool_instances 实例数量 每 1GB 内存设 1 个实例（如 20GB 设为 20）
innodb_buffer_pool_chunk_size 每个 Chunk 的大小 默认为 128MB，通常无需修改
innodb_old_blocks_pct 冷数据区比例 默认 37（即 37%），全表扫描频繁时可提高到 50
innodb_old_blocks_time 冷数据激活时间 默认 1000ms，OLTP 场景可降低到 500ms 加速热数据识别
innodb_max_dirty_pages_pct 最大脏页比例 默认 10，高并发场景可提高到 50（需配合强磁盘性能）
innodb_io_capacity 磁盘 I/O 能力 HDD 设为 200 ~ 500，SSD 设为 2000~4000

Adaptive Hash Index（自适应哈希索引 ）

  • 作用：当从表中反复查询相同行时，它会自动接管查询，此时查询效率等同于哈希表，能加速查询，是 InnoDB 针对高频访问场景的优化手段，自动为频繁访问的索引条目创建哈希索引，无需手动配置。
  • 工作方式：基于对索引的访问模式动态构建，InnoDB 会监测索引的查询情况，对于那些被频繁访问的索引键值，建立哈希索引，后续查询可通过哈希查找快速定位数据，减少 B + 树索引的查找层级，提升查询速度 。

Change Buffer（变更缓冲区）

触发条件

当执行INSERT/UPDATE/DELETE操作时：

  • 命中条件 ：若修改的非唯一二级索引页不在缓冲池（Buffer Pool）中，InnoDB 会将变更写入 Change Buffer，而非立即读取磁盘页。

  • 排除情况：

    • 主键或唯一索引因需实时校验唯一性，不使用 Change Buffer。
    • 索引页已在缓冲池中时，直接修改页并标记为脏页。

变更记录过程

Change Buffer 记录的内容包括：

  • 操作类型：INSERT/DELETE MARK（逻辑删除）/PURGE（物理删除）。
  • 索引键值：被修改记录的索引键（如用户名、时间戳等）。
  • 页面位置：目标索引页的物理位置（表空间 ID、页号）。
  • 变更数据：新增记录的完整数据或删除标记。

合并（Merge）机制

Change Buffer 中的变更会在以下时机合并到实际索引页：

  • 被动合并：

    • 当目标索引页因查询被加载到缓冲池时，立即合并。
    • 缓冲池空间不足，页被驱逐前强制合并。

  • 主动合并：

    • 后台线程（page cleaner）定期扫描并合并。
    • 执行FLUSH TABLES或数据库关闭时。
    • 执行OPTIMIZE TABLE或重建索引时。

数据结构与存储

B + 树结构

Change Buffer 本身是一个内存中的 B + 树，按索引页号排序存储变更记录。其特点：

  • 高效查询：通过页号快速定位待合并的变更。
  • 批量处理：支持按页批量合并，减少随机 I/O。
持久化存储
  • 内存部分 ：Change Buffer 占用缓冲池的一部分（由innodb_change_buffer_max_size控制，默认 25%）。
  • 磁盘部分：变更记录会写入重做日志（Redo Log），确保崩溃恢复时不丢失。

与其他组件的协作

与缓冲池（Buffer Pool）的关系
  • 内存竞争：Change Buffer 与数据页、索引页共享缓冲池空间。若配置过大，可能导致热点数据被换出，反而降低性能。
  • 脏页管理 ：合并后的索引页会标记为脏页，由page cleaner线程异步刷新到磁盘。
与重做日志（Redo Log）的协作
  • 顺序写优化：Change Buffer 变更先写入 Redo Log（顺序 I/O），再异步合并到索引页（随机 I/O），将多次随机写转换为一次顺序写。
  • 崩溃恢复：重启时，通过 Redo Log 恢复 Change Buffer 中未合并的变更。
与双写缓冲区（Doublewrite Buffer）的关系

合并后的索引页通过双写缓冲区确保原子性写入，防止部分写失效（Partial Write Failure）。

关键参数

参数名 对二级索引的影响 默认值
innodb_change_buffer_max_size 控制 Change Buffer 占用缓冲池的最大比例，直接影响二级索引变更的缓存容量。值越大，可缓存的二级索引变更越多，但可能挤压数据页内存。 25%
innodb_change_buffering 控制对哪些操作启用 Change Buffer（如inserts/deletes），可针对二级索引的操作类型优化。 all
innodb_page_cleaners 控制后台清理线程数量，影响二级索引变更的合并效率。 4

Log Buffer (日志缓冲区)

一、Log Buffer 的本质定义​

  • ​内存结构 ​：固定大小的环形缓冲区（默认 ​256MB）

  • ​专属用途 ​：​唯一缓存 redo log records​（重做日志记录）

  • ​生命周期​：事务修改 → 生成 redo → 缓存 → 批量刷盘

  • ​核心定位​：

📌 关键特征：不与任何其他日志共享（Binlog/Undo Log有独立缓冲）

​二、核心作用与价值​
​作用维度​ ​实现机制​ ​业务价值​
​I/O性能优化​ 将碎片化redo日志合并为顺序大块写入 提升10x+事务吞吐量
​事务持久化保障​ 实现WAL(Write-Ahead Logging)关键环节 确保ACID中的持久性(Durability)
​系统稳定性​ 缓冲突发写负载（如秒杀场景） 避免事务阻塞与系统雪崩
​崩溃恢复基石​ 持久化redo日志用于重建未刷盘数据 保障数据一致性
​三、工作流程全景解析​

​触发机制三维度​：

  1. 事务提交驱动（高频触发，模式依参数而定）
  2. 空间压力驱动（防溢出保护）
  3. 时间周期驱动（兜底机制）
​四、调优参数矩阵表​
​参数​ ​默认值​ ​动态​ ​调优建议​ ​监控指标​
innodb_log_buffer_size 256 MB ✅ Yes 写密集型：512MB-2GB Innodb_log_waits>0则扩容
innodb_flush_log_at_trx_commit 1 ✅ Yes 1(强持久)/2(平衡)/0(高性能) Innodb_os_log_fsyncs
innodb_flush_log_at_timeout 1秒 ✅ Yes SSD建议0.5秒，HDD建议3秒 Innodb_log_write_requests
innodb_redo_log_capacity 100 MB×32 ✅ Yes ≥4GB (8.0.30+替代旧日志配置) LSN增长率

​黄金公式​：

理想容量=安全系数峰值日志量(MB/s)×容忍延迟(s)×1.5​

示例：峰值100MB/s日志 + 容忍2秒延迟 → 300MB缓冲

​五、组件关联图谱​
​关键关联详解​

  1. ​Redo Log Files​

    • 物理落盘目的地
    • 日志文件容量(innodb_redo_log_capacity)需匹配Buffer大小

  2. ​Buffer Pool​

    • WAL机制绑定：数据页修改前 → redo必须进Buffer
    • 崩溃恢复时：用磁盘redo重建Buffer Pool脏页

  3. ​Binlog​

    • 二阶段提交协作流程

  4. ​Checkpoint​

    • 推进Last Checkpoint LSN释放空间
    • Buffer刷新需保证不覆盖未checkpoint的日志

  5. ​OS Cache​

    • 刷盘中间层
    • 参数innodb_flush_log_at_trx_commit=2时依赖此层持久化

磁盘结构（On - Disk Structures）

System Tablespace（系统表空间，对应文件 ibdata1 ）

1. 理解

  • ​核心定义：​ ​ 系统表空间是 InnoDB 存储引擎的一个核心物理存储区域 ，对应磁盘上的一个或多个文件（默认通常是 ibdata1）。

  • ​8.0 之前 (如 5.7):​​

    • 这是一个多功能容器，通常包含：

      • InnoDB 数据字典 (Data Dictionary):​ 关于表、列、索引、外键等元信息的内部表。
      • Doublewrite Buffer:​ 用于提高页面写入可靠性（防止部分页写入）。
      • Change Buffer:​ 用于缓存对非唯一索引的更改（插入、删除、更新），后续再合并回主索引。
      • Undo Logs:​ 所有（或默认配置下的大部分）Undo Log 都存储在这里。
      • 用户表/索引数据 (可选但常见):​ 如果用户没有为表指定 FILE_PER_TABLE 或显式指定其他表空间，其数据和索引也存放于此。

  • ​8.0 的变化：​​

    • 数据字典迁移与形式改变：​ 最重要的变化！​ InnoDB 的数据字典表 (innodb_dynamic_metadata) 被存储为 InnoDB 表 并放置于系统表空间本身 ，取代了旧的 .frm 文件和基于文件的元数据存储。这使得数据字典完全由 InnoDB 管理，支持事务性 DDL。
    • Undo Logs 默认分离：​ 默认情况下，Undo Logs 不再 存储在系统表空间中，而是存储在独立的 Undo 表空间 (undo tablespaces)​ 里（通常是 undo_001, undo_002 等）。这极大地减轻了系统表空间的负担和增长压力。
    • 不再存储用户数据 (建议)：​ 强烈推荐 将用户数据存储在使用 innodb_file_per_table=ON（默认）设置下的独立 表名.ibd 文件中。系统表空间主要用于存储系统相关数据。
    • Serialized Dictionary Information (SDI):​ 系统表空间包含存储在 InnoDB 表空间文件（包括 .ibd 文件和 ibdata1）中的表/表空间元数据的冗余、序列化副本 (SYS_ 开头的隐藏表)，用于故障恢复等场景。
    • Doublewrite Buffer & Change Buffer:​ 这两个关键组件仍然存储在系统表空间中。
    • 内部系统表：​ 除了数据字典表，一些用于InnoDB内部管理的系统表（如 innodb_table_stats, innodb_index_stats 等的底层实现）也可能存储在此。
    • 临时表空间管理分离：​ ibtmp1 作为独立的全局临时表空间已被引入，专门处理临时表和磁盘临时表操作，不再占用系统表空间。

​8.0 系统表空间主要包含：​​

  • 内部（隐藏）的数据字典表 (innodb_dynamic_metadata)
  • Doublewrite Buffer
  • Change Buffer
  • Serialized Dictionary Information (SDI) 的物理副本
  • 其他必要的内部系统表结构
  • 不再包含 (默认)：​ Undo Logs, 用户数据表/索引。

2. 作用

系统表空间是 ​InnoDB 存储引擎启动和运行的基础，扮演着关键角色：

  1. ​元数据基石:​​

    • 存储事务性、内部管理的数据字典，为MySQL服务器提供关于数据库对象（表、列、索引等）的核心元信息。8.0的统一InnoDB表管理取代了分散的.frm文件。

  2. ​数据完整性保障:​​

    • Doublewrite Buffer:​ 确保数据页在写入磁盘过程中发生宕机时不会出现"部分写入"（页撕裂），是InnoDB崩溃恢复机制的关键一环。系统表空间为其提供固定存储位置。

  3. ​索引写性能优化:​​

    • Change Buffer:​ 缓存对非唯一辅助索引的修改操作（INSERT, DELETE-MARK, PURGE），后续在合适时机再合并回辅助索引树，显著减少随机I/O，提升写密集负载下的索引维护性能。

  4. ​系统内部管理:​​

    • 为InnoDB内部所需的其他系统结构和表（如统计信息表底表）提供存储基础。

  5. ​恢复支持:​​

    • 包含的SDI信息为在数据字典损坏或缺失时恢复表结构提供了最后一道防线（尽管这不是常规恢复操作）。

3. 工作原理

  1. ​物理结构:​​

    • 由一个或多个ibdataN文件组成（通常只有ibdata1）。
    • 文件大小和数量通过 innodb_data_file_path 配置。
    • MySQL实例启动时，InnoDB会初始化并管理这些文件。

  2. ​空间管理:​​

    • 使用Extents（1 Extent = 64 Pages = 1MB）和Segments进行空间分配管理。
    • 存在用于存放不同组件（如doublewrite, change buffer）的专门段。

  3. ​组件协同:​​

    • ​数据字典：​​ 当创建、修改或访问数据库对象时，系统表空间中存储的事务性数据字典表会被更新或查询。

    • ​Doublewrite Buffer：​ ​ 在脏页刷新刷出到ibd文件之前，它们会被先顺序地写入doublewrite buffer区域。当刷新完成到ibd文件后，doublewrite区域中的该页标记为旧可复用。

    • ​Change Buffer:​​

      • 发生对非唯一辅助索引的更改（非唯一索引是为了避免唯一约束检查）。
      • 该更改不是直接写入索引页，而是作为一条记录缓存在Change Buffer的 B-tree 中（位于系统表空间）。
      • 当相关索引页被后续读入Buffer Pool时，或者在后台由Purge线程处理时，缓存的变更会被合并（Merge）到实际的索引页中。
      • 合并操作涉及将Change Buffer记录的变更应用到Buffer Pool中的索引页，然后将该页标记为脏页等待刷新。

    • ​内存交互:​​

      • 系统表空间的关键部分（如Change Buffer索引结构、数据字典表的数据页）也会被加载到InnoDB Buffer Pool中进行操作。

4. 调优参数

8.0 版本的重大变化导致调优思路也与以前不同：

  1. ​**innodb_data_file_path (重要，8.0+ 可动态修改):​**​

    • ​功能：​ ​ 定义系统表空间文件的路径、初始大小、是否自动扩展 (autoextend)、扩展增量 (autoextend=<increment>)、最大大小 (max=<size>)。默认通常是 ibdata1:12M:autoextend。

    • ​调优考虑 (8.0+):​​

      • ​初始大小：​​ 由于主要存储系统数据，初始大小可以比5.7时代小很多。12M通常足够初始启动。监控实际使用情况。

      • ​是否autoextend：​ ​ 默认开启是合理的。​重要提示：​ ​ 一旦设定了 autoextend，​强烈建议 同时设置一个较大的 max 值（远超过预期需求），或者完全依赖文件系统可用空间（使用 max 可能导致空间耗尽问题）。

      • ​添加文件：​ ​ 8.0支持在线 添加额外的系统表空间数据文件 (ALTER INSTANCE ADD UNDO TABLESPACE ... 是给Undo用的；添加系统表空间文件是通过动态修改 innodb_data_file_path 在线完成的）。这在系统表空间快满时很有用，​优先于无限制扩展单个 ibdata1。

      • ​为何避免无限制 ibdata1:​​

        • 巨大的 ibdata1 难以备份和恢复（尤其使用物理备份工具）。
        • 即使删除用户数据（在旧版本或错误放在系统表空间），ibdata1 也不会收缩（只有truncate操作可能利用释放的空间）。

    • ​5.7 vs 8.0:​ ​ 在5.7及之前，此参数通常在初始化时设置，修改较困难。8.0支持动态修改（添加文件），更灵活。​永远不要手动删除或随意移动ibdata文件！​​

  2. ​**innodb_doublewrite (8.0+ 通常默认启用):​**​

    • ​功能：​ ​ 启用或禁用doublewrite buffer。ON（默认）。

    • ​调优考虑：​​

      • 默认启用：​ 强烈推荐保持开启 ，这对数据安全和崩溃恢复至关重要。禁用它（OFF）仅在极端磁盘负载（写入量巨大）​ 且能承受极低概率数据页损坏风险时才考虑（例如某些写入量极大且可重建的纯日志类型从库？）。禁用前必须彻底评估风险！
      • 几乎没有其他调优点：​ Doublewrite Buffer的位置固定，大小也相对固定（约128个页，即2MB*128=256MB? 实际实现上，doublewrite buffer包含两个区(extents)，每个区64个页，总共128个页。每个页16KB，总大小128 * 16KB = 2MB。这个内存区域主要用于批量写操作时的临时存放，但磁盘上的实际占用是在系统表空间的双写段上）。基本没有参数调节其大小或行为。

  3. ​**innodb_change_buffer_max_size (影响系统表空间大小):​**​

    • ​功能：​ ​ 设置Change Buffer最多能占用Buffer Pool 总内存大小的百分比 。默认 25（即25%）。

    • ​调优考虑：​​

      • 写密集型索引操作：​ 如果你的应用主要涉及大量的INSERT, UPDATE, DELETE操作，且受影响的表有许多非唯一辅助索引 ，增加此值（例如30-50）可以提升写性能和减少后续合并的I/O。注意：​ 这会使Change Buffer在系统表空间中存储更多的"变更记录"，增加ibdata1的增长压力和使用量（Change Buffer本身是存储在系统表空间中的B树）。
      • 读密集型/高更新率索引操作：​ 如果你的应用主要是读或者更新操作较少涉及辅助索引，或者辅助索引较少，可以适当降低此值（例如5-15），以节省Buffer Pool内存供其他用途（数据页缓存）。这也会减小Change Buffer对系统表空间的使用。
      • 监控：​ 使用 SHOW ENGINE INNODB STATUS\G 查看 INSERT BUFFER AND ADAPTIVE HASH INDEX 部分，观察Ibuf: size, free list len, inserts, merged 等指标评估Change Buffer的利用率和效果。监控系统表空间大小变化。

    • ​5.7 vs 8.0:​ ​ 参数本身作用相同。但在8.0下，因为系统表空间不再存储用户数据和Undo Log，Change Buffer对ibdata1的增长影响相对变得更加突出，调优此参数对空间管理的意义也更大。

  4. ​**innodb_flush_method (间接影响):​**​

    • 功能:​ 控制InnoDB如何刷新数据到磁盘（涉及文件系统和块设备层面的策略，如 O_DIRECT, O_DSYNC, fsync等）。
    • 调优考虑:​ 选择合适的刷新方法（在Linux上强烈推荐 O_DIRECT）​ 可以显著减少doublewrite buffer带来的额外写入开销，因为它避免了文件系统缓存导致的"双缓冲"。这间接提升了系统表空间相关I/O的效率。

5. 与其他组件的关联

  1. ​数据字典 & DDL:​​

    • 紧密耦合：​ 系统表空间存储了事务性的InnoDB数据字典表，是执行任何DDL（CREATE/ALTER/DROP TABLE/VIEW/PROCEDURE等）操作的核心依赖。DDL操作的元数据变更直接写入这里的事务性系统表。这是8.0原子DDL实现的基础。

  2. ​事务 (Transaction) & Undo Log:​​

    • 历史关联：​ 过去与Undo Log直接关联。在8.0+，Undo Log存储在独立的Undo表空间中，但事务所需的结构和Rollback Segment最初的信息仍与数据字典管理有关。Undo Log分离后显著解耦了其与系统表空间的I/O和空间压力。

  3. ​Doublewrite Buffer & Recovery:​​

    • 核心保障：​ 系统表空间为Doublewrite Buffer提供固定存储位置。在崩溃恢复阶段，InnoDB会检查Doublewrite Buffer区域，若发现待恢复的数据页在.ibd文件中不完整，则从Doublewrite中找回完整页副本进行修复。这是崩溃恢复成功的关键。

  4. ​Change Buffer & Secondary Indexes:​​

    • 性能优化枢纽：​ Change Buffer物理存储在系统表空间，通过延迟非唯一索引写入和合并操作，减轻了对用户表.ibd文件的随机I/O压力。它在优化辅助索引维护性能中扮演核心角色。

  5. ​Buffer Pool:​​

    • 内存缓存：​ 系统表空间中的活跃部分（如Change Buffer的结构、数据字典表的数据页）会被加载到Buffer Pool中进行操作。innodb_change_buffer_max_size 控制的是Change Buffer在Buffer Pool中的最大内存占用。

  6. ​Redo Log:​​

    • 协同保护：​ Redo Log保护所有对InnoDB数据页（包括系统表空间页）的物理修改。对系统表空间中Doublewrite Buffer、Change Buffer、数据字典页等内容的修改都会记录到Redo Log，确保崩溃时能重放恢复其状态。两者共同保障数据一致性。Redo Log存储在独立 的ib_logfileX文件中。

  7. ​临时表空间 (ibtmp1):​​

    • 功能分离：​ 在8.0之前，临时表相关操作可能用到系统表空间。8.0引入了全局临时表空间 (ibtmp1)​，专门处理磁盘临时表和InnoDB优化器临时表，完全独立于系统表空间，避免了后者因临时操作而膨胀。

  8. ​独立表空间 (表名.ibd) & innodb_file_per_table:​​

    • 解耦用户数据:​ 开启 innodb_file_per_table=ON (8.0默认)，用户数据和索引存储在独立的 .ibd 文件中，不再挤占系统表空间，简化了备份、恢复和空间管理。系统表空间专注于系统职能。

  9. ​**SYS Tables (SDI):​**​

    • 内嵌元数据：​ 系统表空间本身和每个独立的.ibd文件都内嵌了序列化的表/表空间元数据（SDI）。虽然存储在系统表空间本身，但其作用更在于独立表空间的元信息冗余存储（包含在.ibd文件中）。系统表空间中的SDI提供了一层系统级的冗余信息。

  10. ​InnoDB Persistent Optimizer Statistics:​​

    • 元数据存储：​ 表索引统计信息的持久化（通过 innodb_stats_persistent=ON, 8.0默认）数据存储在 mysql.innodb_table_stats 和 mysql.innodb_index_stats 表中（位于mysql系统数据库），但它们的底层InnoDB表实现 可能涉及系统表空间。这些表本身是普通InnoDB表，如果放在mysql库中且innodb_file_per_table=ON，它们会有自己的.ibd文件，但它们的元数据（表结构定义）仍然通过数据字典存储在系统表空间中。

Doublewrite Buffer Files（双写缓冲区文件 ）

是什么

  • ​本质：​ ​ Doublewrite Buffer 是 ​InnoDB 存储引擎中一个专门的内存区域及其在磁盘上对应的物理存储区域 ，它存在的唯一目的 是解决 ​Partial Page Write（部分页写入）​​ 问题。

  • ​物理存储：​​

    • 8.0 之前 (5.7及更早):​ Doublewrite Buffer 的磁盘存储区域 物理上位于系统表空间 (ibdata1)​ 内部。它是系统表空间中的一个专门段。
    • 8.0 的变化：​ MySQL 8.0 引入了 独立的 Doublewrite Buffer 文件 ，默认在数据目录 (datadir) 下创建，文件名类似 #ib_<通常为数字>_0.dblwr。这是一个完全独立 于系统表空间 (ibdata1) 的文件。

  • ​内存部分：​ ​ Doublewrite Buffer 在内存中（属于 Buffer Pool 管理范围的一部分）维护一个连续的块，用来暂存即将刷盘的数据页。大小通常是固定的 128 个页面 (2MB = 128 * 16KB)。

  • ​Partial Page Write 问题：​ ​ 现代存储系统（硬盘/SSD）通常以 512字节 或 4KB 的扇区/块为单位进行写入。而 InnoDB 的数据页大小默认为 16KB。如果一个 16KB 的页在写入 .ibd 文件的过程中系统崩溃或断电，操作系统或硬件可能只完成了部分扇区（比如前 4KB 或 8KB）的写入，导致该数据页在磁盘上损坏（部分新数据，部分旧数据）。这就是 "Partial Page Write"。这种损坏是无法通过 Redo Log 来修复的，因为 Redo Log 假设页面的物理内容是完整的，它只记录逻辑变化。

​一句话总结：​ ​ Doublewrite Buffer 是一块特殊的、用于在写入用户数据页到其最终 .ibd 文件位置之前，先将这些页完整写入一个 ​临时"暂存区"​​ (就是双写文件/区域) 的机制，其核心目标是防范部分页写入导致的数据页损坏。

2. 作用

  • ​核心作用：防止因部分页写入 (Partial Page Write) 导致的数据页物理损坏，确保崩溃恢复的有效性。​​

  • ​工作原理简述 (确保数据页物理完整性)：​​ 当一个脏页需要刷新到磁盘时：

    1. InnoDB 不是直接 将这个 16KB 页写入其目标 .ibd 文件中的位置。
    2. 而是 先将整个 16KB 页按顺序写入到 Doublewrite Buffer 文件中的连续位置。​
    3. 只有在 确认整个 16KB 页成功写入 Doublewrite Buffer 文件后 ，InnoDB 才将这个页写入最终目标 .ibd 文件中的实际位置。
    4. 写入 .ibd 成功后，Doublewrite Buffer 文件中的该页副本即可被覆盖复用。

  • ​崩溃恢复时的作用：​​

    • 当数据库崩溃重启进行恢复时，InnoDB 会扫描 Redo Log。
    • 在应用一个 Redo Log 条目来重做 (REDO) 一个数据页之前，InnoDB 会先检查该目标页在磁盘 .ibd 文件中的物理完整性。
    • 如果检测到该页是损坏的（极有可能是因为部分写入造成的），InnoDB 不会试图直接用 Redo Log 修改这个损坏的页（这很危险，可能导致进一步损坏或逻辑错误）。
    • 取而代之，它会从 Doublewrite Buffer 文件中找到该页的一个完好副本 （这个副本是在崩溃前成功完整写入的），用这个完好副本来覆盖 .ibd 文件中损坏的页。
    • 在确保了页面的物理完整性之后，InnoDB 再对其应用 Redo Log，进行逻辑上的重放，使数据页恢复到崩溃前的正确状态。

​简言之：​ ​ Doublewrite Buffer 文件为每个即将写入用户表空间的数据页提供了一个临时的、完好无损的备份副本。当目标页写入失败导致物理损坏时，它能提供一份救命的"原始"备份来恢复页面的物理完整性，从而使得依赖逻辑重放（Redo）的崩溃恢复机制得以顺利进行。​它是 Redo Log 能够有效工作的基础保障。​​

3. 工作原理

  1. ​刷盘触发：​​ Buffer Pool 中的脏页 (Dirty Page) 达到阈值或需要刷新时，InnoDB 的 Page Cleaner 线程负责将其刷出。

  2. ​写入双写缓冲 (Write to Doublewrite Buffer):​​

    • 待刷新的脏页首先被复制到内存中的 Doublewrite Buffer 区域。
    • 然后，整个 Doublewrite Buffer 内存区域 (通常包含多个连续待刷新的脏页)​ 按顺序、一次性 刷盘 (fsync) 写入到物理的 Doublewrite Buffer 文件 中。这是一个连续的、顺序的写操作。
    • 关键点：​ 必须 等待这次写入（并fsync）成功完成。

  3. ​写入实际位置 (Write to Final Location):​​

    • 确认 Doublewrite Buffer 文件写入成功后，每个脏页再被各自写入到其在最终目标 .ibd 文件中的实际物理位置 。这些写入通常是离散的、随机I/O。
    • 写入 .ibd 文件**不需要立即fsync**（依赖于操作系统的缓存刷新策略或稍后由 Redo Log 的 fsync 策略间接保证），因为物理完整性已由双写机制保护。

  4. ​释放资源：​​ 目标位置写入成功（或进入文件系统缓存）后，内存中的 Doublewrite Buffer 区域对应的槽位即可被新的脏页复用。

  5. ​崩溃恢复 (Crash Recovery):​​

    • 重启后，扫描 Redo Log。

    • 对于每个需要 REDO 的页面（由 Redo Log 条目标识），检查其在目标 .ibd 文件中的物理页面完整性 (checksum 校验等)。

    • ​如果校验失败 (页损坏)：​​

      • 从 Doublewrite Buffer 文件 (注意在 8.0+ 中搜索的是独立的 .dblwr 文件，而非 ibdata1 内部) 中找到该页的一个完好副本。
      • 用这个完好副本覆盖 .ibd 文件中损坏的页。
      • 然后，对这个已经物理恢复完好的页应用 Redo Log 中的逻辑修改。

    • ​如果校验成功 (页完整)：​​

      • 直接对该页应用 Redo Log 中的逻辑修改。

4. 调优参数

  • ​**innodb_doublewrite**​

    • ​功能:​​ 全局开关，控制是否启用 Doublewrite Buffer 机制。

    • ​默认值:​ ​ ON (强烈推荐)

    • ​调优:​​

      • ​几乎永远保持 ON:​ ​ ​这是最强烈、最重要的建议。​ ​ 禁用 Doublewrite Buffer (SET GLOBAL innodb_doublewrite = OFF) ​显著增加在崩溃后遭遇无法修复的数据页损坏的风险 。这种损坏可能导致数据丢失、表不可用 (Table is corrupted)、甚至实例启动失败。

      • ​考虑禁用的极端场景:​ ​ ​仅在以下情况下，经过极其严格的评估和风险接受后方可考虑临时禁用：​​

        • ​写入性能是绝对瓶颈。​ ​ 启用双写会带来一定的写放大（数据被写了两次）和额外的 fsync 操作。

        • 底层存储设备自身能保证原子写入 (atomic writes)​。例如：

          • 某些高端企业级 SSD 明确支持原生 16KB 原子写（如 Fusion-io, Intel Optane P4800X 等）。但需要极其谨慎地核实硬件和文件系统的支持情况。
          • O_DIRECT 模式本身不能 保证原子写！FUSE 文件系统或 ZFS 等提供写时复制（CoW）的文件系统可以减少部分页写入的风险，但通常不能完全等同于原子写保证，且性能开销可能与双写持平或更差。

        • 数据重要性不高，丢失或损坏可以忍受（例如临时数据、可完全重建的非关键从库）。​生产主库禁用几乎是自毁行为。​​

      • ​结论:​ ​ ​在绝大多数生产环境、公有云环境以及非特制硬件上，都必须且应该保持 innodb_doublewrite = ON。​​

    • ​5.7 vs 8.0:​​ 参数功能相同。但 8.0 双写文件独立后，其开销在理论上有轻微优化（文件系统缓存管理更独立）。

  • ​**innodb_doublewrite_files**​

    • ​功能:​ ​ ​8.0 新增参数。​ ​ 定义 Doublewrite Buffer 文件的数量。默认值通常为 2。

    • ​调优:​​

      • 通常不需要更改默认值。​
      • 潜在影响：​ 增加文件数量理论上允许有更多独立的写线程或队列服务于双写操作，在极高并发写负载 环境中可能 （微乎其微）减轻 innodb_doublewrite_dir 所在存储设备的压力。
      • 权衡：​ 增加文件数会增加文件描述符的使用。收益通常非常小。

    • ​5.7 vs 8.0:​ ​ 5.7 及之前没有此参数，双写区域固定在 ibdata1 内一个连续的段中，只有一个"区域"。

  • ​**innodb_doublewrite_dir**​

    • ​功能:​ ​ ​8.0 新增参数。​ ​ 指定独立 Doublewrite Buffer 文件的存储目录路径 。​默认值：​ ​ datadir（数据目录）。

    • ​调优:​​

      • ​考虑场景：​​

        • 如果你的 datadir 使用的是 HDD 或较慢的 SSD，而你有另一块非常快的 SSD/NVMe 设备专用于提高日志或临时文件性能。可能 （但性能提升通常极小且难以衡量）将双写文件移动到该快速设备上。
        • 空间不足/隔离：​ 数据目录所在分区空间紧张或有特殊隔离要求时，可指定其他位置。这是更实际的用途。

      • ​性能效果：​ ​ ​非常有限。​ ​ 双写写入是短暂的、顺序的写操作（虽然是 fsync），并且占整体 I/O 比例通常不大。将其放在与主数据/日志分离的超高速设备上，可能无法带来明显整体性能提升，反而增加了管理复杂性。将 Redo Log (ib_logfile*) 放到专用高速设备上的收益要明显得多（因为 Redo Log 的 fsync 是写入性能的绝对关键瓶颈）。

    • ​5.7 vs 8.0:​ ​ 5.7 及之前无法指定位置，只能存储在 ibdata1 所在目录。

  • ​**innodb_io_capacity / innodb_io_capacity_max**​

    • 间接影响：​ 这些参数控制 InnoDB 后台 I/O（包括刷新脏页）的整体吞吐量目标（IOPS）。Page Cleaner 线程的工作速率受此限制。由于双写操作是脏页刷新过程的一部分，因此设置过低的 I/O 容量可能会间接限制双写的速度，进而影响整体刷新速率和潜在的写入吞吐瓶颈（Buffer Pool 满了或 Redo Log 满了）。根据存储设备能力合理设置这些值，有助于保持系统流畅运行，间接支持双写机制。

5. 与其他组件的关联 (Relationships with Other Components)

  1. ​InnoDB Buffer Pool:​​

    • 来源：​ 需要刷盘的脏页来源于 Buffer Pool。
    • 内存区域：​ Doublewrite Buffer 的内存暂存区是 Buffer Pool 整体分配的一部分（虽然特殊）。在 Buffer Pool 初始化时分配。
    • 协作:​ Page Cleaner 线程从 Buffer Pool 的 flush lists 中选出脏页，先刷到双写缓冲区，再刷到最终位置。

  2. ​Redo Log (ib_logfile*):​​

    • ​保护前提：​ ​ ​双写缓冲区是 Redo Log 机制能够有效进行崩溃恢复的物理基础。​​ 没有双写保护页面物理完整性，如果发生部分页写入，Redo Log 也无法修复损坏的页，重放会导致错误数据。

    • ​协作顺序：​ ​ Redo Log 记录的是逻辑 变化（对页面的修改）。双写保护的是页面的物理完整性。在崩溃恢复时：

      • 先：​ 使用双写副本（如果需要）修复损坏页面的物理内容。
      • 后：​ 使用 Redo Log 应用逻辑修改 ，使页面回到崩溃前的最新状态。

    • ​**fsync 差异：​**​ Redo Log 写入后 fsync 是事务持久化 (D) 的保证点。双写文件的 fsync 是保证页面物理写入完整性的机制。两者目的不同。

  3. ​表空间文件 (.ibd Files):​​

    • 保护对象：​ Doublewrite Buffer 直接保护 的对象就是这些 .ibd 文件中的用户数据页（及其中的索引数据）。
    • 修复来源：​ 当 .ibd 文件中的页面在崩溃后被发现物理损坏时，Doublewrite Buffer 文件提供了唯一的可靠物理副本来源用于修复。
    • 独立分离 (8.0+):​ 在 8.0 之前，双写区域是 ibdata1 的一部分，而用户数据页在 .ibd 文件（如果 innodb_file_per_table=ON）。在 8.0 之后，双写有自己独立的文件，用户数据在 .ibd 文件，两者在物理文件上完全分离。

  4. ​系统表空间 (ibdata1):​​

    • ​历史关联 (Pre-8.0):​ ​ 在 8.0 之前，Doublewrite Buffer 的物理存储直接位于 ibdata1 文件内部，是该表空间中的一个固定段。

    • ​8.0 解耦：​ ​ 在 8.0 中，Doublewrite Buffer 迁移到了独立的 .dblwr 文件。这带来了以下好处：

      • 空间分离：​ ibdata1 不再需要包含双写区域，大小更可控。
      • I/O 隔离/解耦：​ 减少 ibdata1 文件的写入压力，特别是减少该文件上重要的 fsync 调用次数（双写 fsync 发生在自己独立文件上）。
      • 简化管理：​ 使 ibdata1 更专注于核心元数据存储（数据字典）和内部缓存（Change Buffer）。
      • 恢复可能性：​ 理论上增加了 ibdata1 严重损坏后，用户数据恢复的可能性（虽然可能性不大且非常复杂，因为 ibdata1 还包含数据字典等关键信息）。

  5. ​操作系统/文件系统/存储设备:​​

    • ​性能影响：​ ​ 双写操作带来的额外顺序写入和 fsync 是主要的性能开销来源。其性能高度依赖底层存储介质的写入速度和延迟（尤其是 fsync 的延迟）。

    • ​优化点 - innodb_flush_method:​​

      • 设置为 O_DIRECT（强烈推荐在 Linux 上使用 ）可以显著降低 Doublewrite Buffer 带来的开销。
      • 原因：​ O_DIRECT 绕过操作系统的 Page Cache，将双写直接写入设备。避免了一次 fsync（双写文件）导致操作系统将大量未刷新的脏用户数据页 (在 Page Cache 中) 也刷盘的连带效应。它使得磁盘写入更可控。

  6. ​崩溃恢复线程 (Recovery Threads):​​

    • 依赖：​ 恢复线程在扫描应用 Redo Log 前，对于需要 REDO 的每个页面，必须检查其物理完整性。
    • 修复操作：​ 如果检测到损坏，恢复线程负责定位到双写文件中的对应完好副本，并用其修复 .ibd 文件中的损坏页。

Undo Tablespaces（撤销表空间）

什么是Undo Tablespaces

Undo Tablespaces（撤销表空间）是MySQL中用于存储事务回滚信息的专用表空间。在MySQL 8.0中，Undo表空间经历了重大改进：

  • 与之前版本的区别：在MySQL 5.7及之前版本，undo日志存储在系统表空间(ibdata1)中；而8.0版本将undo日志分离到独立的表空间中

2. 作用

Undo Tablespaces的主要作用包括：

  1. 事务回滚：存储事务修改前的数据，以便在事务回滚时恢复原始数据
  2. MVCC实现：支持多版本并发控制，为读操作提供一致性视图
  3. 崩溃恢复：在数据库异常关闭后恢复未提交的事务

3. 工作原理

MySQL 8.0 Undo Tablespaces的工作机制：

  1. 独立存储：undo日志不再与系统表空间混合，而是存储在独立的.ibu文件中
  2. 动态管理：可以动态创建和删除undo表空间（8.0.14+）
  3. 循环使用：undo空间被组织为回滚段(rollback segments)，采用循环写入方式
  4. 自动截断：支持自动截断(truncate)不再需要的undo空间（8.0.23+）

4. 调优参数

MySQL 8.0中与Undo Tablespaces相关的重要参数：

参数 说明 默认值 与之前版本差异
innodb_undo_directory undo表空间存放目录 datadir 8.0新增
innodb_undo_tablespaces undo表空间数量 2(8.0.1-8.0.13) 0(8.0.14+) 8.0.14后默认为0表示自动管理
innodb_rollback_segments 每个undo表空间的回滚段数量 128 比5.7的128个全局回滚段更灵活
innodb_undo_log_truncate 是否启用undo日志截断 ON 8.0新增
innodb_max_undo_log_size 触发截断的undo表空间大小阈值 1GB 8.0新增
innodb_undo_log_encrypt 是否加密undo日志 OFF 8.0新增

​重要调整建议​：

  1. 在8.0.14+版本中，建议让InnoDB自动管理undo表空间数量
  2. 对于高并发系统，可适当增加innodb_rollback_segments
  3. 监控undo表空间大小，合理设置innodb_max_undo_log_size

5. 与其他组件的关联

  1. ​事务系统​：

    • 每个事务会分配一个undo日志记录
    • 与innodb_trx系统表密切相关

  2. ​存储引擎​：

    • 完全集成在InnoDB内部
    • 与redo log协同工作保证ACID特性

  3. ​缓冲池​：

    • undo页会被缓存在缓冲池中
    • 受innodb_buffer_pool_size影响

  4. ​临时表空间​：

    • 临时表的undo日志使用临时表空间而非undo表空间

  5. ​性能模式​：

    • 可通过performance_schema监控undo表空间使用情况

Redo Log（重做日志）

核心定义

Redo Log（重做日志）是InnoDB存储引擎的核心组件，是一种物理日志，记录了事务对数据页的物理修改信息，用于保证事务的持久性和崩溃恢复能力。

MySQL 8.0的重要改进

特性 MySQL 5.7 MySQL 8.0
架构 单线程写入 多线程并行写入
文件管理 固定大小需重启调整 支持在线动态调整（8.0.22+）
归档功能 不支持 支持redo log归档（8.0.17+）
加密 不支持 支持TDE加密
默认大小 48MB×2 256MB×2
原子DDL 不支持 完整支持

2. 核心作用

核心功能

  1. 崩溃恢复：数据库异常重启后，通过重放redo log恢复已提交事务
  2. 持久性保证：确保已提交事务不会因系统故障丢失
  3. 写优化：将随机写转换为顺序写，极大提升IO效率
  4. WAL机制：实现Write-Ahead Logging（先写日志后写数据）

MySQL 8.0增强

  • 并行恢复：多线程应用redo log加速崩溃恢复
  • 即时点恢复：通过归档redo log实现任意时间点恢复
  • DDL原子性：支持DDL操作的回滚和恢复

3. 工作原理详解

关键流程：

  1. 日志生成：事务修改数据前，生成redo log记录
  2. 缓冲区写入：日志先写入log buffer（内存）
  3. 刷盘策略：根据配置决定何时写入磁盘
  4. 循环写入：采用环状结构循环覆盖
  5. 检查点机制：标识已持久化的数据位置
  6. 崩溃恢复：从最近检查点重放redo log

MySQL 8.0优化：

  • 并行写入：多线程并发写入log buffer
  • 组提交优化：合并多个事务的fsync操作
  • 归档线程：独立线程处理redo log归档
  • 写放大优化：减少小事务的日志量

4. 调优参数及版本差异

关键参数配置

参数 默认值 说明 版本差异
innodb_log_file_size 256MB 单个redo文件大小 5.7默认48MB，8.0大幅增加
innodb_log_files_in_group 2 redo文件数量 相同
innodb_log_buffer_size 16MB 日志缓冲区大小 8.0支持动态调整
innodb_flush_log_at_trx_commit 1 刷盘策略 1-每次提交刷盘 2-写入OS缓存 0-每秒刷盘 8.0优化选项2的性能
innodb_log_write_ahead_size 8KB 预写块大小 5.7不可配置，8.0新增
innodb_redo_log_archive_dirs NULL 归档目录 8.0.17+新增
innodb_redo_log_encrypt OFF redo日志加密 8.0新增

MySQL 8.0新增命令

ini 复制代码 
sql
复制
-- 动态调整redo log大小（8.0.22+）
ALTER INSTANCE REDO_LOG RESIZE SIZE = 4G;

-- 启用redo log归档
SET GLOBAL innodb_redo_log_archive_dirs = 'archive:/path';

调优建议

  1. ​容量设置​：

    理想大小=(每小时写入量/3600)×2×安全系数

    • OLTP系统推荐4-8GB总量
    • 避免超过innodb_log_files_in_group×innodb_log_file_size > 512GB

  2. ​IO优化​：

    • 使用高速存储设备存放redo log
    • RAID卡配置带电池保护的write-back缓存

  3. ​安全策略​：

    • 金融系统：保持innodb_flush_log_at_trx_commit=1
    • 可容忍少量丢失：使用=2提升5-10倍性能

5. 与其他组件关联

1. InnoDB架构关系

2. 关键交互组件

组件 交互方式 MySQL 8.0优化
​Buffer Pool​ 脏页刷盘前必须先写redo log 并行刷新优化
​Undo Log​ undo页修改也记录redo undo空间独立管理
​Doublewrite​ 协同防止页断裂问题 取消二次写优化
​Binlog​ 通过XA保证一致性 增强的组提交
​Purge线程​ 清理前需要redo持久化 MVCC优化减少purge负载
​InnoDB表空间​ 记录数据文件修改 原子DDL支持

3. 性能监控

MySQL 8.0新增监控视图：

sql 复制代码 
sql
复制
-- 查看redo log状态
SELECT * FROM performance_schema.innodb_redo_log_files;

-- 监控写入负载
SELECT EVENT_NAME, COUNT_STAR 
FROM performance_schema.events_waits_summary_global_by_event_name
WHERE EVENT_NAME LIKE 'innodb/redo%';

6. 与历史版本的核心差异

架构差异

方面 MySQL 5.7 MySQL 8.0
​写入架构​ 单线程写瓶颈 多生产者-单消费者模型
​持久化机制​ sync_binlog和innodb_flush_log_at_trx_commit强绑定 解耦优化
​恢复速度​ 单线程应用日志 多线程并行恢复
​空间管理​ 需重启修改大小 在线动态调整
​DDL支持​ 部分DDL不可回滚 完整原子DDL
​物理格式​ 老版本格式 新版本支持更多数据类型

最佳实践

  1. ​容量规划​：

    sql 复制代码 
    sql
复制
-- 检查redo log使用峰值
SHOW GLOBAL STATUS LIKE 'Innodb_os_log_written';
    • 确保1小时产生的redo不超过总量的75%

  2. ​升级策略​：

    ini 复制代码 
    sql
复制
-- 5.7升级到8.0后优化
ALTER INSTANCE REDO_LOG RESIZE SIZE = 4G;
SET GLOBAL innodb_log_buffer_size = 64M;

  3. ​安全加固​：

    ini 复制代码 
    bash
复制
# 启用redo加密
ALTER INSTANCE ENABLE INNODB REDO_LOG ENCRYPTION;

  4. ​灾备方案​：

    sql 复制代码 
    sql
复制
-- 配置redo归档
SET GLOBAL innodb_redo_log_archive_dirs = 'bakdir:/mnt/redologs';
SELECT innodb_redo_log_archive_start('bakdir');

MySQL 8.0的Redo Log通过架构革新和功能增强，显著提升了数据库的可靠性、性能和管理灵活性，是现代MySQL高性能事务处理的核心基石。

File - Per - Table Tablespaces（独立表空间，对应文件如 t1.ibd、t2.ibd 等 ）

  • 启用条件 ：当innodb_file_per_table = ON（MySQL 8.0 默认开启 ）时，每个 InnoDB 表会对应一个独立的表空间文件（.ibd 后缀 ），文件名为表名.ibd，用于存储该表的数据和索引 。
  • 优势：方便管理，比如要删除一个表，直接删除对应的.ibd 文件即可；也便于进行一些独立的优化操作，如对单个表进行收缩、迁移等；还能一定程度上减少表空间的碎片化问题，因为每个表的数据相对独立存储 。

General Tablespaces（通用表空间，如 ts1.ibd、ts2.ibd 等 ）

  • 特点：是一种用户可创建和管理的表空间，可将多个表的数据存储在同一个通用表空间文件中（如 ts1.ibd 中可存 t3、t4、t5 等表 ）。它提供了更灵活的表空间管理方式，比如可以在创建表时指定将表放入某个通用表空间，适合一些对表空间有特殊规划和管理需求的场景，例如想将相关的几个表集中存储，便于统一管理和维护 。
  • 创建与使用 ：可通过CREATE GENERAL TABLESPACE语句创建，然后在创建表时，使用TABLESPACE子句指定该表要放入的通用表空间 。

Temporary Tablespaces（临时表空间，如 ibtmp1、temp_1.ibt 等 ）

  • 存储内容：用于存储临时表相关的数据，包括全局临时表（如 ibtmp1 (global) ）和会话级别的临时表（如 temp_1.ibt、temp_2.ibt 等 ）。临时表在会话或事务结束后，相关数据会被清理，临时表空间也会相应进行管理和回收 。
  • 作用：将临时表数据和普通表数据分开存储，避免对普通表空间造成影响，同时方便 InnoDB 对临时数据进行专门的管理和优化，比如在临时表空间的清理、回收等操作上，可根据临时数据的特点进行针对性处理 。
相关推荐
我的炸串拌饼店2 小时前
ASP.NET MVC 中SignalR实现实时进度通信的深度解析
后端·asp.net·mvc
挑战者6668883 小时前
springboot入门之路(一)
java·spring boot·后端
lifallen5 小时前
Java BitSet类解析：高效位向量实现
java·开发语言·后端·算法
子恒20056 小时前
警惕GO的重复初始化
开发语言·后端·云原生·golang
daiyunchao6 小时前
如何理解"LLM并不理解用户的需求,只是下一个Token的预测,但他能很好的完成任务,比如写对你想要的代码"
后端·ai编程
Android洋芋6 小时前
SettingsActivity.kt深度解析
后端
onejason7 小时前
如何利用 PHP 爬虫按关键字搜索 Amazon 商品
前端·后端·php
令狐冲不冲7 小时前
常用设计模式介绍
后端
Java水解7 小时前
深度解析MySQL中的Join算法：原理、实现与优化
后端·mysql
热门推荐
01扣子（coze）实战|我用扣子搭建了一个自动分析小红薯笔记内容的AI应用|详细步骤拆解02Coze扣子平台完整体验和实践（附国内和国际版对比）03KGG转MP3工具|非KGM文件|解密音频04DeepSeek各版本说明与优缺点分析05AI Agent | Coze 插件使用指南：从功能解析到实操步骤06从零安装 LLaMA-Factory 微调 Qwen 大模型成功及所有的坑07字节跳动“扣子空间”AI智能体全解析08零代码入门 | Coze——让大模型接入自己的数据库09YOLOv8入门 | 重要性能衡量指标、训练结果评价及分析及影响mAP的因素【发论文关注的指标】10免费可用！最强AI数字人对口型神器：让照片开口说话唱歌，支持多人对口型+全身动作，1分钟学会！（附保姆级教程）