在 Backend Tw 的 https://www.facebook.com/groups/616369245163622/posts/2467225396744655/ 這邊看到：
先大概回答一下假設，DELETE 後的空間是可以被同一個表格重複使用的，所以應該是還好，不過離峰時間跑一下 OPTIMIZE TABLE 也沒什麼關係就是了。
裡面提到的「13.7.2.4 OPTIMIZE TABLE Statement」(MySQL 5.7 文件) 以及「13.7.2.4 OPTIMIZE TABLE Statement」(MySQL 5.6 文件) 都有講到目前比較新的版本都已經是 Online DDL 了：(這邊抓 5.6 的文件，有支援的版本資訊)
Prior to Mysql 5.6.17, OPTIMIZE TABLE does not use online DDL. Consequently, concurrent DML (INSERT, UPDATE, DELETE) is not permitted on a table while OPTIMIZE TABLE is running, and secondary indexes are not created as efficiently.
As of MySQL 5.6.17, OPTIMIZE TABLE uses online DDL for regular and partitioned InnoDB tables, which reduces downtime for concurrent DML operations. The table rebuild triggered by OPTIMIZE TABLE is completed in place. An exclusive table lock is only taken briefly during the prepare phase and the commit phase of the operation. During the prepare phase, metadata is updated and an intermediate table is created. During the commit phase, table metadata changes are committed.
文件上有提到會有一小段 lock 的時間，不過一般來說應該不會造成太大問題。
這邊要講的是早期的經典工具 pt-online-schema-change (pt-osc)，這是使用 TRIGGER-based 的方式在跑，他的範例就直接提供了一個不需要 Online DDL 支援的版本：
Change sakila.actor to InnoDB, effectively performing OPTIMIZE TABLE in a non-blocking fashion because it is already an InnoDB table:
pt-online-schema-change --alter "ENGINE=InnoDB" D=sakila,t=actor
這在早期的時候還蠻常被拿出來用的，如果還在維護一些舊系統的話還蠻推薦的...