OPTIMIZE TABLE 对某些表无效，因其仅对启用innodb_file_per_table=ON的InnoDB独立表空间生效；若表在共享表空间（ibdata1）中或该参数为OFF，则无法释放磁盘空间，且DELETE仅标记删除不回收空间。
为什么 OPTIMIZE TABLE 对某些表没用？
因为 MySQL 的 OPTIMIZE TABLE 实际上是重建表 + 释放碎片空间，但它只对 InnoDB 表生效（且需启用 innodb_file_per_table=ON），对系统表空间（ibdata1）完全无效。如果你的表数据文件（.ibd）没变小，大概率是表还在共享表空间里，或者表被频繁更新后又回滚了，导致空间未真正回收。
实操建议：
- 先确认表是否独立表空间：
SELECT TABLE_NAME, TABLE_SCHEMA, ENGINE, CREATE_OPTIONS FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME = 'your_table';—— 看输出里有没有row_format=Dynamic或create_options含ROW_FORMAT，更关键的是检查innodb_file_per_table是否为ON - 若
innodb_file_per_table=OFF，OPTIMIZE TABLE不会生成新.ibd，只会整理ibdata1内部页，但该文件永不缩容 - 执行前确保有足够磁盘空间——它会临时复制整张表
删掉大量数据后空间不释放？别只 DELETE
DELETE 只是标记行删除，不归还磁盘空间；尤其是大范围删除（比如 DELETE FROM logs WHERE created_at ），InnoDB 会保留空闲页供后续插入复用，但不会主动通知文件系统“这块可以还了”。这时候你看到 <code>data_length 没变，不是 bug，是设计如此。
实操建议：
- 删完立刻跑
OPTIMIZE TABLE（仅限独立表空间） - 更稳妥的做法是
ALTER TABLE your_table ENGINE=InnoDB;—— 效果同OPTIMIZE，但更明确、兼容性略好 - 如果表太大怕锁太久，考虑分批删除 +
pt-osc（Percona Toolkit）在线重建，避免长事务阻塞
索引比数据还大？检查 TEXT/VARCHAR 字段是否被过度索引
InnoDB 的二级索引会把索引列值 + 主键值一起存，如果在很长的 VARCHAR(2000) 或 TEXT 字段上建普通索引，每条索引记录可能占用几 KB，索引体积轻松超过数据本身。常见于日志表、内容表误加全文字段索引。
实操建议：
- 查索引大小：
SELECT INDEX_NAME, SUM(stat_value) * @@innodb_page_size AS size_bytes FROM mysql.innodb_index_stats WHERE table_name = 'your_table' GROUP BY INDEX_NAME; - 用前缀索引替代全字段索引：
CREATE INDEX idx_content_prefix ON articles(content(100));—— 100 字节通常够支撑区分度 - 确认是否真需要这个索引：用
performance_schema.table_io_waits_summary_by_index_usage查该索引是否被查询用到过 - 全文搜索别用
B-TREE索引，改用FULLTEXT索引或外部方案（如 Elasticsearch）
如何安全收缩 ibdata1？基本不能，但可规避
ibdata1 是共享表空间，默认存放系统元数据、undo log、双写缓冲区等。一旦写入，MySQL 不允许缩小它——哪怕删光所有表，ibdata1 体积也不会下降。网上流传的“导出→删库→重装→导入”方案风险极高，容易丢 undo/redo 一致性，且停机时间不可控。
实操建议：
- 唯一可行路径：停机 + 全量逻辑导出（
mysqldump --all-databases --single-transaction）+ 删除整个datadir+ 重装 MySQL + 导入 - 但前提是：你没开启
innodb_undo_log_truncate且无长期运行事务，否则 dump 可能失败 - 日常预防更重要：初始化 MySQL 时就设
innodb_file_per_table=ON，并定期监控information_schema.INNODB_SYS_TABLESPACES中各表空间大小
最常被忽略的一点：innodb_undo_tablespaces 和 innodb_undo_log_truncate 配合使用，才能让 undo 日志空间可回收——但这只影响 undo 占用，不影响 ibdata1 主体。真要动 ibdata1，本质上是在重做整个实例，不是“清理”而是“重建”。
