当mysql数据库存储在SSD上时，运行“优化表”是否有意义？

Question

手册提到“优化表”：

“删除的行保存在链接列表中，随后的插入操作重用旧行位置。您可以使用优化表来收回未使用的空间，并对数据文件进行碎片整理。”

因此，我猜想会有一些性能提高，即使存储介质是SSD (因为已删除的行的链接列表将被删除)。OTOH (再次猜测)性能增益将不像HDD那样显著，而HDD在运行优化后也将受益于更快的顺序读取。

那么，在这种情况下运行优化是否值得呢？性能增益是否足以超过SSD预期寿命的下降(由于不必要地重新安排存储的数据)？我指的是一些优化的最佳候选表(具有可变长度的行和频繁的更新)。

Answer 1

您经常会看到SSD性能，甚至读取性能，以限制您的驱动器每秒最大I/O操作的数量(S)。以英特尔X-25 E为例，最高读取速度可达250 MB/s，但每秒读取操作最多可达3.5万次，最高传输速率为140MB/S，为4KB块。

如果您的数据是不连续的，并且您的典型读取将导致串行I/O负载(也就是说，您将在一个非分段的数据库中看到针对典型加载的大型请求大小)，那么运行OPTIMIZE TABLE将有利于性能。

到目前为止，了解它的最简单方法是简单地签出它--为您最常用的表运行一个优化表命令，对它进行典型的加载读/写，并使用iostat -x /dev/<device>检查平均请求大小(avgrq-sz)。如果avgrq-sz是高的(>32个扇区)，那么您确实从优化中受益。如果没有，可能没有必要在未来麻烦，因为您的访问模式是相当随机的。

Answer 2

在使用优化表时，还需要考虑其他一些问题

您使用的是哪个存储引擎，MyISAM还是InnoDB？

如果您使用的是MyISAM，那么如果一个MyISAM表删除了大量的插入、更新和删除(IUD)，那么确实可以恢复大量的磁盘空间。不要忘记优化表内部调用分析表来更新索引行统计信息。在复杂的IUD环境中，索引行统计信息可以被大量抛出，并且会阻碍MySQL查询优化器对查询的解释方案做出很好的选择。如果MyISAM表经历了很低的更新和删除，优化表是没有必要的。如果MyISAM表没有删除，而是进行了大量的插入和更新，则OPTIMZIE表非常节省(每年一次)，但在离散的时间段(可能每月一次)运行分析表。

如果我们在讨论InnoDB，那么让我们来谈谈您的InnoDB设置。如果启用了诺姆b，那么优化表就是全部，好的，好的。但是，分析表对InnoDB没有任何影响，因为指数统计是通过对BTREE指数进行快速计算来实现基数近似的。请期待InnoDB .ibd文件比其MyISAM对应方增长得更快，因为数据页和索引页都驻留在同一个.ibd文件中，而MyISAM数据和索引驻留在单独的文件中(.MYD和.MYI)。因此，InnoDB需要更频繁地优化MyISAM的表操作。

如果禁用了诺姆b，则在您成功地对InnoDB表运行优化表命令之前，请使用您必须重新设计InnoDB基础结构。