必须改配置文件并重启才永久生效，set global无效；启用后仅新表生成独立.ibd文件，老表仍留在ibdata1中；确认是否启用应执行select @@innodb_file_per_table，返回1或on表示已启用。
必须改配置文件并重启，仅 SET GLOBAL 无效，且老表不会自动迁移。
怎么确认当前是否启用 innodb_file_per_table
别看文档或猜版本，默认值不等于实际值。直接连进 MySQL 执行：
SELECT @@innodb_file_per_table;
返回 1 或 ON 表示已启用；返回 0 或 OFF 表示仍用共享表空间 ibdata1。注意：SHOW VARIABLES LIKE 'innodb_file_per_table' 结果一样，但更推荐用 SELECT @@... —— 它查的是当前会话生效值，不受临时连接干扰。
在哪改、怎么改才真正永久生效
必须编辑 MySQL 主配置文件（如 /etc/my.cnf、/etc/mysql/mysql.conf.d/mysqld.cnf 或 /usr/etc/my.cnf），且只能写在 [mysqld] 段下：
[mysqld] innodb_file_per_table = ON
常见错误包括：
- 写成
innodb-file-per-table = 1（用了短横线，MySQL 解析失败） - 写在
[client]或[mysql]段里（完全不生效） - 只执行
SET GLOBAL innodb_file_per_table = ON（重启后回退，且对已有表无影响）
改完必须重启 MySQL 进程：sudo systemctl restart mysql 或 sudo service mysqld restart。
启用后新建表有 .ibd，但老表还在 ibdata1 里
这是最常被忽略的点：启用 innodb_file_per_table 只影响后续 CREATE TABLE 的表。已有 InnoDB 表仍留在共享表空间 ibdata1 中，删表也不会释放 ibdata1 空间。
想把老表迁出，唯一安全方式是重建：
ALTER TABLE `your_table` ENGINE=InnoDB;
该操作会生成新 .ibd 文件，并从 ibdata1 中清理旧数据（需确保磁盘有足够临时空间）。批量处理时建议逐个执行，避免锁表时间过长。
为什么 ibdata1 还在涨，即使开了独立表空间
即使启用了 innodb_file_per_table，ibdata1 仍承担三类不可剥离的数据：
- InnoDB 数据字典（table metadata）
- undo logs（事务回滚段）
- 系统表（如
mysql.innodb_table_stats）
所以 ibdata1 不会变小，但增长会显著放缓。若它已膨胀到几十 GB 且无法接受，唯一彻底清理方式是：全库 mysqldump → 清空数据目录 → 修改配置 → 重启 → 导入。该操作需停服，务必提前备份。
