MySQL 8.0 的 INFORMATION_SCHEMA 表不是 InnoDB 存储的，而是只读内存视图，数据源自 InnoDB 内部数据字典和内存结构，经 Server 层封装为 SQL 接口，无 .ibd 文件、不走事务流程、不可修改。
MySQL 8.0 的 INFORMATION_SCHEMA 表不是用 InnoDB 存储的——它们是只读的内存视图，底层不对应任何实际的 InnoDB 表文件，也不走 InnoDB 的事务、缓冲池或 redo log 流程。
这个误解很常见，因为 INFORMATION<em>SCHEMA</em> 里确实有大量以 INNODB* 开头的表（比如 INNODB_TABLES、INNODB_INDEXES），但这些只是 MySQL Server 层提供的元数据接口，背后由 InnoDB 存储引擎“提供数据”，而非“用 InnoDB 引擎存储”。
INFORMATION_SCHEMA 表为什么查起来像 InnoDB 表？
- 它们出现在
SHOW ENGINES输出中时，引擎类型显示为NULL或MEMORY（取决于版本和表），但从不显示为InnoDB； - 执行
SELECT ENGINE FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA='information_schema' AND TABLE_NAME='INNODB_TABLES';会返回NULL； - 这些表无法被
ALTER TABLE、TRUNCATE或INSERT，也没有对应的 .ibd 文件； - 它们的数据来自 InnoDB 内部数据字典（data dictionary）的实时快照，经 Server 层封装后暴露为 SQL 可查的视图。
INNODB_TABLES 等表的数据来源是什么？
- 数据直接读取自 InnoDB 的内存结构（如
dict_table_t、dict_index_t）和系统表空间（ibdata1或mysql.ibd中的 data dictionary 表）； - 部分字段（如
NUM_ROWS）来自INNODB_TABLESTATS，而该表本身依赖于内存中的统计缓存，不是持久化存储； -
INFORMATION_SCHEMA.FILES能查到./ibdata1、./ibtmp1、xxx.ibd等路径，是因为它解析的是 InnoDB 实际管理的物理文件列表，不是“把文件列表存进 InnoDB”。
为什么不能把 INFORMATION_SCHEMA 当成普通 InnoDB 表用？
-
SELECT COUNT(*) FROM INFORMATION_SCHEMA.INNODB_TABLES可能比查业务表还慢，因为它要遍历所有已打开的 InnoDB 表对象，触发内部扫描逻辑； - 如果你看到
INNODB_TABLESPACES返回空，不代表没有表空间——可能只是当前没有活跃的 general tablespace，或权限不足（需要PROCESS权限）； -
INNODB_TABLESTATS的NUM_ROWS是估算值，且未 ANALYZE 过的表可能显示0或陈旧值，不能用于精确计数； - 某些字段（如
DATA_FREE）在INFORMATION_SCHEMA.FILES中对 system tablespace 返回的是预留空闲页数，不是磁盘剩余空间。
真正容易被忽略的点是：这些表不是“存储引擎的产物”，而是“存储引擎的数据出口”。你查 INNODB_INDEXES，本质是在调用 InnoDB 的 C 接口获取索引元信息，不是在 SELECT 一张磁盘上的表。
