ibdata1无法缩小是InnoDB固有设计，唯一缩容方式是导出、清空数据目录、初始化新实例并导入；开启innodb_file_per_table仅使新表使用独立.ibd文件，老表需逐个执行ALTER TABLE ENGINE=InnoDB迁移，且必须双重验证配置生效。
ibdata1不会缩小，这是 InnoDB 的设计事实，不是配置错了或操作不到位——它根本不可逆缩容。
确认 innodb_file_per_table 是否真生效
很多人改了配置却没起作用，结果还在徒劳优化大表。必须双重验证：
登录 MySQL 执行 SELECT @@innodb_file_per_table;，返回 1 才算开启成功
检查配置文件（如 /www/server/mysql/my.cnf 或 /etc/my.cnf）的 [mysqld] 段，确认有且仅有一行：innodb_file_per_table = 1
修改后必须执行 service mysqld restart（reload 不生效）
注意：innodb_file_per_table=1 只影响后续新建的表，对已存在的表完全无效
ibdata1 里到底在写什么？为什么停不下来
即使开了 innodb_file_per_table=1，ibdata1 仍会持续增长，因为它必须承载以下不可剥离的内容：
数据字典（mysql 库中所有系统表定义）
undo 日志（MVCC 和事务回滚依赖，尤其长事务未提交时堆积极快）
change buffer、doublewrite buffer、rollback segments（MySQL 8.0 默认仍集成在 ibdata1 中）
所有未重建过的老表的数据和索引（哪怕你 TRUNCATE TABLE 过，空间也不释放）
典型诱因：SHOW ENGINE INNODB STATUS\G 中 History list length 持续 > 10000，或看到 ACTIVE xxx sec 的陈旧事务
把老表从 ibdata1 迁出到独立 .ibd 文件
这是释放磁盘空间最直接有效的动作，本质是让表数据脱离共享表空间：
先查哪些表最大：SELECT table_schema, table_name, ROUND(((data_length + index_length) / 1024 / 1024), 2) AS size_mb FROM information_schema.TABLES WHERE table_schema NOT IN ('mysql', 'information_schema', 'performance_schema', 'sys') ORDER BY size_mb DESC LIMIT 10;
对目标表执行：ALTER TABLE `log_order_history` ENGINE=InnoDB;（替换为实际表名）
该操作会锁表，期间无法读写；百 GB 表可能耗时数小时；MySQL 5.6+ 支持 Online DDL，但元数据锁（MDL）仍可能阻塞业务
执行后检查对应数据库目录（如 /www/server/data/your_db/），应出现 log_order_history.ibd；再用 SELECT FILE_NAME, TABLESPACE_NAME FROM INFORMATION_SCHEMA.FILES WHERE TABLE_NAME='log_order_history' AND FILE_TYPE='TABLESPACE'; 验证是否成功迁移
磁盘需预留 ≈ 原表大小 × 1.2 空间，否则中途失败可能留下损坏状态
真正让 ibdata1 变小的唯一办法：重建实例
导出 → 清空数据目录 → 初始化新实例 → 导入，这是唯一能让 ibdata1 回到初始大小（如 12MB）的操作路径：
直接删 ibdata1 会导致 MySQL 启动失败，报错类似 InnoDB: The system tablespace must be non-empty
OPTIMIZE TABLE、DROP TABLE、甚至 mysqldump 后删文件再恢复，都不影响已有 ibdata1 的物理尺寸
即使只启用 innodb_undo_log_truncate=ON 和 innodb_undo_tablespaces=2，也仅能抑制未来增长，无法回收已占空间
关键点不是“删文件”，而是“重置共享表空间结构”——这一步容易被忽略，但恰恰是成败所在
