对于innodb独立表空间来说，delete 是不能回收其在磁盘所占用的空间，采用truncate （原理是先删除，或重建）倒是可以；
这里不讨论直接drop表的情况，直接alter table ....engine=innodb 是可以整理碎片，回收部分表空间，在数据量小或者buffer pool 比较小的时候（小于30g）倒是很不错；
当碎片较多或者buffer pool较大的时候，我们需要面临风险----对innodb存储引擎在执行ddl语句的时候，会短暂hang住整个系统，而且这个hang的时间的长短与buffer pool的大小相关。主要原因在于innodb在drop table时，会连续两次遍历buf pool lru 链表，遍历的过程加锁，因此导致系统hang住。第一遍遍历lru链表，会定期释放buf pool mutex，因此对于系统hang的影响较小；而第二遍会一直持有，对系统hang的影响较大。-
--相关文章可以参考：
mysql删除大表性能
innodb buffer解读
在这里我介绍一种安全高效的碎片整理方法；pt-online-schema-change
percona这款工具本身是用来进行非阻塞的online ddl的，但由于只有alter table ...语句才能回收表空间，那可以采用该工具的原理：创建一张临时表，以触发器来保证与原表的数据一致，最后renmame替换掉；用过这款工具的朋友可能会有疑问，“online ddl”最后的操作时 drop old table；drop trigger；这样的操作；但可以采用--no-drop-old-table,让其不会删除旧表，等有其他时间的时候，采用脚本形式批量删除记录，，最后在drop掉剩余的“小表”；这样就避免了hang 住系统；
本人亲测，版本2.2.1，60g表，2个小时左右回收至21g；
推荐阅读：
innodb存储引擎的启动、关闭与恢复
mysql innodb独立表空间的配置
mysql server 层和 innodb 引擎层 体系结构图
innodb 死锁案例解析
mysql innodb独立表空间的配置