必须显式确认并配置innodb_file_per_table才真正生效：先执行SELECT @@innodb_file_per_table;或SHOW VARIABLES LIKE 'innodb_file_per_table';查值，返回1或ON才启用；需在[mysqld]段配置文件中设innodb_file_per_table=ON并重启MySQL，否则动态设置仅对新表生效且老表仍留在ibdata1。

innodb_file_per_table

必须显式启用才真正生效，MySQL 8.0+ 虽默认为 ON，但若初始化时跳过配置文件或用 --initialize-insecure，仍可能为 OFF；不查就开干，容易误判。

怎么确认当前是否已启用 innodb_file_per_table

别靠猜或看版本，直接查变量值：

• SELECT @@innodb_file_per_table; —— 返回 1 表示已启用，0 表示关闭
• SHOW VARIABLES LIKE 'innodb_file_per_table'; —— 查看 Value 列是 ON 还是 OFF

注意：即使返回 ON，也得检查是否写在配置文件里。动态设置（如 SET GLOBAL innodb_file_per_table = ON;）只对后续新建表生效，且 MySQL 5.6 及更早版本不支持该动态修改。

在哪改、怎么改才永久生效

必须编辑 MySQL 配置文件（如 /etc/my.cnf 或 /etc/mysql/mysql.conf.d/mysqld.cnf），且严格放在 [mysqld] 段下：

• 加一行：innodb_file_per_table = ON（MySQL 5.6+ 推荐用 ON，旧版也认 1）
• 绝不能写在 [client]、[mysql] 或其他段里，否则无效
• 改完必须重启 MySQL 实例：systemctl restart mysql 或 service mysqld restart

重启后再次查变量，确保值稳定为 ON —— 否则说明配置没加载成功（常见于路径错、段名错、语法错）。

开了之后老表还在 ibdata1 里，怎么办

启用 innodb_file_per_table 不会自动迁移已有表，这是最常被忽略的事实：

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

• 新创建的表会生成独立 .ibd 文件，路径在数据目录下对应数据库子目录中
• 已有表仍留在共享表空间 ibdata1 中，删表也不释放磁盘空间
• 要让老表“搬出来”，必须重建：ALTER TABLE your_table ENGINE=InnoDB;
• 该操作会锁表（除非用 pt-online-schema-change 或 MySQL 5.6+ 的在线 DDL），执行后检查对应目录是否有 your_table.ibd

重建后若仍没 .ibd，可能是表引擎不是 InnoDB（查 SHOW CREATE TABLE your_table; 确认 ENGINE=InnoDB）。

删表后磁盘空间没释放？先排查这几个点

即使开了 innodb_file_per_table，删表不回收空间也很常见，原因往往不在配置本身：

• Linux 文件系统层未释放：mysqld 进程仍持有已删 .ibd 的文件句柄，需重启 MySQL 或等其自动释放（lsof -p $(pgrep mysqld) | grep deleted 可验证）
• .ibd 文件残留：手动删了 .frm 却漏删 .ibd，或反向操作，导致元数据与物理文件状态不一致
• 真正占空间的是 undo 表空间（如 undo_001），尤其当 innodb_undo_log_truncate=ON 但收缩失败时
• ibdata1 无法收缩：哪怕所有表都迁出，只要它曾被写入过，就只能增长不能缩小；彻底清理只能导出 → 清库 → 重建 → 导入

真正麻烦的是混合状态：部分表在 .ibd，部分还在 ibdata1 —— 此时 ibdata1 永远卡在最大历史体积，删再多独立表也没用。