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

Question

该手册说，关于“优化表”：

“删除的行保存在链表中，随后的 INSERT 操作会重用旧的行位置。您可以使用 OPTIMIZE TABLE 回收未使用的空间并对数据文件进行碎片整理。”

所以我猜即使存储介质是SSD也会有一些性能提升（因为删除行的链表将被消除）。OTOH（再次猜测）性能提升不会像 HDD 那样显着，这也将受益于运行优化后更快的顺序读取。

那么在这种情况下是否值得运行优化？性能提升是否足以超过 SSD 预期寿命的减少（由于不必要的重新排列存储的数据）？。我说的是在其他方面非常适合优化的表（具有频繁更新的可变长度行）。

Answer 1

您经常会看到 SSD 性能，甚至读取性能，受到驱动器每秒最大 I/O 操作数量的限制。以Intel 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 很高（> 32 个扇区），则您确实受益于 OPTIMIZE。如果没有，将来可能不需要打扰，因为无论如何您的访问模式都是相当随机的。

Answer 2

使用OPTIMIZE TABLE时还需要考虑其他事项

你在使用什么存储引擎，MyISAM还是InnoDB？？？

如果您使用的是MyISAM，并且 MyISAM 表经历了大量的 INSERT、UPDATE 和 DELETE (IUD)，您确实可以恢复大量磁盘空间。不要忘记OPTIMIZE TABLE 在内部调用ANALYZE TABLE来更新索引行统计信息。在繁重的 IUD 环境中，索引行统计信息可能会被大量丢弃，并且会阻碍 MySQL 查询优化器为查询的 EXPLAIN 计划做出正确的选择。如果 MyISAM 表遇到非常低的 UPDATE 和 DELETE，则不需要 OPTIMIZE TABLE。如果 MyISAM 表没有经历 DELETE，而是有很多 INSERT 和 UPDATE，则OPTIMZIE TABLE 会非常谨慎（一年一次），但会在谨慎的时期（可能每月一次）运行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，则必须重新构建 InnoDB 基础架构，然后才能针对 InnoDB 表成功运行OPTIMIZE TABLE命令。