MySQL 怼了架构师关于 optimize table 需求 与 为什么反对 optimize table

这开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, Oceanbase, Sql Server等有问题，有需求都可以加群群内，可以解决你的问题。加群请联系 liuaustin3 ，（共1830人左右 1 + 2 + 3 + 4 +5） 4群（360+ 关闭自由申请,新入群的将默认分配达到5群）,另欢迎 OpenGauss 的技术人员加入。

2024年1月某些星象的原因，导致我个人的星盘在1月大概率要和某些人要有不愉快。这不就来了，在一次关于mysql 数据库数据表清理后，关于optimize table 的问题上，我毫无悬念的和架构师们进行了一次非常不nice 的沟通。

随意就有了此篇的文章，因为我这个人比较的要通过实际的情况来说明问题，而不是用权威来压制，那样没有品。事情简单的说一下，几十个库，几百张表，要进行数据的清理，这没有问题，我们会使用自动的手段来进行，而后面一个架构师提出，希望能对表进行optimize table 的操作，并且提出这样的好处多多。 

但是，但是，但是，说话办事就怕光站在自己的角度来说问题，我对此要求是拒绝的，并且我拿出了 PG SQL SERVER ORACLE 甚至 IBM DB2 的一些理论对于对方无礼的需求进行驳斥，因为这个架构师提出，optimize table 很快，MYSQL8 有新功能，大致的意思我翻译一下，optimize table 的任何过程中，不会对表产生影响，产生锁，产生业务影响。因为我们是 7*24小时的业务，所以DB 对于表在一些操作的中，是非常忌讳，产生TABLE LOCK 并且是无预估的长时间的表不可用的情况。 

那么我们来看看到底MYSQL8  是否如这个架构师讲的，很快不会对业务有什么影响。

我们使用一个，说新不新 ，说旧不旧的MySQL数据库版本，8.031 来验证MYSQL8 对这个optimize table 并没有多少改进。

mysql> select version();<br>+-----------+<br>| version() |<br>+-----------+<br>| 8.0.31    |<br>+-----------+<br>1 row in set (0.00 sec)<br><br>