InnoDB表空间文件不会自动收缩是设计使然；DELETE或DROP无法缩小ibdata1，独立.ibd需ALTER TABLE ENGINE=InnoDB重建才能释放空间；唯一缩容ibdata1的方法是停机导出、初始化新实例并导入。
InnoDB 表空间文件（ibdata1 或 .ibd）不会自动收缩是设计使然，不是故障；靠 DELETE 或 DROP TABLE 无法让 ibdata1 变小，对独立 .ibd 文件也需显式重建才能释放磁盘空间。
确认当前表空间模式：innodb_file_per_table 是否生效
这是所有后续操作的前提。MySQL 8.0+ 默认开启，但若初始化时跳过配置文件或用了 --initialize-insecure，可能仍为 OFF。
- 执行
SELECT @@innodb_file_per_table;—— 返回1才表示启用成功 - 若为
0，需在my.cnf的[mysqld]段中添加innodb_file_per_table = ON并重启 MySQL - 注意：该参数只影响新创建的表；已有表仍留在
ibdata1中，不会自动迁移 - 验证某张表是否已使用独立表空间：运行
SHOW CREATE TABLE your_table\G，输出中含ENGINE=InnoDB且无警告即为独立模式
收缩单个 .ibd 文件：用 ALTER TABLE ... ENGINE=InnoDB
这是最常用、最可控的收缩方式，本质是重建表并重写数据页，消除空洞、压缩存储。
- 它等价于
OPTIMIZE TABLE your_table，但更明确，且可配合ALGORITHM=INPLACE（MySQL 5.6+）减少锁时间 - 执行前确保磁盘剩余空间 ≥ 当前表
Data_length + Index_length的 2 倍（临时表 + 原表共存） - 该操作会加元数据锁（MDL），期间 DDL 被阻塞；大表建议在低峰期执行
- 执行后立即检查：
SELECT data_free FROM information_schema.tables WHERE table_name='your_table';应归零或显著下降
处理顽固的 ibdata1 过大问题：必须重建实例
ibdata1 一旦膨胀，就无法在线 shrink——它承载数据字典、undo 日志、回滚段等系统级内容，MySQL 不支持共享表空间缩容。
- 唯一安全方法是停机导出 → 初始化新实例 → 导入：先用
mysqldump或mydumper备份全库，再用mysqld --initialize初始化空实例（确保配置含innodb_file_per_table = ON），最后导入 - 切勿直接删除或清空
ibdata1，MySQL 将拒绝启动 - 如果 undo 日志是主因（如长事务多），可在新实例中启用
innodb_undo_tablespaces = 2+innodb_undo_log_truncate = ON，让 undo 分离并定期截断 - 别碰
innodb_data_file_path和innodb_undo_directory：这两个参数属“初始化锁定型”，运行中修改会导致 MySQL 启动失败
避免未来再次虚高：监控碎片率 + 清理 binlog/relay log
光收缩不够，得防复发。很多“磁盘满”其实是日志堆积或碎片未被发现导致的。
- 定期查碎片：运行以下 SQL 获取真实碎片率（
frag_pct> 25% 且free_mb> 50 即值得处理）SELECT table_name, ROUND((data_length + index_length) / 1024 / 1024, 2) AS size_mb, ROUND(data_free / 1024 / 1024, 2) AS free_mb, ROUND(100 * data_free / (data_length + index_length + data_free), 2) AS frag_pct FROM information_schema.tables WHERE engine = 'InnoDB' AND table_schema = 'your_db' AND data_free > 0 ORDER BY frag_pct DESC;
- binlog 不清理会悄悄吃光磁盘：检查
expire_logs_days是否设置，未设则默认永久保留；生产环境建议设为7或更短，并用PURGE BINARY LOGS BEFORE '...'临时清理 - 从库 relay log 若卡住（SQL_THREAD 停滞），也会持续增长；确认
relay_log_purge = ON（默认开启），并监控Seconds_Behind_Master
真正麻烦的从来不是“怎么缩”，而是“缩完还涨”。ibdata1 不能动、undo 日志易堆积、data_free 不等于磁盘空闲——这些细节一旦忽略，下次巡检又会看到那个熟悉的 14G ibdata1。
