通过SHOW TABLE STATUS查看Data_length和Data_free是否变化，结合SHOW VARIABLES LIKE 'innodb_file_per_table'判断：ON且值动态变化为独立表空间，OFF或所有表数据均在ibdata1中则为系统表空间。
怎么判断当前表用的是独立表空间还是系统表空间
InnoDB 默认开启
（MySQL 5.6.6+），但老库或手动关过就可能还在共享表空间（
）。别猜，直接查：
，看
是
后，重点盯
和
—— 如果值明显不为 0 且随数据增减变化，基本是独立表空间；如果所有 InnoDB 表的
都“挤”在
里，
返回
就坐实了。
MyISAM 完全没这问题：每个表固定对应
（数据）和
（索引）两个文件，一目了然。
迁移已有表到独立表空间要重做，不是改个配置就行
只对新创建的表生效。老表即使配置开了，仍躺在
里。想搬出来，必须重建：
—— 最常用，会锁表（Online DDL 在 5.6+ 支持部分场景，但
不保证一定不锁读）
导出再导入 —— 适合低峰期，但耗时长、需额外磁盘空间
注意：迁移后原
不会自动缩小，它只增不减。想真正释放空间，只能停库、导出全部数据、删掉
、重启、再导入 —— 生产环境慎用。
MyISAM 的 .MYD/.MYI 文件能直接 mv，InnoDB 的 .ibd 不行
MyISAM 表文件是自包含的，只要 MySQL 没在用，
安全；恢复时复制回来、
就行。InnoDB 的
文件不能这么干 —— 它和内存中的 buffer pool、redo log、数据字典强耦合。
真要移动 InnoDB 表文件，必须走正规流程：
MySQL（Linux）
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
下载
（先清掉内存里的元数据映射）
把
移到目标位置
（校验页 checksum、重建内存映射）
漏一步就会报错
或
。
独立表空间下 DROP TABLE 会立刻释放磁盘空间，MyISAM 也是，但共享表空间不会
这是最常被忽略的运维差异。开
时，
直接删掉
，磁盘空间秒还。MyISAM 同理，删
/
就完事。
但如果表还在
里（即
），
只清理数据字典和
内部的页标记，文件体积完全不变。你看着表没了，
还是那么大 —— 这就是为什么线上库 ibdata1 越跑越大却没法收缩。
所以，别只看配置开关，得确认表实际落在哪；删表前先
看看对应文件是否存在，比查文档更快定位问题。
innodb_file_per_tableibdata1SHOW TABLE STATUS LIKE 'your_table_name'EngineInnoDBData_lengthData_freeData_lengthibdata1SHOW VARIABLES LIKE 'innodb_file_per_table'OFF.MYD.MYIinnodb_file_per_table=ONibdata1ALTER TABLE your_table ENGINE=InnoDB;ALGORITHM=INPLACEmysqldumpibdata1ibdata1mv /var/lib/mysql/db/t1.MYD /backup/FLUSH TABLES.ibdALTER TABLE t1 DISCARD TABLESPACE;t1.ibdALTER TABLE t1 IMPORT TABLESPACE;Tablespace is missing for table 'db/t1'Failed to open tableinnodb_file_per_table=ONDROP TABLE t1t1.ibd.MYD.MYIibdata1innodb_file_per_table=OFFDROP TABLEibdata1ibdata1ls -lh