ibdata1 文件体积不会缩小，这是 InnoDB 共享表空间的硬性设计；即使删除所有表、优化表或清空 binlog，其大小仍保持不变。
ibdata1 不会缩小，哪怕你删光所有表、OPTIMIZE 所有表、清空 binlog，它体积也纹丝不动——这不是配置没开对，是 InnoDB 共享表空间的硬性设计。
确认 innodb_file_per_table 是否真生效
很多人改了配置却白忙一场，关键卡在「以为开了，其实没生效」。必须双重验证：
- 登录 MySQL 执行
SELECT @@innodb_file_per_table;，返回1才算真正启用 - 检查配置文件（如
/etc/my.cnf或/www/server/mysql/my.cnf）的[mysqld]段，必须有且仅有一行：innodb_file_per_table = 1 - 改完必须执行完整重启：
service mysqld restart（reload不生效） - MySQL 5.7 默认仍是
OFF，不能假设“新装就开了”
为什么开了 innodb_file_per_table，ibdata1 还每天涨？
该参数只影响「新建表」，而 ibdata1 仍在持续接收以下不可剥离的内容：
- 数据字典（
mysql库中所有系统表，如innodb_table_stats） - undo 日志（MVCC 和事务回滚依赖；长事务未提交时，
History list length会飙升） - change buffer、doublewrite buffer、回滚段（MySQL 5.7 默认全塞进 ibdata1）
- 所有从未重建过的老表数据和索引（
DROP TABLE或TRUNCATE后空间也不释放）
典型线索：SHOW ENGINE INNODB STATUS\G 中看到 ACTIVE xxx sec 的陈旧事务，或 History list length > 10000。
把老表从 ibdata1 迁出到独立 .ibd 文件
这是唯一能停止某张表继续往 ibdata1 写入的方式，本质是触发全量重建：
- 先查大表：
SELECT table_schema, table_name, ROUND(((data_length + index_length) / 1024 / 1024), 2) AS size_mb FROM information_schema.TABLES WHERE engine='InnoDB' AND table_schema NOT IN ('mysql', 'information_schema', 'performance_schema', 'sys') ORDER BY size_mb DESC LIMIT 10; - 对目标表执行：
ALTER TABLE `orders` ENGINE=InnoDB;（替换为实际表名） - 该操作会加元数据锁（MDL），期间读写阻塞；百 GB 表可能耗数小时
- 执行后检查数据库目录（如
/var/lib/mysql/your_db/）是否生成orders.ibd - 验证迁移成功：
SELECT FILE_NAME, TABLESPACE_NAME FROM INFORMATION_SCHEMA.FILES WHERE TABLE_NAME='orders' AND FILE_TYPE='TABLESPACE';返回orders.ibd即可
注意：磁盘需预留 ≈ 原表大小 × 2；OPTIMIZE TABLE 在这里等价于 ALTER TABLE ... ENGINE=InnoDB，别被宝塔面板的“优化表”按钮误导。
真正让 ibdata1 变小的唯一办法：重建实例
所有在线操作只能「止血」，无法「缩容」。要回到初始大小（比如 12MB），必须停机导出+重置：
- 用
mysqldump导出全库（含mysql系统库） - 停 MySQL：
service mysqld stop - 手动删除
ibdata1、ib_logfile0、ib_logfile1及所有.ibd文件（保留mysql目录结构） - 确保配置文件已设
innodb_file_per_table = 1 - 启动 MySQL，它会自动重建最小化
ibdata1 - 导入 dump 文件
这个过程绕不开停机窗口和备份完整性校验——很多团队卡在这一步，不是不会做，而是不敢动。
