能否在无复制延迟及downtime的情况下运行OPTIMIZE TABLE？

你提出的先在主库执行带NO_WRITE_TO_BINLOG参数的OPTIMIZE TABLE，再逐个在从库执行相同命令的方案完全可行，是MySQL 5.7 InnoDB引擎下规避OPTIMIZE操作引发主从复制延迟的常用实现方案。
NO_WRITE_TO_BINLOG（也可替换为等效的LOCAL关键字）会让主库的OPTIMIZE操作不写入binlog，因此不会被同步到从库触发自动执行，你可以灵活控制各个从库的执行时机，错开业务高峰避免影响线上服务。

• 元数据锁阻塞风险：InnoDB的OPTIMIZE TABLE本质是执行「重建表+重新统计索引信息」的逻辑，执行全程会对目标表加元数据锁，所有针对该表的DML读写操作都会被阻塞，500GB的大表执行时长通常在几十分钟到数小时不等，必须在业务低峰期执行。
• 主从一致性风险：执行操作期间如果有针对该表的DDL操作下发，会导致正在执行OPTIMIZE的节点和其他节点表结构不一致，后续主从同步直接中断报错。
• 从库临时延迟风险：即使是手动在从库执行OPTIMIZE，操作期间会占用大量磁盘IO、CPU资源，如果从库同时承接读流量或者同步主库的DML请求，依然会出现短时间的复制延迟，建议执行前先把该从库的读流量切走再操作。
• 磁盘空间不足风险：OPTIMIZE重建表需要占用和原表大小相当的临时磁盘空间，执行前必须确认当前节点磁盘剩余空间至少大于等于原表体积的1.2倍，避免磁盘占满导致服务宕机。
• 操作顺序风险：必须严格遵循「先完成主库操作、再逐个操作从库」的顺序，如果提前操作从库，主库后续下发的删除操作可能出现主从数据行数不一致的问题。

• 无锁表重建：使用pt-online-schema-change工具执行无锁表重建，指定--alter='ENGINE=InnoDB'参数即可实现和OPTIMIZE完全一致的碎片回收效果，全程仅在最后交换表名时有毫秒级锁，不会阻塞业务DML，也支持配置不写binlog手动在各节点执行。
• 后台自动碎片回收：如果可以接受空间逐步回收不需要立即释放，可调大innodb_purge_threads参数提升purge线程效率，同时开启innodb_defragment=1，后台会自动合并空闲碎片页，不需要停业务，缺点是回收效率低，通常仅能回收60%~80%的data_free空间，且会产生少量额外IO开销。
• 新表迁移数据：如果当前表仅保留少部分新数据，可新建同结构空表，分批将需要保留的数据插入新表，最后用RENAME TABLE原子替换新旧表，删除旧表即可直接释放全部空间，执行速度远快于OPTIMIZE。

内容的提问来源于stack exchange，提问作者Bernard Wiesner