ibdata1不会自动缩小，因innodb共享表空间不支持缩容；删库、清日志、optimize table均无效；根本解决需启用innodb_file_per_table并迁移大表至独立.ibd文件，或重建实例。
ibdata1 不会自动缩小，删库、清日志、OPTIMIZE TABLE 都没用——这是 InnoDB 共享表空间机制决定的，不是你操作错了。
确认 innodb_file_per_table 是否已开启
新装宝塔默认已开，但老实例或手动迁移过的可能仍是 OFF。不确认就动手，后面所有操作都白费。
- 登录 MySQL 执行：
SELECT @@innodb_file_per_table;，返回1才有效 - 检查配置文件
/www/server/mysql/my.cnf的[mysqld]段，必须有innodb_file_per_table = 1 - 若修改了配置，必须重启 MySQL：
service mysqld restart，仅 reload 不生效 - 注意：该参数只对「新建表」生效，已有大表仍躺在 ibdata1 里，需单独迁移
把大表从 ibdata1 迁出到独立 .ibd 文件
这是释放空间最直接有效的动作。本质是让表数据脱离共享表空间，后续删表或 TRUNCATE 才能真正归还磁盘。
- 先查哪些表最大：
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 20; - 对目标表执行：
ALTER TABLE `log_order_history` ENGINE=InnoDB;（替换表名） - 该操作会锁表，期间无法读写，建议在业务低峰期操作；百 GB 表可能耗时数小时
- 执行后检查对应数据库目录（如
/www/server/data/your_db/），应出现log_order_history.ibd文件，且ibdata1不再增长
别碰 OPTIMIZE TABLE，它在这里等于重建表
宝塔面板里点“优化表”，底层就是 ALTER TABLE ... ENGINE=InnoDB。对大表而言，这不是轻量维护，而是高风险重操作。
- 磁盘剩余空间必须 ≥ 原表大小 × 1.2，否则中途失败，可能留下损坏状态
- 不会减少 ibdata1 体积，只是把该表挪出去——和上面
ALTER TABLE效果完全一样 - 日常只需
ANALYZE TABLE your_table;，毫秒级，只更新统计信息，不影响业务 - 真要“瘦身”旧表，更稳妥的是：
mysqldump导出 →DROP TABLE→CREATE TABLE+source导入，全程可控
清理 binlog 和 undo 日志才是治本辅助
ibdata1 膨胀主因是 undo 日志堆积，而 binlog 和慢日志虽不进 ibdata1，但也在吃磁盘，容易掩盖真实问题。
- 设置 binlog 自动过期：
SET GLOBAL binlog_expire_logs_seconds = 604800;（7 天），并写入 my.cnf 的[mysqld]段：binlog_expire_logs_seconds = 604800 - 关闭不必要的日志：
SET GLOBAL slow_query_log = 'OFF';，或注释掉 my.cnf 中的slow_query_log_file和long_query_time - 慎用
PURGE BINARY LOGS：确保没有从库在同步，否则主从断裂 - undo 日志无法在线清理，若 ibdata1 已严重膨胀且无法停机，唯一安全路径是重建实例：备份 → 停库 → 初始化新数据目录 → 导入
真正关键的不是“怎么缩 ibdata1”，而是“不让它再涨”。独立表空间 + 定期迁移大表 + 控制长事务 + 合理日志轮转，四者缺一不可。其中最容易被跳过的，是查表物理大小——光看 phpMyAdmin 里的行数，根本发现不了那个存了 50 万条 JSON 日志却只有 200 行的 cache_api_response 表。
