共计 1833 个字符，预计需要花费 5 分钟才能阅读完成。
WordPress 使得 MYSQL 停止 99% 是 wp_options 表引起的
wp_options 表是 WordPress 中最重要的表，一切程序设置、主题设置和绝大多数插件的设置均保存在此。在使用 WordPress 的过程中，测试插件与插件的反安装功能不完善，都很容易造成 wp_options 表的产生大量垃圾数据，这不仅占据了大量的数据库空间，还使数据库查询的效率降低。wp_options 表中的垃圾数据主要有两种：
1. 无效的插件设置：一般来说，安装 WordPress 后，必定会大量安装使用各种插件体验，直到一段时间之后才会开始稳定的固定使用几款插件。无用的插件虽然被删除掉了，但是其保存在的数据库中的设置却没有被删除 (80% 以上的插件没有提供删除自身添加的数据库数据的功能，所以我也希望插件的作者都能够提供彻底反安装的功能)，从而出现了大量垃圾数据。对于大部分插件来说，其在数据库中的数据命名都是源自于插件名称或者缩写，比如自动文章关联插件“Yet Another Related Posts Plugin”，它在数据库中的数据全部以“yarpp_”起始。这样我们就可以在 PHPMyAdmin 中确定相关的条目，删除即可。如果了解 MySQL 的语法，也可以执行：
DELETE FROM `wp_options` WHERE `option_name` LIKE “yarpp_%”
如果我们早就忘记了安装过什么插件插件的名字是什么呢? 单凭经验也很难确定哪些是垃圾数据哪些是有用的数据，不过有一点很重要：全新安装的 WordPress 3.1.3 版 wp_options 数据库条数为 118 条 (option_id 1~118)，也就是说位于这之后的所有条目都是由用户后来的调整和主题、插件产生的，后面的条目可以尝试删除，当然过程中要胆大心细，提前备份好数据库以防出现问题。另一个比较稳妥的方案就是在本地全新建立一个 WordPress，配置好之后将数据库导入到主 WordPress 数据库中。
2. 无用的 RSS Feed Cache：其实这才是 wp_options 表变得庞大的最重要原因，如果你在 wp_options 表中发现了大量 option_name 以“_transient”开头的数据，那就是它没跑了。先说说这玩意儿是干嘛用的，这玩意就是 WordPress 程序中引入 RSS Feed 后产生的缓存，在表中的表现主要有这三种：
- ■_transient_feed_* Feed 内容
- ■_transient_feed_mod_* Feed 最后更改时间
- ■_transient_timeout_feed_* Feed 缓存保存期限
这玩意是如何产生的呢? 如果你在你的博客中使用了 RSS 小工具; 如果你在后台开启了“博客引入链接”、“WordPress China 博客”、“其它 WordPress 新闻”; 如果你的插件中引入了 RSS 小工具显示新闻比如 NextGen Gallery。只要你看到了这些东西，那就会在数据库中产生这些垃圾数据 (或许说是无用数据更为恰当)，简直防不胜防。以我的博客为例，2 个月的时间 wp_options 表就被这种数据撑大了 600KB，网络上甚至有人达到了十数 MB 之巨。经过验证，这种数据清除后也会不断的产生，除非你能保证不去后台有 RSS Feed 小工具的页面。
优化清理 wp_options 数据表冗余数据
WordPress 数据表中最让人头痛的就是 WP_Options 数据表, 还好这个表是独立跟其他表没有关联的. wp_options 表主要是存贮 WP 的全局数据设置方面的信息, 如博客名、博客地址、基本设置、插件设置、主题设置等等. 清理 wp_options 数据表有以下方法:
1. 安装 Clean Options (http://wordpress.org/extend/plugins/clean-options/) 插件清理 WP_Options 数据表的冗余数据。下载安装 - 激活 - 进入操作即可。也可以进入你的 phpMyAdmin, 手动选择删除 wp_options 数据表里的内容, 以 _transient、_site 开始的都可以删除掉。 这些都是治标的办法 。
2. 备份 wp_options 数据表并导出, 然后清空 wp_options 表, 然后在本地架设环境新安装一个 WordPress。
设置好和你服务器上的博客同样的博客名、博客地址、基本设置等等, 然后导出本地的 wp_options 数据表, 导入到服务器上的数据库去。最后然后进入博客重新设置下插件、博客主题等。
