我的客户在Woocomerce上有一家1.2GB数据库的商店。我知道类似的商店（按产品计算）应该有大约700Mb的空间。
最大的表是wp_posts（760Mb）本身！我觉得很奇怪。通常最大的表是wp_postte或wp_选项。
我试着通过插件优化这个数据库：WP Sweep和WP optimize，这样就没有修改和草稿了。
我还尝试了SQL：
OPTIMIZE TABLE
但它是innoDB，所以它不支持它。我收到这个消息：
表不支持优化，而是执行重新创建+分析
就这样结束了？我的意思是：“再现+分析”还是我应该做？怎么做？
我在innoDB中读到，我应该转储表并还原，但是当我通过DBeaver执行此操作时，我得到了相同的大小。
知道我该怎么做吗？
最佳答案
这个错误消息有点误导人，因为它可以追溯到MyISAM是默认存储引擎的时候，OPTIMIZE TABLE在MyISAM中做了一些与在InnoDB中不同的事情。例如，在优化表之前，MyISAM不能从删除的行中回收空间（而InnoDB是动态回收空间的）。
InnoDB确实支持OPTIMIZE TABLE，而且它做了一些有用的事情。在使用复制算法时，它的作用与ALTER TABLE基本相同。也就是说，它创建一个新文件，并将数据逐行复制到新文件中。这就完成了碎片整理和索引重建，就像完成了转储和还原一样。所以你不需要转储和恢复。
优化表之后，如果碎片很少的话，InnoDB表的大小可能会接近以前的大小。
坦白地说，按照我所做过的大多数MySQL项目的标准，表1.2GB的大小并没有那么大。我们开始担心一个表是否大于500GB，如果这个表大于800GB，或者大于剩余的可用磁盘空间，我们开始提醒开发人员。
关于mysql - 巨大的wp_post表，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/58997229/