必须在配置文件中写死并重启才能永久开启innodb_file_per_table，仅动态设置或依赖默认值不可靠；运行时需用SHOW VARIABLES或SELECT @@确认为ON/1，且老表须手动ALTER TABLE重建才生效。
必须在配置文件里写死并重启，否则删表不释放磁盘空间
怎么确认当前是否真开启了 innodb_file_per_table
别信“MySQL 5.6 默认开启”这种说法——实际是否生效，只看运行时值。执行以下任一命令：
-
SHOW VARIABLES LIKE 'innodb_file_per_table'—— 返回ON才算开启 -
SELECT @@innodb_file_per_table—— 返回1才算开启
注意：即使返回 ON，如果没写进配置文件，重启后可能变回 OFF（尤其 MySQL 5.6.42 及更早版本）。Linux 下可直接检查物理文件：ls -lh /var/lib/mysql/your_db/，若只有 .frm 没有 .ibd，说明表还在共享空间。
如何在 my.cnf 中正确配置并永久生效
编辑 MySQL 配置文件（如 /etc/my.cnf 或 /etc/mysql/mysql.conf.d/mysqld.cnf），确保在 [mysqld] 段下添加：
innodb_file_per_table = ON
不要写成 1（虽然旧版兼容，但 5.6+ 官方推荐用 ON）；不要放在 [client] 或其他段；改完必须重启 MySQL 实例。动态设置 SET GLOBAL innodb_file_per_table = ON 仅影响后续新建表，且部分 5.6 分支不支持该动态赋值，不可靠。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
开启后老表不会自动迁移，必须手动重建
这是最容易被忽略的致命点：启用参数只对新表生效。已有表仍锁死在 ibdata1 里，DROP TABLE 后磁盘空间一分不回。想让某张老表独立出来，必须显式重建：
-
ALTER TABLE table_name ENGINE=InnoDB（推荐，语义明确） - 或等价的
OPTIMIZE TABLE table_name
重建期间会持有元数据锁（MDL），写操作会被阻塞；大表需双倍磁盘空间；务必确认 innodb_file_per_table 已为 ON，否则重建完还是落回 ibdata1。成功后，ls -lh /var/lib/mysql/your_db/ 应能看到 table_name.ibd。
收益不止是“删表能回收空间”
独立表空间带来的实际好处远超直觉：
-
TRUNCATE TABLE在独立表空间上更快，且立即归还空间给操作系统 - 单表可单独备份、迁移或传输（
FLUSH TABLES ... FOR EXPORT+ 拷贝.ibd） - 可对单表运行
OPTIMIZE TABLE回收碎片空间，不影响其他表 - 损坏隔离：一张表的
.ibd损坏，不影响其他表甚至系统表空间 - 支持
ROW_FORMAT=DYNAMIC和压缩表等高级特性（共享空间不支持）
唯一代价是略微增加文件描述符消耗和小文件管理开销，但对现代 Linux 和 MySQL 5.6 来说完全可接受。真正难的是：一旦 ibdata1 膨胀到几十 GB，就只能走全库逻辑重建（mysqldump → 删文件 → 恢复）来缩小它——这个过程无法在线完成，也无参数可绕过。
