默认开启独立表空间，但仅影响新表；已有表仍存于共享表空间，需通过ALTER TABLE ... ENGINE=InnoDB手动迁移，且ibdata1无法自动收缩。
默认开启独立表空间，但已存在的表不会自动迁移；切换配置只影响新创建的表，老表需手动重建才能生效。
如何确认当前是独立还是共享表空间
直接查变量值最可靠：
mysql> show variables like 'innodb_file_per_table';
返回 ON 表示新表将使用独立表空间（.ibd 文件）；返回 OFF 表示新表将写入共享表空间（ibdata1 等文件）。
- 这个变量只控制「新建表」的行为，对已有表完全无影响
- 即使设为
ON，老表仍可能长期留在ibdata1中，尤其是 MySQL 5.6 及更早版本 - 别依赖
ls *.ibd判断全局状态——可能只是部分表被重建过
修改配置后为什么新建表还是没 .ibd 文件
常见原因是未重启 mysqld 服务，或配置未落到正确 my.cnf 段落中。
- 必须在
[mysqld]段下添加：innodb_file_per_table=1（或=ON） - 改完配置后必须执行：
service mysqld restart（或systemctl restart mysqld） - 重启后再次验证：
show variables like 'innodb_file_per_table';，确保值已更新 - 注意：某些 Docker 镜像或云数据库（如阿里云 RDS）禁止修改该参数，会静默忽略
让老表迁移到独立表空间的唯一可靠方式
只能逐表执行 ALTER TABLE ... ENGINE=InnoDB，这是 InnoDB 内部重建表结构+数据的过程。
- 执行前确保磁盘有足够空间（临时需要双倍空间）
- 该操作会锁表（MySQL 5.6+ 支持
ALGORITHM=INPLACE的 DDL，但仅限部分场景，不能保证全程无锁） - 执行后检查对应数据库目录：
ls /var/lib/mysql/your_db/old_table.ibd是否出现 - 不推荐用
mysqldump + DROP + RESTORE方式迁移——流程长、易出错、停机时间不可控
共享表空间 ibdata1 能不能缩小
不能。一旦写入，ibdata1 文件大小只增不减，且无法在线收缩。
- 即使把所有表都迁出到
.ibd，ibdata1仍包含 undo log、系统表、doublewrite buffer 等关键元数据 - 想真正清理它，必须全库导出（
mysqldump --all-databases）、停库、删除ibdata*和ib_logfile*、重配my.cnf、再启动并导入——这是高风险操作，生产环境慎用 - 日常运维中，应把
innodb_file_per_table保持为ON，并定期监控ibdata1增长趋势
真正麻烦的不是开关配置，而是历史表是否已迁移、ibdata1 是否已膨胀到难以维护的程度——这两点往往在磁盘告警时才被发现。
