【MySQL】MySQL如何存储元数据？

目录

1.数据字典的作用

2. MySQL 8.0 之前的数据字典

3. MySQL 8.0 及之后的数据字典

4.MySQL 8 中的事务数据字典的特征

5.数据字典的序列化

6. .sdi文件的作用：

7..sdi的存储方式

在 MySQL 中，元数据（Metadata） 是描述数据库对象（如表、列、索引、约束等）的结构信息。简单来说，元数据就是描述数据库里有哪些表、表里有哪些列、列是什么类型、谁有权限访问等信息。而数据字典是存储元数据的仓库。

1.数据字典的作用

数据字典存储了数据库的元数据，包括：

• 数据库对象信息：如表、视图、索引、存储过程、触发器等。
• 结构信息：如表的结构、列的数据类型、索引的类型等。
• 约束信息：如主键、外键、唯一约束等。
• 权限信息：用户和权限的元数据。

通过数据字典，MySQL 可以高效地管理和查询数据库对象的元数据。

2. MySQL 8.0 之前的数据字典

在 MySQL 8.0 之前，数据字典的元数据存储方式包括：

1. 文件存储：元数据存储在 .frm 文件（表结构文件）、.par 文件（分区表文件）等中。
2. 系统表：部分元数据存储在 information_schema  系统数据库（虚拟数据库，存储了 MySQL 服务器中所有数据库的元数据，只读）和 mysql 系统数据库中（仅存储 MySQL 核心元数据）。
3. 在 MySQL 8.0 之前，InnoDB 系统表主要用于存储 InnoDB 存储引擎的内部信息，不用于存储 MySQL 的全局数据字典。

缺点：

• 非事务性：元数据的更新不是事务性的，可能导致不一致。
• 性能问题：频繁的文件操作影响性能。
• 复杂性：元数据分散存储，管理复杂。

3. MySQL 8.0 及之后的数据字典

从 MySQL 8.0 开始，数据字典的实现发生了重大改进：

• 基于 InnoDB：元数据存储在 mysql 系统数据库中的、使用 InnoDB 存储引擎的表中，而不再存储在 ibdata1 文件里，支持事务性操作。

• 集中存储：所有元数据集中存储在 mysql 系统数据库下的数据字典表中。

• 事务性：元数据的更新支持事务，确保一致性。

• 性能提升：不再依赖 .frm 文件等外部文件存储元数据，减少了文件操作，提高了元数据访问性能。

4.MySQL 8 中的事务数据字典的特征

（1） 是所有 MySQL 服务器子系统的单一元数据存储库

统一存储：

• 在 MySQL 8.0 之前，元数据分散存储在不同的地方（如 .frm 文件、mysql 系统数据库等）。
• 在 MySQL 8.0 中，所有元数据集中存储在 数据字典表 中，这些表位于 InnoDB 数据字典表空间（mysql.ibd）。

跨存储引擎：虽然不同的存储引擎（如 InnoDB、MyISAM）有自己的用户表，但它们的所有元数据都存储在相同的数据字典表中，这种统一存储简化了元数据的管理和访问。

（2）基于标准 SQL 定义

标准化：数据字典表基于标准 SQL 定义，使用标准的表结构和查询接口。这使得数据字典更易于扩展和维护。

公共数据字典：所有存储引擎共享同一个数据字典，避免了元数据的冗余和不一致。

自动升级：在 MySQL 8.0 中，安装程序会自动处理数据字典的升级，确保从旧版本迁移时的兼容性。

（3）使用事务存储引擎 InnoDB

事务性：数据字典表使用 InnoDB 存储引擎，支持事务性操作（ACID 特性）。这意味着元数据的更新是原子性的，要么全部成功，要么全部失败。

原子 DDL：DDL（数据定义语言）操作（如创建表、修改表结构）现在是原子性的。例如，如果在创建表的过程中发生错误，MySQL 会自动回滚，确保数据库状态一致。

损毁安全：由于数据字典存储在 InnoDB 表空间中，即使发生崩溃或断电，InnoDB 的崩溃恢复机制也能确保元数据的一致性。

（4）改进的 INFORMATION_SCHEMA

性能优化：在 MySQL 8.0 中，INFORMATION_SCHEMA 的实现基于数据字典表，使用了标准的优化技术（如索引、缓存），这使得查询 INFORMATION_SCHEMA 的性能显著提升。

更易于维护：由于 INFORMATION_SCHEMA 直接访问数据字典表，不再需要复杂的文件解析和内存管理，这使得 INFORMATION_SCHEMA 的实现更简洁、更易于维护。

5.数据字典的序列化

在 MySQL 5.6 及之前，InnoDB 存储引擎将所有的数据字典信息存储在共享表空间（即 ibdata1文件）中。这种存储方式存在一些问题：

• 性能问题：由于数据字典的信息存储在共享表空间中，访问这些元数据时可能导致磁盘 I/O 瓶颈。
• 恢复效率低：在恢复数据库时，重新加载共享表空间中的数据字典信息可能导致较慢的恢复速度。
• 无法优化查询：由于数据字典在同一文件中，查询这些信息时的性能可能不是最优的。

因此，从 MySQL 5.7 开始，InnoDB 引入了 序列化字典机制，使得数据字典信息能够更高效地存储和访问。

MySQL 5.7 及以上版本中，InnoDB 使用 .sdi 文件（Serialized Dictionary Information）来专门存储序列化的数据字典信息，采用序列化格式存储。每个数据库会有一个对应的 .sdi 文件，用于存储该数据库的元数据，它包含了关于数据库、表、列、索引等的所有元数据，.sdi 文件中的数据是压缩的、序列化的元数据，MySQL 会在数据库启动时将其反序列化，以便快速访问。

序列化格式：这些元数据被序列化为一种压缩格式，InnoDB 可以在需要时快速反序列化并使用这些信息。这种方式比之前将数据字典存储在共享表空间中更加高效，尤其在高并发访问时能减少锁争用。

序列化：当数据字典信息被更新时（例如创建表、修改列、添加索引等），SDI 文件是将JSON 格式的元数据序列化为二进制数据，存储在 .sdi 文件中。序列化过程确保了元数据存储的高效性，并且节省了空间。

反序列化：在查询或操作数据库对象时，MySQL 会将 .sdi 文件中的序列化数据反序列化为可用的元数据格式。反序列化操作是在需要访问元数据时进行的，通常是高效且快速的。

6. .sdi文件的作用

每次元数据发生更改时（如创建、修改或删除表），MySQL 会自动生成它的副本 .sdi 文件。元数据以 JSON 格式序列化。

• 元数据备份：在元数据更改时，保存当前状态的副本，便于备份、恢复或迁移。
• 数据一致性：确保元数据与数据文件的一致性，避免损坏或丢失。
• 跨存储引擎支持：为不同存储引擎（如 InnoDB 和 MyISAM）提供统一的元数据管理机制。

7. .sdi的存储方式

MySQL 根据存储引擎的不同，将 .sdi 存储在不同的位置：

（1）InnoDB 存储引擎

• 存储位置：存储在 InnoDB 用户表空间 中，与表的数据一起存储。
• 文件格式：被嵌入到表空间文件（.ibd 文件）中，作为表的一部分。
• 优点：元数据与数据存储在一起，便于管理和恢复。

（2）MyISAM 存储引擎

• 存储位置：存储在数据库目录中，作为独立的文件。
• 文件格式：以 .sdi 文件的形式存储，文件名与表名对应。
• 优点：独立文件便于查看和备份。

Q：那这里就有一个疑问，.sdi文件是如何为不同存储引擎（如 InnoDB 和 MyISAM）提供统一的元数据管理机制？

A：主要通过以下三种方式：

1.统一的元数据格式：无论使用 InnoDB 还是 MyISAM，SDI 的 JSON 结构是统一的，使用 JSON 格式存储元数据。

2.MySQL 提供了一个统一的数据字典 API，用于访问和管理 SDI 数据。无论底层存储引擎是 InnoDB 还是 MyISAM，上层应用（如 MySQL 服务器）都通过相同的接口读取和写入元数据。

3.统一的元数据恢复机制：在数据库崩溃或元数据损坏时，无论是 InnoDB 还是 MyISAM，，MySQL 可以通过 SDI 恢复元数据。当需要将表从一个存储引擎迁移到另一个存储引擎时，SDI 提供了一种统一的元数据表示形式。例如，可以将 MyISAM 表的 .sdi 文件解析后，直接应用到 InnoDB 表。

总之，SDI 通过统一的 JSON 格式和数据字典 API，为不同存储引擎（如 InnoDB 和 MyISAM）提供了一种一致的元数据管理机制。尽管不同存储引擎在物理存储方式上有所差异，但 SDI 确保了元数据的统一性、可移植性和可恢复性，从而简化了 MySQL 的元数据管理。