这手动的关于“优化表”的说法：
“已删除的行保存在链接列表中，后续的 INSERT 操作将重用旧行的位置。您可以使用 OPTIMIZE TABLE 来回收未使用的空间并对数据文件进行碎片整理。”
因此，我猜测即使存储介质是 SSD，性能也会有所提升（因为删除行的链接列表将被消除）。另一方面（只是再次猜测），性能提升不会像 HDD 那样显著，HDD 在运行优化后也会受益于更快的顺序读取。
那么在这种情况下是否值得运行优化？性能提升是否足以抵消 SSD 预期寿命的减少（由于不必要的重新排列存储的数据）？我说的是那些原本非常适合优化的表（具有可变长度的行且更新频繁）。
答案1
您经常会看到 SSD 性能（甚至读取性能）受到驱动器每秒最大 I/O 操作量的限制。英特尔 X-25 E例如 - 最高读取速度高达 250 MB/s，但每秒最多读取 35,000 次，这导致 4 KB 块的最高传输速率为 140 MB/s。
如果已知你的数据是不连续的和您的典型读取将产生串行 I/O 负载（即，对于您的典型负载，您会在非碎片数据库中看到较大的请求大小），运行将提高性能OPTIMIZE TABLE。
到目前为止，了解这一点的最简单方法就是简单地检查一下 - 对最常用的表运行 OPTIMIZE TABLE 命令，获取其上的典型负载读/写，并使用检查平均请求大小 (avgrq-sz) iostat -x /dev/<device>。如果 avgrq-sz 很高（> 32 个扇区），则您确实从 OPTIMIZE 中受益。如果不是，那么将来可能不需要再费心了，因为您的访问模式本来就相当随机。
答案2
使用时还需要考虑其他事项优化表
您正在使用什么存储引擎，数据库管理系统或者数据库引擎InnoDB???
如果你正在使用数据库管理系统，如果 MyISAM 表经历了大量的 INSERT、UPDATE 和 DELETE (IUD)，您确实可以恢复大量的磁盘空间。不要忘记优化表内部调用分析表更新索引行统计信息。在 IUD 较多的环境中，索引行统计信息可能会被严重干扰，并可能妨碍 MySQL 查询优化器为查询的 EXPLAIN 计划做出正确的选择。如果 MyISAM 表的 UPDATE 和 DELETE 很少，则 OPTIMIZE TABLE 是不必要的。如果 MyISAM 表没有 DELETE 但有大量 INSERT 和 UPDATE，优化表非常谨慎（一年一次），但要运行分析表在不公开的时间段（可能每月一次）。
如果我们正在谈论数据库引擎InnoDB，让我们来谈谈你的 InnoDB 设置。如果你有表 1. innodb_file_per_table启用后，OPTIMIZE TABLE 就万事大吉了。但是，ANALYZE TABLE 对 InnoDB 没有影响，因为索引统计信息是通过深入研究 BTREE 索引进行基数近似而实时计算的。InnoDB .ibd 文件的增长速度会比 MyISAM 文件快，因为数据和索引页都位于同一个 .ibd 文件中，而 MyISAM 数据和索引位于不同的文件（.MYD 和 .MYI）中。因此，InnoDB 需要比 MyISAM 更频繁的 OPTIMIZE TABLE 操作。
如果你有表 1. innodb_file_per_table残疾人士，你必须重新设计 InnoDB 基础设施才能成功运行优化表针对 InnoDB 表的命令。