特殊的 MariaDB 优化结果

问：

我开始从事 10 年前正在进行的项目。屁股上有一个痛苦（由以前的开发人员引起） - 巨大的表，我们称之为 abc - 128GB 的数据、16,5 mil 行、120 列。当然，它非常慢，会引起很多问题。因此，我们决定是时候做点什么了。我们在 AWS RDS Mariadb 上运行，我们有多个数据库实例为各种微服务运行，因此我可以访问 PROD 的快照/备份并为此目的恢复它们 - 测试和优化这个大表（DEV/TEST 上的数据库甚至没有接近那么完整和大）。对于后端，有PHP框架和Doctrine作为ORM。

因此，我开始将未使用的和不必要的列一起删除 30 列（也重构了后端和实体，但与此问题无关）。太好了，第一步！

然后我运行队列（通过 RabbitMQ），它清理了一些包含不必要的大型 JSON 的列（由于导出某些实体的愚蠢方式，现已修复）。这些列仅用于存储此数据，不用于搜索或选择。

然后我做了一些研究（也是关于分区的，因为有 7 个非常指定的在不久的将来永远不会更改的值的列“type”，还有后续步骤，现在不重要）

我最终运行了命令optimize（是的，我知道在mariadb中它将重建和分析表格）

OPTIMIZE TABLE abc

这奏效了！它运行了大约 2.5 小时，导致大小从 128GB 减少到 46GB！我对结果非常满意。我还检查了表格的大小，这是正确的。桌子也开始明显更快（但没有人们希望的那么快）。information_schema.tablesdata_length

随着时间的流逝，我做了一些其他事情，大约 2 周后，我重新创建了 PROD 的另一个快照，并开始通过后端 Doctrine 迁移等测试所有具有正常流程的优化迁移。我以相同的顺序做所有事情。首先删除列，然后排队等待 JSON，然后 OPTIMIZE TABLE。这次花了 5 小时，将数据从 128GB 减少到 124GB。我一无所知，如何以及为什么。

快照相距 4w，我首先运行命令的“旧”版本是 16 330 693 列，而“当前”版本是 16 649 545。所以没有太大的区别。快照使用相同的设置、相同的实例（m5 large）、相同的所有内容重新创建，但突然优化不起作用。在几乎相同的数据集上。我什至试图在这个 abc 表上放置一个非常大且非常愚蠢的复合索引并再次运行 OPTIMIZE 命令，但无济于事。

你有什么提示我可以做些什么不同的事情吗？因为我甚至第三次尝试过，新鲜快照，新鲜构建，新鲜所有内容，相同的设置，相同的代码，但我仍然无法复制 128 到 46 gigs 优化（是的，我仍然运行该快照/实例，它很好并且包含所有数据）