WordPress速度优化系列之 清理数据库的方法
时间：2017-04-08目前本站已经有300多篇日志和超过2000条评论，虽然数据量不是很多但是偶尔会出现，404或者是500亦或是502错误，甚至造成服务器宕机。
也就出现了今天这篇”WordPress速度优化系列之“清理数据库”，全部来源于之前对和邪社进行优化所得来的经验以及教训，以后还有其他相关的文章。
通过上网搜索相关优化技巧和个人经验，造福各位博主，于是就有了今天大家看到的WordPress优化系列之“清理数据库”。
既然是WordPress优化系列，肯定有方方面面需要照顾到，比如选择正确的插件，减少数据库请求次数，如果最大限度的提升加载速度等等，我会尽量把方方面面需要说明清楚的内容都写出来。今天就先讲一下最容易也是最需要亟需解决的一个问题，那就是日益增长的数据库问题。
刚接触wordpress我对这方面的经验为零，完全的从零开始，甚至没有接触过linux或者是相关的一些技术，比如Nginx（Apache）的优化配置，数据库（MySQL）的理论知识以及相关的配置等等等等。只因从一台完全空白的服务器（仅有linux或者是Windows）到一个完整的WordPress博客是一个相当“艰巨”的过程。而这篇文章提到的内容肯定不可能非常完善，以后我会逐步的将其充实起来。
目前小残博客有300多篇日志和超过2000条评论，可是MySQL数据库的总大小已经超过了250多MB，从上图可以看到和邪社的数据库大小已经到了250M（这个小残优化之前的截图，现在的数据库因为已经清理完毕，所以很小了）
这么“庞大”的数据库到底有多少有用呢？下面就开始一步步优化我们的数据库。
清理wp-commentmeta表
WordPress现在已经发展到了3.1版本，而如果是从2.X系列就开始使用WP的用户则会发现数据库增长的比例跟文章发布的数量不成比例，原因当然有很多。
我们首先要清理的是wp_commentmeta这个表，在2.9版本之前，这个表完全不存在，先来看看它的内容，浏览表结构可以发现其为akismet_history、akismet_result、akismet_as_submitted等
很显然，这个是WP官方推荐的反垃圾评论插件Akismet所生成的，其值的作用是记录管理员用户对垃圾评论的处理结果以及插件自动判断某条评论是否为垃圾评论的相关记录。
（如果你没有安装这个Akismet插件）可以跳过这一步
如果你安装了AKismet那么只需要在MySQL管理器也就是phpMyAdmin里面输入一条简单的命令即可清除。进入数据库运行MySQL语句查询，
TRUNCATE TABLE `wp_commentmeta`
清理Revision Post（日志修订）
Revision Post 是 WordPress 在2.6版之后加入自动保存日志修订版造成的，您每修改一次日志，就会增加一个 revision ， 如果您修改多次，数篇日志之后，这将是一个很可怕的数量！您如果有上百篇的日志，您的冗余 revisiong 可能会有上千篇之多！
（此描述来自插件delete-Revision manager）这里我们使用一个简单好用的插件来清理，Delete-revision Manager（WP官方扩展链接），安装此插件后，运行该插件可以清楚的看到目前数据库里面所保存的日志修订。
PS:安装好插件清理成功后在修改修改wp-config.php文件:合适的位置插入这一行参数：
//取消自动修订版
define('WP_POST_REVISIONS',false);
彻底优化清理wp_options
wp_options表是用来存贮WP的设置方面的信息，如博客名、博客地址、基本设置、插件设置、主题设置…等。
关于这个表，如果你不是砖家级的人物，建议直接跳过，因为这个操作这个表的危险性比较大。此表用来存储WP设置相关的信息，如地址、插件设置等等。但是因为各位的“折腾”，这个表会因为频繁的尝试安装/禁用各种插件变得臃肿不堪。
(本站数据库259Mwp_options占用了248M)十分影响数据库运行速度。因危险性较大，我不做过多阐述
如果发现自己的博客中这个表也和小残博客一样这个表异常的大那么可以先备份数据库然后在清空wp_options表
最后本地搭建一个wordpress然后设置的网站标题后台密码插件设置后台设置全部设置为和自己的博客一模一样然后在导入wp_options表即可。
除非万不得已最好不要这样做,小残我也是被逼无奈。。。
清理wp_postmeta
可能有很多东西你想保存到你的一些日志中 — 你写日志时候的心情 ，你当时听的歌曲，你所处的地理位置，一些相关日志的列表，特定为搜索引擎指定日志信息等等。所以这些东西都会保存到wp_postmeta 这个表中。关于这个表的清理可以借助插件WP-Cleanup完成。执行下列相关的MySQL指令则可以进一步的清理出无用的数据
DELETE FROM wp_postmeta WHERE meta_key = '_edit_lock';
DELETE FROM wp_postmeta WHERE meta_key = '_edit_last';
DELETE FROM wp_postmeta WHERE meta_key = '_revision-control';
最终优化结果如上图从259M减少到14.4M,其中大部分占用的都拜wp_postmeta所赐
WordPress数据库相关的清理工作到此就告一段落，其他关于WordPress数据库的优化技巧也还有很多，牵扯到了系统底层方面以及需要借助插件完成。
关于这篇文章除了优化清理wp_options以为所涉及到的SQL语句基本不会出现什么问题
但是永远记住一句话：做好备份！只有做好备份工作才可以有备无患。
本文来自小残博客
也就出现了今天这篇”WordPress速度优化系列之“清理数据库”，全部来源于之前对和邪社进行优化所得来的经验以及教训，以后还有其他相关的文章。
通过上网搜索相关优化技巧和个人经验，造福各位博主，于是就有了今天大家看到的WordPress优化系列之“清理数据库”。
既然是WordPress优化系列，肯定有方方面面需要照顾到，比如选择正确的插件，减少数据库请求次数，如果最大限度的提升加载速度等等，我会尽量把方方面面需要说明清楚的内容都写出来。今天就先讲一下最容易也是最需要亟需解决的一个问题，那就是日益增长的数据库问题。
刚接触wordpress我对这方面的经验为零，完全的从零开始，甚至没有接触过linux或者是相关的一些技术，比如Nginx（Apache）的优化配置，数据库（MySQL）的理论知识以及相关的配置等等等等。只因从一台完全空白的服务器（仅有linux或者是Windows）到一个完整的WordPress博客是一个相当“艰巨”的过程。而这篇文章提到的内容肯定不可能非常完善，以后我会逐步的将其充实起来。
目前小残博客有300多篇日志和超过2000条评论，可是MySQL数据库的总大小已经超过了250多MB，从上图可以看到和邪社的数据库大小已经到了250M（这个小残优化之前的截图，现在的数据库因为已经清理完毕，所以很小了）
这么“庞大”的数据库到底有多少有用呢？下面就开始一步步优化我们的数据库。
清理wp-commentmeta表
WordPress现在已经发展到了3.1版本，而如果是从2.X系列就开始使用WP的用户则会发现数据库增长的比例跟文章发布的数量不成比例，原因当然有很多。
我们首先要清理的是wp_commentmeta这个表，在2.9版本之前，这个表完全不存在，先来看看它的内容，浏览表结构可以发现其为akismet_history、akismet_result、akismet_as_submitted等
很显然，这个是WP官方推荐的反垃圾评论插件Akismet所生成的，其值的作用是记录管理员用户对垃圾评论的处理结果以及插件自动判断某条评论是否为垃圾评论的相关记录。
（如果你没有安装这个Akismet插件）可以跳过这一步
如果你安装了AKismet那么只需要在MySQL管理器也就是phpMyAdmin里面输入一条简单的命令即可清除。进入数据库运行MySQL语句查询，
复制代码
代码如下:TRUNCATE TABLE `wp_commentmeta`
清理Revision Post（日志修订）
Revision Post 是 WordPress 在2.6版之后加入自动保存日志修订版造成的，您每修改一次日志，就会增加一个 revision ， 如果您修改多次，数篇日志之后，这将是一个很可怕的数量！您如果有上百篇的日志，您的冗余 revisiong 可能会有上千篇之多！
（此描述来自插件delete-Revision manager）这里我们使用一个简单好用的插件来清理，Delete-revision Manager（WP官方扩展链接），安装此插件后，运行该插件可以清楚的看到目前数据库里面所保存的日志修订。
PS:安装好插件清理成功后在修改修改wp-config.php文件:合适的位置插入这一行参数：
复制代码
代码如下://取消自动修订版
define('WP_POST_REVISIONS',false);
彻底优化清理wp_options
wp_options表是用来存贮WP的设置方面的信息，如博客名、博客地址、基本设置、插件设置、主题设置…等。
关于这个表，如果你不是砖家级的人物，建议直接跳过，因为这个操作这个表的危险性比较大。此表用来存储WP设置相关的信息，如地址、插件设置等等。但是因为各位的“折腾”，这个表会因为频繁的尝试安装/禁用各种插件变得臃肿不堪。
(本站数据库259Mwp_options占用了248M)十分影响数据库运行速度。因危险性较大，我不做过多阐述
如果发现自己的博客中这个表也和小残博客一样这个表异常的大那么可以先备份数据库然后在清空wp_options表
最后本地搭建一个wordpress然后设置的网站标题后台密码插件设置后台设置全部设置为和自己的博客一模一样然后在导入wp_options表即可。
除非万不得已最好不要这样做,小残我也是被逼无奈。。。
清理wp_postmeta
可能有很多东西你想保存到你的一些日志中 — 你写日志时候的心情 ，你当时听的歌曲，你所处的地理位置，一些相关日志的列表，特定为搜索引擎指定日志信息等等。所以这些东西都会保存到wp_postmeta 这个表中。关于这个表的清理可以借助插件WP-Cleanup完成。执行下列相关的MySQL指令则可以进一步的清理出无用的数据
复制代码
代码如下:DELETE FROM wp_postmeta WHERE meta_key = '_edit_lock';
DELETE FROM wp_postmeta WHERE meta_key = '_edit_last';
DELETE FROM wp_postmeta WHERE meta_key = '_revision-control';
最终优化结果如上图从259M减少到14.4M,其中大部分占用的都拜wp_postmeta所赐
WordPress数据库相关的清理工作到此就告一段落，其他关于WordPress数据库的优化技巧也还有很多，牵扯到了系统底层方面以及需要借助插件完成。
关于这篇文章除了优化清理wp_options以为所涉及到的SQL语句基本不会出现什么问题
但是永远记住一句话：做好备份！只有做好备份工作才可以有备无患。
本文来自小残博客
织梦dedecms后台增加logo上传功能用过dedecms的朋友都知道，织梦cms后台系统基本参数里是无法直接上传图片的，我们更换logo图只能到ftp里替换，非常的不方便
PHP中递归的实现实例详解递归（http:/en.wikipedia.org/wiki/Recursive）是一种函数调用自身（直接或间接）的一种机制，这种强大的思想可以把某些复杂的概