WordPress 数据库清理高级技巧(半自动化)

前言

开网站五年有余,折腾过很多主题和插件。大凡插件和主题,卸载后,数据没有自动清除机制,故残留于数据库之中。时日愈久,“残垣断壁”愈多。

更何堪发帖又删除,图片附件等,以及曾捯饬过的缓存插件也会向数据库写入很多内容,若不再使用,基本没有几个插件会在卸载后,自动删除其在数据库中创建的内容。

VIpsystem Pro 是我最近半年来开发的一款虚拟宝贝买卖插件。因为之前也有使用同款第三方插件,也有许多残留无用,或近来也弃用的数据。本想为此做一扩展功能解决。但折腾之人,心不如此,虽说同理之道,但也扩大涉及到WordPress数据库,一并也给收拾了。

今日不了插件所生数据,来日开专贴叙之。当日尚先解决WordPress内置七大数据库。

 

分析

数据有库,名为“mysql”。库中分类,一为WordPress;二为插件。今日仅聊第一类数据瘦身之道。

网站有文(文章)存于“wp_posts”表,有人(用户)占在“wp_users”表,人之论语(评论)丢“wp_comments”表。三足鼎立。自哲学,生万物。

此三足派生相应meta(元数据),意为非重要的辅助数据,亦或“秘书”。有之则事半功倍,无之也可自如前行。依次名为:wp_postmeta,wp_usermeta,wp_commentmeta。共得六表,笑称“三头六臂”。

六者相生相往,如银河般律动前行。古往今来,六者需相安无事必有一王者。因此诞生“wp_options”之领军人物。此表与其六者本质不同,世人进站(网站)望不见,点不着。却是在这网络海洋中的掌舵者。

WordPress 数据库清理高级技巧(半自动化)

“vipsystem pro”插件里的“数据优化”扩展功能下的“WordPress 数据库管理”功能之一

瘦身之法,在于站长。网站如儿,细心喂养,食之物,饮之水,他人不知,无可替代。

 

妖法总纲

一查二析三动手,宁可放过不错杀。

来日放长勿破釜,先做备份是宗旨。

 

wp_options 篇(瘦身妖法实战篇一)

据妖法总纲,欲练此功,必先备份。

WordPress 数据库清理高级技巧(半自动化)

再看六表体积,此后对比。

WordPress 数据库清理高级技巧(半自动化)

 

  1. 一查看。

先插结构,再查数量。

 

1.1 插结构

打印首行,看列目。

使用语句: SELECT * FROM wp_options limit 1;输出结果:

列目有四个,根据经验理解如下。

“option_id”:序号,无实际意义。用于查询某行的索引数字,此数字不重复,新建行递增。

“option_name”:键名,存放的数据名称。

“option_value”:键值,存放数据的值。

“autoload”:页面加载时是否自动加载,单站点默认“yes”,多站点默认“no”。

 

“wp_options”表,主要来源有三

  • WordPress默认设置选项
  • 主题设置选项
  • 通过插件添加设置选项

 

1.2 查数量

查看总数,心里有数。

使用语句: SELECT COUNT(*) FROM wp_options ;输出结果:

357行非多,537KB是少。若要大度可以忽略,若要严苛,我们继续。

 

2. 二分析

看表结构可知道“option_name”列是重点。是WordPress、主题和插件的设置选项的名称,而“option_value”是对应设置选项的值。

打印所有行,看其内容,根据站长折腾“日记”,判断是否该“杀”。

使用语句: SELECT * FROM wp_options  ;输出结果如下图。

WordPress 数据库清理高级技巧(半自动化)

使用“Vipsystem Pro”插件中“数据库优化”扩展功能查询的结果显示截图

 

“option_name”的结果没有固定规律可说,其中包含WordPress选项,是不可删的。当前使用或需要保留的主题设置选项,也不可删除,插件也是一样。需要删除的是那些已经不用的主题或插件的设置数据。

少数主题、插件会有独立数据表用以保存数据,方便管理。如“Vipsystem pro”有独立的option表保存设置数据。

WordPress 数据库清理高级技巧(半自动化)

可见作者必是有心之人。

在“vipsystem pro”插件中“数据库优化”扩展功能下,WordPress数据库管理功能中,我以加入常用数据的预设语句。可选择性使用,日后会写入更多。

WordPress 数据库清理高级技巧(半自动化)

 

如此,仅根据我网站的实际情况,来做处理分析。你们用来借鉴,也从此可以获得一些关键字判断的经验。

WordPress 数据库清理高级技巧(半自动化)

 

3. 三动手。删除不需要的内容。

案例1“active_plugins”关键字。

上图①内容,是WordPress程序中记录当前激活插件的数据,不可删除。

 

案例2“ping_sites”关键字

上图②内容,是WordPress程序中,发布新文章时,自动通知搜索引擎蜘蛛来抓取,更新订阅频道。

 

案例3“duoshuo_%”关键字(%为通配符)

还有许多看关键字名称就知道是什么插件。比如下图

WordPress 数据库清理高级技巧(半自动化)

如果正在使用“多说评论”那就保留这些。如果不使用,就可以删除了。

 

案例4“%_archives_%”关键字

还有一部分看“option_value”内容,就会知道是什么插件或东西产生的了。

WordPress 数据库清理高级技巧(半自动化)

如上图“cx_archives_20417”其内容一看格式便知为“档案”,且关键字中包含“archives”单词。我也不知道该条目出自那个地方。但是根据内容可以判断,记录的最新的一篇文章是2015-06-21日的。但是网站现在最新的文章是2017年的,中间也发布过很多。因此,可以判断,应该是删除了的插件或者主题所产生的。因为记得曾经我折腾过关于档案有关的插件和主题。所以是可以删除的。

使用语句: DELETE FROM wp_options WHERE option_name = 'cx_archives_20417' ,删除该条内容。若您使用的是“vipsystem pro”插件。可以直接修改某一条预设内容,或者直接在“mysql 代码”框中输入上述语句。

WordPress 数据库清理高级技巧(半自动化)

执行后得到如下结果:

WordPress 数据库清理高级技巧(半自动化)

 

案例5“ossdl_%”关键字

以“ossdl_”开始的关键字是七牛相关的设置。

使用查询语句: SELECT * FROM wp_options WHERE option_name LIKE 'ossdl_%' ;结果如下

WordPress 数据库清理高级技巧(半自动化)

我当前正在使用,不删除。

 

案例6“wpsupercache_%”关键字

这是“WP Super Cache”插件,曾经用过,现在已不再使用,所以删除。删除前先查询下结果,无问题后,再执行删除命令。

查询语句: SELECT * FROM wp_options WHERE option_name LIKE 'wpsupercache_%' ;结果如下。

WordPress 数据库清理高级技巧(半自动化)

删除语句: DELETE FROM wp_options WHERE option_name LIKE 'wpsupercache_%'

如此,您也可以操作自己的数据库了。据妖法总纲“宁可放过不错杀”,除非十足把握,否则不删。

 

wp_users 和 wp_usermeta 篇(瘦身妖法实战篇二)

有了“wp_options”篇的处理经验。user两个表的处理也非常简单。

一查结构

查询语句: SELECT * FROM wp_users limit 1;结果如下。

“wp_users”表中没有特别需要处理的,他们全都是用户。除非你想删除一年前注册的用户,参考下方查询语句(删除语句自己修改)。

DATE_SUB(CURDATE(), INTERVAL 1 YEAR) 是当前时间减去一年的时间,根据具体需要自行修改“1 YEAR”。

再查数量

查询语句: SELECT COUNT(*) FROM wp_users ;结果如下

这是在我开发“数据库优化”功能时已经删去了一大部分的用户数量。以前有1w+的注册用户。但是发现活跃用户并非很多。

WordPress没有记录用户最后登录时间的功能,但是我开发的“vipsystem pro”有记录。但有一问题是,只能计算从安装启用插件后的用户登录数据。之前是没有记录用户最后登录时间的数据。所以这7k+用户是删除了一年前未登录过的用户后的数量。

 

wp_users没有啥好说的,主要的是查看“wp_usermeta”表的内容。

一查结构

结构很简单,和“wp_options”相似。

 

再查数量

查询语句: SELECT COUNT(*) FROM wp_usermeta ;结果如下

11w+的内容。是用户数量将近20倍的内容,平均每个用户有近20条meta标签。如此这般,便有点问题。

查类别

“wp_usermeta”记录的是用户的每个元数据,并且他们在每个用户身上都是相互重复的。因此,我们总揽下所有的“wp_usermeta”罗列出来的种类,并结算价该元数据中包含了多少个用户。

查询语句: SELECT meta_key, count(meta_key) as nums FROM wp_usermeta group by meta_key ;结果如下。

WordPress 数据库清理高级技巧(半自动化)

共有98个类别。后面“nums”列,是包含的用户数量。如“admin_color”是WordPress用户后台自定义颜色风格数据。必须人手一个,所以他的数量应该和用户数量相等,都是7391,所有的用户都有该元数据。

由次可见,如果我们按照“nums”降序排列查询的结果数据,就可以得到哪些元数据是人手一个,并且由此推导出,人手一个或与其接近的元数据基本都是现在一直都使用的数据,除非我知道他是做什么的,且确实不需要了,就可以删去。

WordPress 数据库清理高级技巧(半自动化)

并且你还可以在本地搭建一个新的WordPress网站,查看纯净版下的“wp_usermeta”表中有的“meta_key”,他们是不可以删除的。

WordPress 数据库清理高级技巧(半自动化)

WordPress原始“wp_usermeta”数据表内容

 

案例1“closedpostboxes_%”关键字。

如果你对其中的某个关键字感兴趣,可以查询有这个关键字的用户,看看这个用户到底有什么不一样的。如“closedpostboxes_dashboard”关键字。

查询语句: SELECT * FROM wp_usermeta WHERE meta_key='closedpostboxes_dashboard' ;结果如图。
WordPress 数据库清理高级技巧(半自动化)

根据我曾经折腾过的“日记”,和“meta_value”数值。大体可以判断出,这些应该是我曾经测试过某个国外主题中对用户的数据。

目前已不在需要和使用。我决定删除他,使用语句: DELETE FROM wp_usermeta WHERE meta_key='closedpostboxes_dashboard' ;使用“vipsystem pro”插件返回结果如下。

WordPress 数据库清理高级技巧(半自动化)

 

案例2“billing_%”(%为通配符)关键字。

打印所有“billing_%”的内容。查询语句: SELECT * FROM wp_usermeta WHERE meta_key like "billing_%" ;结果如下。

WordPress 数据库清理高级技巧(半自动化)

从“meta_key”得知,这些应该是主题为用户添加的特殊的标签,国家、城市、地址、电话等。我网站目前似乎都不需要这些。

并且发现“user_id”只有5个用户具有这些元数据内容,我网站并未有这样特殊人群。所以删除他们,使用语句: DELETE FROM wp_usermeta WHERE meta_key like "billing_%"

 

案例3“_woocommerce_%”关键字。

一看名称,便知是“WooCommerce”插件的数据。我网站目前不实用,该删。

切记删除前查询下内容,查询语句: SELECT * FROM wp_usermeta WHERE meta_key like "_woocommerce_%" ;查询到只有两个用户有这个数据,并且一个是管理员,一个是我自己的小号。也就是说没有其他用户再有这样的数据了。

删除语句: DELETE FROM wp_usermeta WHERE meta_key like "_woocommerce_%"

 

案例4“aim”关键字。

从“meta_key”查询的种类中得知,“aim”只有17个用户。不是很多,应该也是废弃的。

WordPress 数据库清理高级技巧(半自动化)

查询下“aim”关键字的结果。查询语句: SELECT * FROM wp_usermeta WHERE meta_key = 'aim';得到结果如下。

WordPress 数据库清理高级技巧(半自动化)

共有17个“user_id”拥有,并且“meta_value”值是空的。想象下基本没有什么作用。

删除他们,删除语句: DELETE FROM wp_usermeta WHERE meta_key = 'aim'

 

案例5

这次我们不再关注关键字了。97条关键字,我大概都浏览了一便,发现大部分都是无用的。挨个删除太浪费时间,我们来个批量操作。

根据查询到的数量记过,我总结出一个规则。就是删除关键字所在用户数量小于100的记录。我们先来查询下小于100个用户的关键字都有那些。

查询语句: SELECT meta_key, count(meta_key) as nums FROM wp_usermeta group by meta_key having count(meta_key)<100;查询结果如下。

WordPress 数据库清理高级技巧(半自动化)

大致浏览线,并没有WordPress默认的关键字。我使用的Begin主题,当前主题会给用户添加如QQ,新浪微博等的元标签。

WordPress 数据库清理高级技巧(半自动化)

而他们的数量并不小于100,可以通过查询语句: SELECT meta_key, count(meta_key) as nums FROM wp_usermeta where meta_key = 'qq' or meta_key = 'weibo' or meta_key = 'weixin' group by meta_key ;得到结果如下。

WordPress 数据库清理高级技巧(半自动化)

所以我可以放心的删除数量小于100的内容。但是之前使用的查询语句 SELECT meta_key, count(meta_key) as nums FROM wp_usermeta group by meta_key having count(meta_key)<100 其结果只有53条,并且他只是用来统计“meta_key”类别的,我们不能使用同样的条件来删除。

我们需要查询到符合以上条件中“meta_key”的内容。使用查询语句: SELECT * FROM wp_usermeta where meta_key in (select meta_key from wp_usermeta group by meta_key having count(meta_key)<100) ;结果有329条,大体浏览下并无错。

然后执行删除,但是发现报错。这里不讲错误原因,只说下修改后的删除语句为: DELETE FROM wp_usermeta where meta_key in (select * from (select meta_key from wp_usermeta group by meta_key having count(meta_key)<100) as temp);使用“Vipsystem Pro”中“数据库优化”功能,返回结果如下。

WordPress 数据库清理高级技巧(半自动化)

最后,让我们能再来查询下“wp_usermate”表中“meta_key”类别。查询语句: SELECT meta_key, count(meta_key) as nums FROM wp_usermeta group by meta_key ;得到25条记录结果。

WordPress 数据库清理高级技巧(半自动化)

以上就是“wp_usermeta”表中的数据清理大致思路。更多“meta_key”中的关键字我就不赘述了,一是因为帖子并不需要完全重复的讲述,二来很多关键字我也不确定是否有用。所以第二篇章就到此结束了。

 

wp_posts 和 wp_postmeta 篇(瘦身妖法实战篇三)

前面我们实战了两个表,options 和 users 表。他们两个结构不同,所以使用的方法也略微不同。而posts表与users表比较类似。

“wp_posts”表中包括文章、修订版本、页面、文章的附件、菜单等。其中每个类别又有很多状态如继承、发布、私有、草稿、自动草稿、回收站等。

“wp_postmeta”表中存放文章的自定义字段,在我们发帖时,文章编辑框下方的,由插件或主题提供的一些选项,这些都是保存在这个表中。

WordPress 数据库清理高级技巧(半自动化)

先看“wp_posts”表中的数量。查询语句: SELECT COUNT(*) FROM wp_posts;结果如下。

我所有类型的文章包括页面加起来肯定没有这么多,我们来看下表结构。打印首行数据。查询语句: SELECT * FROM wp_posts limit 1;结果如下。

其中占位最大的“post_content”是文章内容。

“ID”为文章的id编号,我们可以通过格式“http:www.fox-studio.net/?p=文章编号”格式来访问这篇文章。“post_date”和“post_date_gmt”是发帖时间,两种时间格式。

再还有比较重要的是“post_status”记录该类型文章的状态,如草稿,回收站,未来发布等。“post_type”记录文章类型,如文章,页面,公告,音乐等,其中除了WordPress内容之的类型,还有主题或插件所创建的类型。比如我使用的begin主题,也包含图片、视频、商品等等。

WordPress 数据库清理高级技巧(半自动化)

首先我们可以在WordPress后台“文章”和“页面”下,手动删除不需要的文章和页面,当然这样应该不会很多内容。

然后我们从数据库再看下文章的“post_type”都有那些,因为我们曾经用过的主题,他们有的文章类型,都会保留在这里,就算你删了主题,他们依然存在。

查询语句: SELECT post_type, count(post_type) as nums FROM wp_posts group by post_type;得到共22个分类,并且降序排列“nums”的值,这样方便看到那个种类占用的的数量最多。如下图。

WordPress 数据库清理高级技巧(半自动化)

 

案例1“attachment”关键字。

“attachment”是附件的意思,一般表示图片,MP3等这类附件的独立页面。在我们发帖时,如果是上传图片,有一个选项“链接到”其中有一个媒体文件。

WordPress 数据库清理高级技巧(半自动化)

通常我们使用的都是媒体文件。点击图片弹出原图,或在新窗口打开该图片地址。如果使用“附件页面”则该文件会在单独的主题页面下打开这个图片。

但是如果我图片设置为“附件页面”点击图片后却打不开图片。可能是因为主题的关系吧。

“attachment”是文章类型,然后我们看下这个类型下文章状态都有那些。以确保他们都是一样的,然后考虑要不要删掉这6000+的记录。

查询语句: SELECT post_status, count(post_status) as nums from wp_posts where post_type = 'attachment' group by post_status ;结果如下。

 

WordPress 数据库清理高级技巧(半自动化)

“attachment”附件类型的文章下,只有一个状态,就是“inherit”继承。

我觉得可以删掉这些东西。删除语句: DELETE FROM wp_posts WHERE post_type = 'attachment' ;这些都是发布帖子是正在操作的,有点小丢丢激动。6000+的数据,万一我考虑错了,那可就亏了,要恢复备份的结果了。返回结果如下图。

WordPress 数据库清理高级技巧(半自动化)

迫不及待的返回网站查看了效果,结果发现杯具的事情发生了。部分文章不显示缩略图了。

WordPress 数据库清理高级技巧(半自动化)

我不愿意相信我判断是错无的。我回到网站首页,发现,最近发布的文章缩略图都是存在的。而且我也不记得最近的文章都有手动设置某个缩略图。

由此我断定肯定是“wp_postmeta”表中的数据对文章产生了影响。我找来两个文章,一个有缩略图,一个没有缩略图的。进行对比观察,看看他们有啥区别。

如 ID='31192' 的文章有缩略图,ID='31189' 的没有缩略图。打印这两个文章的“wp_postmeta”表来观察。查询语句: SELECT * FROM wp_postmeta WHERE post_id='31192' or post_id = '31189';结果如下图。

媒体库WordPress 数据库清理高级技巧(半自动化)

确实发现一个可以的关键字,“thumbnail”意思是缩略图。ID为“31189”的文章是没有缩略图的,而ID为“31192”的文章有缩略图,却没有“thumbnail”关键字。

因此我断定是因为这里定义了缩略图的ID,从而导致文件不存在,连接是可空的。缩略图不显示。当我尝试手动删除这个文章的“thumbnail”关键字后。文章缩略图出现了。

然后我就批量删除所有的“wp_postmeta”表中关键字为“_thumbnail_%”的内容。删除前先核对下,语句: SELECT COUNT(*) FROM wp_postmeta WHERE meta_key like '_thumbnail_%' ;结果如下。

然后进行删除,语句: DELETE FROM wp_postmeta WHERE meta_key like '_thumbnail_%'

全站图片都回来了,更神奇的是,很久前的文章缩略图显示不出来的,现在也都出来了,我还以为是当时的图片都丢了,因为我般站好几次。哈哈。

问题是,“添加媒体”里面也看不到所有图片了,呵呵。就这样吧。以后需要了再用sql批量更新。

 

案例2“http”关键字。

有2328条记录,我们打印前20条看看结果,分析下内容。语句: SELECT * FROM wp_posts WHERE post_type like 'http' limit 20 ;因为结果太长,我就不截图了。

这其中似乎并没有有效信息。我也不知道他用来做什么的,那就试试删掉的感觉把。

删除语句: DELETE FROM wp_posts WHERE post_type like 'http' ;返回网站看看各个文章,友情链接什么的是否完好。结果没有任何异样。

 

案例3“portfolio”关键字。

这是以前我这折腾主题时,一个国外主题中有一个“作品”的文章类型。我曾经发布过文章,所以现在可以直接删去了,并且我也打印观察了这些文章,已经非常确认。

删除语句: DELETE FROM wp_posts WHERE post_type = 'portfolio'

 

更多内容各位就可以自行判断了。以及“wp_postmeta”表也和上面也是一样的处理方法。当我们删除完“wp_posts”表中的文章,再进行“wp_postmeta”表工作前,可以先使用预设“已被删除的文章的元数据”删除这些。

WordPress 数据库清理高级技巧(半自动化)

结果被删除了4w+的元数据。

WordPress 数据库清理高级技巧(半自动化)

这估计能让数据库小好几MB。

 

wp_comments 和 wp_commentmate 篇(瘦身妖法实战篇四)

至此已经身经百战,下面我就简单说下评论篇的经验。

在“wp_comments”表中,有一个列目叫“comment_type”,这里存放评论的类型。包含通知(Ping)、引用(PingBack)和参照(Trackback)的评论。

具体内容可以百度他们的单词了解。在大部分网站,这些内容是可以删去的。而且我也已经将此语句做近了“vipsystem pro”插件“数据库优化”的预设内容中。

WordPress 数据库清理高级技巧(半自动化)

再其他关键字,似乎也没什么了吧。垃圾评论什么的在WordPress后台都可以删去。

 

然后是“wp_commentmeta”这个表也不晓得是那些内容,我将整个表删掉也没有啥问题。不过它又会自己重新出来。而且开始有了新的数据。

不过就这样吧。以后搞懂了再说。

 

出师表

经过四次实战训练,相信对WordPress数据库优化学习差不多了吧。我也是现学现卖。

最后回顾下我们的妖法总纲:

一查二析三动手,宁可放过不错杀。

来日放长勿破釜,先做备份是宗旨。

 

没啥可说的了,看看我们最后瘦了多少MB。

WordPress 数据库清理高级技巧(半自动化)

 

计算得出本次清理共缩减了16MB的数据,其中posts和postmate表缩减最多。他们都是以前更换主题时数据的残留。国外的有些主题,他们都会带有自己的模板,和一些模块数据。

 

本次分享就到这里,如果喜欢请支持我的插件“vipsystem pro

 

千年骚狐
微信公众号

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

目前评论:1   其中:访客  1   博主  0

    • avatar qwe 0

      O(∩_∩)O谢谢