Michael Adams, Quantum Bug Creator at Automattic once said:

“修订内容存储在posts表中。我还不知道这会对post查询产生什么样的影响。我们将在不久的将来在WordPress.com上把开关切换到“开”，我们将更好地了解它会造成什么样的损害（如果有的话）。”

后来他们确实打开了它，还有WordPress。com公司now stores 博客上每篇文章的最后25次修订。所以，是的，你可以处理修改。

后期修订的问题是，您的数据库大小可能会变得非常大（取决于创建的修订数量），这反过来又会增加MySQL的处理负担。

Nevertheless, you can deal with it. 启用页面和数据库级缓存-W3 Total Cache 如果您的网站是从单一服务器提供服务的，请尝试WP Super Cache. 还有各种web应用程序加速器，如Varnish cache. 拥有数万条帖子的网站无论如何都必须对数据库和其他东西进行分片、从复制和主复制。

即使如此，修订（非常？）IMO，旧帖子是对资源的浪费。至于我，我会不时（每隔2-3天）删除已发布帖子的修订。

删除修订：

备份，备份，先备份。总是

如果您想使用插件删除修订和优化数据库，并保持简单，请尝试Better Delete Revisions. 您可能还想看看Revision Control.

也可以使用SQL手动执行，如下所示。

(1A) 删除WordPress博客上所有帖子和页面的修订(source):

DELETE a,b,c  
FROM wp_posts a  
LEFT JOIN wp_term_relationships b ON (a.ID = b.object_id)  
LEFT JOIN wp_postmeta c ON (a.ID = c.post_id)  
WHERE a.post_type = \'revision\';

(1B) 如果您使用WordPress（Blogroll等）中的链接功能，请不要使用前面提到的SQL查询。改用这个(read why?):

DELETE a,b,c
FROM wp_posts a
LEFT JOIN wp_term_relationships b ON ( a.ID = b.object_id)
LEFT JOIN wp_postmeta c ON ( a.ID = c.post_id )
LEFT JOIN wp_term_taxonomy d ON ( b.term_taxonomy_id = d.term_taxonomy_id)
WHERE a.post_type = \'revision\'
AND d.taxonomy != \'link_category\';

(2) 删除自动草稿：

DELETE FROM wp_posts WHERE post_status = \'auto-draft\';

(3) 优化数据库表：

OPTIMIZE TABLE `wp_commentmeta`, `wp_comments`, `wp_links`, `wp_options`, `wp_postmeta`, `wp_posts`, `wp_terms`, `wp_term_relationships`, `wp_term_taxonomy`, `wp_usermeta`, `wp_users`

NOTE: 在上面列出的SQL查询中，不要忘记替换wp_ 使用数据库表前缀