手册说“优化表”：
“删除的行保留在链接列表中，随后的INSERT操作将重新使用旧的行位置。可以使用OPTIMIZE TABLE来回收未使用的空间并对数据文件进行碎片整理。
所以我猜测即使存储介质是SSD，也会有一些性能提升，因为删除的行的链表将被删除。 OTOH（再次猜测）性能增益不会像硬盘那样显着，而硬盘在运行优化后也能从更快的顺序读取中受益。
那么在这种情况下值得运行优化吗？ 性能增益是否足以超过SSD寿命预期的下降（由于不必要的重新安排存储的数据）？ 我正在谈论的表是否是完美的候选优化（具有频繁更新的可变长度的行）。
您经常会看到SSD性能，即使读取性能受到驱动器每秒最大I / O操作数量的限制。 以英特尔X-25 E为例，最高读取速度高达250 MB / s，而且每秒最多可读取35,000次读取操作，因此4 KB数据块的最高传输速率为140 MB / s。
如果您的数据是非连续的， 并且您的典型读取会导致串行I / O负载（例如，您会在典型负载的非碎片数据库中看到大的请求大小），那么运行OPTIMIZE TABLE将会使性能受益。
到目前为止，最简单的方法是简单地检查出来 – 为最常用的表运行一个OPTIMIZE TABLE命令，对其进行典型的读/写操作，并使用iostat -x /dev/<device>检查平均请求大小（avgrq-sz） iostat -x /dev/<device> 。 如果avgrq-sz很高（> 32个扇区），那么您确实从OPTIMIZE中受益。 如果不是，那么将来可能就不需要打扰了，因为你的访问模式是相当随机的。
使用OPTIMIZE TABLE时还有其他要考虑的事情
你使用的是什么存储引擎， MyISAM或InnoDB ？
如果您正在使用MyISAM ，那么如果MyISAM表需要大量的INSERT，UPDATE和DELETE（IUD），则确实可以恢复大量的磁盘空间。 不要忘记OPTIMIZE TABLE在内部调用ANALYZE TABLE来更新索引行统计信息。 索引行统计数据可以在繁重的IUD环境中大量抛出，并可能阻碍MySQL查询优化器为查询的EXPLAIN计划做出正确的select。 如果MyISAM表遇到非常低的UPDATE和DELETE，OPTIMIZE TABLE是不确定的。 如果MyISAM表没有DELETE，但是有大量的INSERT和UPDATE， OPTIMZIE TABLE非常less（一年一次），但是在谨慎的时期（也许一个月一次）运行ANALYZE TABLE 。
如果我们正在谈论InnoDB ，我们来谈谈你的InnoDB设置。 如果您启用了innodb_file_per_table ，那么OPTIMIZE TABLE就是一切，很好，很好。 但是，ANALYZE TABLE对InnoDB没有影响，因为索引统计是通过深入到基数近似的BTREE索引中来计算的。 请期待InnoDB .ibd文件的增长速度与其MyISAM相同，因为数据和索引页都驻留在相同的.ibd文件中，而MyISAM数据和索引则位于分隔文件（.MYD和.MYI）中。 因此，InnoDB将需要更频繁的MyISAM的OPTIMIZE TABLE操作。
如果禁用innodb_file_per_table ，则必须重新构buildInnoDB基础结构，然后才能成功地针对InnoDB表运行OPTIMIZE TABLE命令。