mysql 8.0 默认开启 innodb_file_per_table，需执行 show variables like 'innodb_file_per_table'; 确认返回 on；若为 off，则新建表将写入 ibdata1 共享表空间，delete/ drop 后空间不释放，而启用后 drop table 可直接回收磁盘空间。
MySQL 8.0 默认已开启 innodb_file_per_table，不建议关；如果你用的是 5.6.6+ 版本，它大概率也开着——但必须确认，不能靠猜。
怎么确认当前是否启用独立表空间
直接查变量最可靠，别信文档说“默认开启”就跳过验证：
-
SHOW VARIABLES LIKE 'innodb_file_per_table';—— 返回ON才算真开启 - 如果返回
OFF，说明表会写进ibdata1共享表空间，哪怕你新建的表也看不到.ibd文件 - 注意：该变量是动态可改的（
SET GLOBAL innodb_file_per_table = ON;），但只影响后续新建的表；已有表仍留在原表空间，不会自动迁移
为什么删了数据，磁盘空间却不释放
这是共享表空间最典型的痛点，而独立表空间能直接缓解：
- 在共享表空间（
ibdata1）中，DELETE或TRUNCATE只是标记空间为“可复用”，不会归还给操作系统 - 即使
DROP TABLE，空间也留在ibdata1里，文件体积只增不减 - 启用
innodb_file_per_table后，DROP TABLE会直接删除对应.ibd文件，磁盘空间立刻回收 - 如果只是大量
DELETE而不想删表，可用ALTER TABLE t ENGINE=InnoDB;重建表来收缩.ibd文件（注意锁表和磁盘临时空间）
迁移单表或恢复误删表时更可控
独立表空间让物理文件和逻辑表一一对应，实操中省掉很多麻烦：
-
mysqldump备份恢复是逻辑层，但有时你需要快速拷贝某张大表到另一个实例：cp /var/lib/mysql/dbname/t1.ibd /target/mysql/dbname/+FLUSH TABLES WITH READ LOCK;+IMPORT TABLESPACE就能完成（需严格匹配表结构、checksum、server_uuid） - 误删表但还有
.ibd和.frm（或 MySQL 5.7+ 的.sdi）时，比从ibdata1里抢救数据现实得多 - 分区表每个分区也生成独立
.ibd（当使用innodb_file_per_table时），方便按分区归档或迁移
大表增长过快时，问题暴露得更早
独立表空间不是万能的，但它把“隐性风险”变成“显性信号”：
- 单个
.ibd超过 100GB 不罕见，但你会一眼看到文件系统告警、备份变慢、ALTER TABLE时间飙升 - 而共享表空间下，
ibdata1涨到几百 GB 你也可能无感，直到磁盘爆满或备份失败才察觉 - 此时再切回独立表空间已来不及——必须导出全库重建，停机时间长；所以新实例上线前就该定好策略
- 真正需要警惕的不是“用不用独立表空间”，而是“有没有监控
.ibd文件大小增速”和“是否提前规划分区或归档”
