我对如何在 MySQL 中维护索引以防止碎片化并以某种方式优化某些查询的执行进行了大量研究。
我熟悉计算表可用的最大空间与数据和索引使用的空间之间的比率的公式。
但是，我的主要问题仍未得到解答。也许这是因为我熟悉SQL Server中的索引维护，并且我倾向于认为在MySQL中它应该在某种程度上相似。
在 SQL Server 中，您可以有多个索引，并且每个索引都可以具有不同级别的碎片。然后，您可以选择一个并在该特定索引中执行“重组”或“重建”操作，而不会影响其余部分。
据我所知，没有这样的“表碎片”，并且 SQL Server 不提供任何工具来修复“表碎片”。它提供的是检查索引碎片的工具（理解为索引使用的页面数量与该页面的完整度和连续性之间的比率），以及内部和外部碎片。
所有这些都很容易理解，至少对我来说是这样。
现在，轮到在 MySQL 中维护索引时，只存在“表碎片”的概念，如上所述。
MySQL 中的一个表可以有多个索引，但是当我用那个著名的公式检查“碎片率”时，我没有看到每个索引的碎片，而是整个表。
当我想优化 MySQL 中的索引时，我不会选择要操作的特定索引（如在 SQL Server 中）。相反，我在整个表中执行“优化”操作，这可能会影响所有索引。
当在 MySQL 中优化表时，数据 + 索引使用的空间与整体空间之间的比率减少，这表明硬盘驱动器中进行了某种物理重组，这转化为物理空间的减少。但是，索引碎片不仅与物理空间有关，还与由于插入和更新而随时间发生变化的树结构有关。
最后，我在 InnoDB/MySQL 中得到了一张表。该表有 300 万条记录、105 列和 55 个索引。它是 1.5GB，不包括索引，即 2.1GB。
该表每天都会被访问数千次以进行更新、插入（我们实际上并没有删除记录）。
该表已创建多年，我确信没有人在维护任何索引。
我期待在那里找到一个巨大的碎片，但是当我按照规定执行碎片计算时
free_space / (data_length + index_length)
事实证明，我只有 0.2% 的碎片。恕我直言，这是非常不现实的。
所以最大的问题是：