我有一个包含100000000条记录和500GB数据的表。我一直在将许多旧记录备份到备份数据库中，并从主数据库中删除它们。然而，磁盘空间并没有减少，我注意到该表的data_free增长了很多。
我的理解是，我需要运行OPTIMIZE TABLE来减少磁盘大小，但我已经读到这会导致复制滞后。我使用的是mysql 5.7 InnoDB。
所以我的问题是，我能在不造成复制滞后的情况下运行OPTIMIZE TABLE吗？例如在主机上运行OPTIMIZE TABLE，例如：
OPTIMIZE NO_WRITE_TO_BINLOG TABLE tblname;
然后逐个在从属设备上运行相同的命令。这样行吗？这样做有风险吗？或者还有其他办法吗？
在我的公司，我们使用Percona的免费工具pt在线模式更改。
它并没有真正执行OPTIMIZE TABLE，但对于InnoDB表，任何表复制操作都将获得相同的结果。也就是说，它创建了一个新的InnoDB表空间，将所有行复制到该表空间，并重建该表的所有索引。新的表空间将是原始表空间的碎片整理版本。
任何更改都会起作用，您不必更改表中的任何内容。我使用无操作ALTER TABLE <name> FORCE。
pt在线模式更改的优点是，在它工作的同时，您可以继续读写表。它只需要一个简短的元数据锁来在启动时创建触发器，并在结束时使用另一个简短元数据锁来将新表替换为旧表。
如果使用OPTIMIZE TABLE，这会导致复制延迟很长，因为它要在源上完成后才能开始在复制副本上运行。
而随着pt在线模式的更改，它会立即开始运行表副本，并与其他并发事务一起继续，当它在源上完成时，只需片刻，就可以在副本上完成。
它实际上比OPTIMIZE TABLE花费的时间更长，但由于它不会阻止您使用该表，所以这并不重要。
我最终通过设置复制环境在本地进行了测试。
运行OPTIMIZE TABLE tblname;似乎是可能的，而不会造成任何停机或复制滞后。
您需要在master上运行OPTIMIZE NO_WRITE_TO_BINLOG TABLE tblname;，以避免写入bin日志并将查询复制到slave。
然后，您必须在每个从属设备中单独运行OPTIMIZE TABLE tblname;。
以下是对所发生情况的更详细解释：https://dev.mysql.com/doc/refman/5.7/en/optimize-table.html#optimize-表innodb详细信息
上面写着：
只有在准备阶段才会短暂使用独占表锁以及操作的提交阶段。
所以几乎没有锁定时间。
有一些边缘情况需要担心，可能会导致停机(由于在线DDL上的复制方法导致的表锁定(，其中一些情况在上面的链接中列出。
另一件需要考虑的事情是磁盘空间。通过InnoDB，我观察到它重新创建了表。因此，如果表中的内容加起来达到100GB，则至少需要额外的100GB可用空间才能成功运行该命令。
正如Bill所建议的，使用pt在线模式更改可能是一个更安全的替代方案，但如果您不能使用它，经过仔细的操作，似乎不会出现复制延迟和停机时间。