WordPress数据库wp_options优化，WordPress使得MYSQL停止的原因和解决方法

WordPress使得MYSQL停止99%是wp_options表引起的

wp_options表是WordPress中最重要的表，一切程序设置、主题设置和绝大多数插件的设置均保存在此。在使用WordPress的过程中，测试插件与插件的反安装功能不完善，都很容易造成wp_options表的产生大量垃圾数据，这不仅占据了大量的数据库空间，还使数据库查询的效率降低。wp_options表中的垃圾数据主要有两种：

1.无效的插件设置：一般来说，安装WordPress后，必定会大量安装使用各种插件体验，直到一段时间之后才会开始稳定的固定使用几款插件。无用的插件虽然被删除掉了，但是其保存在的数据库中的设置却没有被删除（80%以上的插件没有提供删除自身添加的数据库数据的功能，所以我也希望插件的作者都能够提供彻底反安装的功能）， 从而出现了大量垃圾数据。对于大部分插件来说，其在数据库中的数据命名都是源自于插件名称或者缩写，比如自动文章关联插件“Yet Another Related Posts Plugin”，它在数据库中的数据全部以“yarpp_”起始。这样我们就可以在PHPMyAdmin中确定相关的条目，删除即可。如果了解MySQL的语法，也可以执行：
1
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数据表, 导入到服务器上的数据库去。最后然后进入博客重新设置下插件、博客主题等。