zblog数据库调用优化 zblog缓存插件
怎么清理优化wordpress数据库
一、数据库表清理
红桥ssl适用于网站、小程序/APP、API接口等需要进行数据传输应用场景,ssl证书未来市场广阔!成为创新互联的ssl证书销售渠道,可以享受市场价格4-6折优惠!如果有意向欢迎电话联系或者加微信:18980820575(备注:SSL证书合作)期待与您的合作!
1. wordpress数据库表
wp_commentmeta: 用于保存评论的元信息,在将评论放入回收站等操作时会将数据放入此表,Akismet等插件也会生成此表的数据。此表不太重要
wp_comments: 用于保存评论信息的表
wp_links: 用于保存用户输入到Wordpress中的链接(通过Link Manager)的表
wp_options: 用于保存Wordpress相关设置、参数的表,里面包括了大量的重要信息
wp_postmeta: 用于保存文章的元信息(meta)的表
wp_posts: 用于保存你所有的文章相关信息的表,非常的重要。一般它存储的数据是最多的
wp_terms: 文章和链接分类以及文章的tag分类可以在表里找到
wp_term_relationships: 日志与wp_terms中的类别与标签联合起来共同存储在wp_terms_relationships表中。类别相关链接也存储在wp_terms_relationships中
wp_term_taxonomy: 该表格对wp_terms表中的条目分类(类别、链接以及标签)进行说明
wp_usermeta : 用于保存用户元信息(meta)的表
wp_users:用于保存Wordpress使用者的相关信息的表
2. 清理涉及到的表
更换主题,删除插件会在将数据留在数据库中,在卸载后无法被清理。除此之外,在由于一些操作,会导致数据库的冗余,比如已经没有的评论,不应该在评论元数据表中有记录,由于没有外键的约束,这些记录没有被删除,会造成数据的冗余。本文的宗旨是删除掉不必要的数据库内容,提高wordpress的效率
在此,主要涉及到一下几张表:wp_options,wp_posts,wp_postmeta,wp_commentmeta
注意清理之前进行备份
3. wp_options的清理
wp_options 这个数据表是wordpress设置的全局数据,这个表会经常有数据膨胀。主要原因是:
(1)以前用过的一些插件、主题在删除之后没有进行设置的清理,造成残留数据
(2)占用数据的大户–RSS缓存,后台的数据调用竟然会放到数据库里面
处理方法:
①网上对RSS处理方法有两种一个是修改后台的文件直接不去调用,这个是我不喜欢的毕竟修改了程序,其实这个很容
易忘记WP升级是太频繁的哪次更新覆盖了新文件还是照样缓存.另外一种就是在配置文件里面填写define(‘MAGPIE_CACHE_ON’, ’0′); 这个是管用的,添加以后后台首页的调用明显变慢
②使用插件clean options
③费力但是简单的清除方法:删除wp_options表,会删除一些设置,需要重新设置wordpress,推荐新手使用
TRUNCATE TABLE wp_options;
4.wp_posts清理
wordpress的文章有好多:wp_posts表中包括
文章种类:文章、修订版本、页面、文章的附件、菜单
其中每种文章又会有很多状态:继承、发布、私有、草稿、自动草稿、回收站中
冗余原因:
(1)在博主写文章的时候,系统会保存很多的中间状态,在文章发布之后其很多的中间状态没有被删除
解决办法:
①使用插件:WP Cleaner,使用插件的好处就是有保护机制,无论怎么操作都无法影响已发布的贴子,请放心使用
②自己动手删除,数据库中的标志删除文章,注意备份
说明:wp_posts的重要字段含义:
post_type:文章类型,post表示为文章,revision表示为修订版本,page为页面,attachment是文章的附件信息,nav_menu_item是菜单。这里我们需要的是文章、页面、和菜单
post_status:文章状态,inherit是继承的附件和文章的附带信息,publish是已经发布、private是私有的,draft是草稿,auto-draft是自动草稿,trash是在回收站。这里我们需要的是publish的状态的
这里我们主要是要 已经发布的文章、页面和菜单,除此之外的都可以删除,当然可以根据自己的需求选择删除哪些
DELETE FROM wp_posts
WHERE NOT(post_status = ‘publish’ AND post_type IN(‘post’,'nav_menu_item’,’ page’));
③去除WP保存修订版本的功能
WordPress默认的功能并不都是我们想要的,比如修订版本历史对于大多数人来说是无用的鸡肋功能。所以我么需要禁止一些博客功能,来达到较为符合个
人要求的博客应用。对于高手来说,可以直接修改程序的配置文件,来禁止相关功能。对于我等程序小白来说还是利用插件是最佳的选择
推荐中文插件SuperSwitch来关闭一些我们不需要的博客功能。这个插件可以关闭自动保存和修订历史版本,还可以关闭博客程序、主题、插件的自动更新。功能非常强大,操作及其简单。用SuperSwitch禁止了保存修订版本之后,文章序号就不会断得太厉害了
5.wp_postmeta清理
wp_postmeta是文章的元信息表,其数据是系统或者插件使用
冗余原因:
(1)文章被删除之后,其在wp_postmeta中的数据理应被删除,在系统中多数情况是系统自动删除,但是由于人为删除文章,系统不知道被删除,就不会删除wp_postmeta表中的数据,造成冗余
(2)很多主题、插件没有做好及时清除的工作
解决办法:
① 手动删除
规矩删除
删除文章中不存在文章的元信息
DELETE FROM wp_postmeta WHERE post_id NOT IN (SELECT post_id FROM wp_posts);
安全删除
删除_edit_lock和_edit_last条目是安全的,所以这里给出SQL语句
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 = ‘_wp_old_slug’;
DELETE FROM wp_postmeta WHERE meta_key = ‘_revision-control’;
DELETE FROM wp_postmeta WHERE meta_value = ‘{{unknown}}’;
特殊插件删除
postnav插件会记录每个文章的访问数,如果不需要,可以删除
DELETE FROM wp_postmeta WHERE meta_key = ‘views’;
特殊操作删除
在WordPress的后台上传图片或者附件后会在wp_postmeta中生成_wp_attached_file和_wp_attachment_metadata两个项,wp_posts也会记录附件的信息。如果使用FTP工具上传文件,表中就不会有这些信息
DELETE FROM wp_postmeta WHERE meta_key = ‘_wp_attached_file’;
DELETE FROM wp_postmeta WHERE meta_key = ‘_wp_attachment_metadata’;
洁癖删除
这几条条语句执行完毕能够删除掉95%以上的数据,算的上是极限优化了,最后考虑到这个数据表并不是很重要,有洁
净癖的人可以尝试清空这个表,当然我测试清空表会让一些原本的数据丢失
TRUNCATE TABLE wp_postmeta;
6. wp_commentmeta清理
冗余原因:
(1)评论被删除之后,其在wp_commentmeta中的数据理应被删除,在系统中多数情况是系统自动删除,但是由于人为删除文章,系统不知道被删除,就不会删除wp_commentmeta表中的数据,造成冗余
(2)很多主题、插件没有做好及时清除的工作
解决办法:
一下语句去除没有用的数据,如果评论中没有此条评论,那么在wp_commentmeta也没有意义,好像wordpress在清空回收站的时候会删除wp_commentmeta相应的数据。如果不出意外,下面的操作我们应该不需要做
DELETE FROM wp_comments WHERE comment_approved = ‘trash’;
DELETE FROM wp_commentmeta WHERE comment_id NOT IN (SELECT comment_id FROM wp_comments);
在wp_commentmeta里面会记录评论被删除的时间,这些信息用处不是很大,当评论被从回收站删除之后,这些删除的时间意义就不是很大,就可以删除了,所以用下面的语句一样达到删除的目的
DELETE FROM wp_commentmeta WHERE meta_key LIKE ‘%trash%’;
如果直接全部删除wp_commentmeta,影响不会太大,这里面不会涉及重要的数据
TRUNCATE TABLE wp_commentmeta
7. 总结
其实大部分无用的数据均在这几张表中,清理过后应该不会又太多的冗余数据了。但这里没有针对特殊插件或主题做数据库清理,有时这些插件和主题会悄悄动了一些数据库表,这样给清理带来很大难度,需要看代码才知道哦
二、数据库表优化
原理:数据库优化不
涉及数据的删除,是将数据库的表的状态调整好。在使用phpmyadmin时候,或许您会看到数据库表后面有多余xxMB的字样,这个指的是那些已经分配
给当前表但是却没有使用的空间。这个多余是没有什么害处的,他不会占用你的空间。当删除一个表的一部分记录时,这些记录仍然保持在一个linked
list 中,当插入新数据时会再次使用这些老纪录的位置。所以删除纪录会闲置一些空间造成你说的“多余”
优化:
(1)在phpmyadmin手动 优化或者修复表即可
(2)运行SQL:
OPTIMIZE TABLE wp_commentmeta;
OPTIMIZE TABLE wp_comments;
OPTIMIZE TABLE wp_links;
OPTIMIZE TABLE wp_options;
OPTIMIZE TABLE wp_postmeta;
OPTIMIZE TABLE wp_posts;
OPTIMIZE TABLE wp_terms;
OPTIMIZE TABLE wp_term_relationships;
OPTIMIZE TABLE wp_term_taxonomy;
OPTIMIZE TABLE wp_usermeta;
OPTIMIZE TABLE wp_users;
(3)插件:Optimize DB
我是使用SQL语句进行清理与优化的,附我的优化SQL语句(我的表前缀是wp1):
DELETE FROM wp1_posts WHERE NOT(post_status = ‘publish’ AND post_type IN(‘post’,'nav_menu_item’,’ page’));
DELETE FROM wp1_postmeta WHERE meta_key in (‘_edit_lock’,
‘_edit_last’, ‘_wp_old_slug’, ‘_revision-control’, ‘{{unknown}}’,
‘_wp_attached_file’, ‘_wp_attachment_metadata’);
DELETE FROM wp1_postmeta WHERE post_id NOT IN (SELECT id FROM wp1_posts);
DELETE FROM wp1_comments WHERE comment_approved like ‘%trash%’;
DELETE FROM wp1_commentmeta WHERE comment_id NOT IN (SELECT comment_id FROM wp1_comments);
OPTIMIZE TABLE wp1_commentmeta;
OPTIMIZE TABLE wp1_comments;
OPTIMIZE TABLE wp1_links;
OPTIMIZE TABLE wp1_options;
OPTIMIZE TABLE wp1_postmeta;
OPTIMIZE TABLE wp1_posts;
OPTIMIZE TABLE wp1_terms;
OPTIMIZE TABLE wp1_term_relationships;
OPTIMIZE TABLE wp1_term_taxonomy;
OPTIMIZE TABLE wp1_usermeta;
OPTIMIZE TABLE wp1_users;
程序需要频繁调用数据库,该如何优化
1、选取最适用的字段属性
MySQL可以很好的支持大数据量的存取,但是一般说来,数据库中的表越小,在它上面执行的查询也就会越快。因此,在创建表的时候,为了获得更好的性能,我们可以将表中字段的宽度设得尽可能小。
2、使用连接(JOIN)来代替子查询(Sub-Queries)
MySQL从4.1开始支持SQL的子查询。这个技术可以使用SELECT语句来创建一个单列的查询结果,然后把这个结果作为过滤条件用在另一个查询中。例如,我们要将客户基本信息表中没有任何订单的客户删除掉,就可以利用子查询先从销售信息表中将所有发出订单的客户ID取出来,然后将结果传递给主查询。
3、使用联合(UNION)来代替手动创建的临时表
MySQL从4.0的版本开始支持union查询,它可以把需要使用临时表的两条或更多的select查询合并的一个查询中。在客户端的查询会话结束的时候,临时表会被自动删除,从而保证数据库整齐、高效。使用union来创建查询的时候,我们只需要用UNION作为关键字把多个select语句连接起来就可以了,要注意的是所有select语句中的字段数目要想同。下面的例子就演示了一个使用UNION的查询。
4、事务
尽管我们可以使用子查询(Sub-Queries)、连接(JOIN)和联合(UNION)来创建各种各样的查询,但不是所有的数据库操作都可以只用一条或少数几条SQL语句就可以完成的。更多的时候是需要用到一系列的语句来完成某种工作。但是在这种情况下,当这个语句块中的某一条语句运行出错的时候,整个语句块的操作就会变得不确定起来。设想一下,要把某个数据同时插入两个相关联的表中,可能会出现这样的情况:第一个表中成功更新后,数据库突然出现意外状况,造成第二个表中的操作没有完成,这样,就会造成数据的不完整,甚至会破坏数据库中的数据。要避免这种情况,就应该使用事务,它的作用是:要么语句块中每条语句都操作成功,要么都失败。换句话说,就是可以保持数据库中数据的一致性和完整性。事物以BEGIN关键字开始,COMMIT关键字结束。在这之间的一条SQL操作失败,那么,ROLLBACK命令就可以把数据库恢复到BEGIN开始之前的状态。
5、锁定表
尽管事务是维护数据库完整性的一个非常好的方法,但却因为它的独占性,有时会影响数据库的性能,尤其是在很大的应用系统中。由于在事务执行的过程中,数据库将会被锁定,因此其它的用户请求只能暂时等待直到该事务结束。如果一个数据库系统只有少数几个用户来使用,事务造成的影响不会成为一个太大的问题;但假设有成千上万的用户同时访问一个数据库系统,例如访问一个电子商务网站,就会产生比较严重的响应延迟。其实,有些情况下我们可以通过锁定表的方法来获得更好的性能。
6、使用外键
锁定表的方法可以维护数据的完整性,但是它却不能保证数据的关联性。这个时候我们就可以使用外键。
7、使用索引
索引是提高数据库性能的常用方法,它可以令数据库服务器以比没有索引快得多的速度检索特定的行,尤其是在查询语句当中包含有MAX(),MIN()和ORDERBY这些命令的时候,性能提高更为明显。
希望可以帮到你,谢谢!
关于ZBLOG的优化
Z-Blog里面有三个插件是做搜索引擎优化(SEO)必不可少。
Google站点地图
Ping中心和引用通告发送器
标题搜索引擎优化
1、Z-Blog 默认模板里面是没有keywords,description等meta标签的。有很多的SEO文章说着两个都要加进去。但我的建议是Description就不要加了,这个容易出错。可以在\THEMES\xxxxxxxx\TEMPLATE目录下的找到single.html(xxxxxxx是你用的主题名称)。
在文件的title里加入如下代码:
meta name="Keywords" content="#article/tagtoname#"
2、于h1和h2的使用。 h1/h1在标准化里面的意义是表示标题,而并不是用来弄大小。Z-Blog里面用h1显示了网站名称,用h2显示副标题。但显然把这个h1留给文章的标题更加合适。你可以在同样的目录里找到single.html default.html catalog.html三个文件。
把其中的h1 换成h2,h2换成h3(记得前后都要换) 。
h1 id="BlogTitle"a href="#ZC_BLOG_HOST#"#ZC_BLOG_NAME#/a/h1
h2 id="BlogSubTitle"#ZC_BLOG_SUB_NAME#/h2
然后再把文章的标题用h1表示。在有的SEO文章里面,提到了文章标题用h1,但是没有指出文章标题的位置。准确的说,文章的标题并不在single.html里面,而是在目录内的b_article-single.html里面。找到它,把其中的h2换成h1,同样前后都要换。
h2 class="post-title"#article/title#/h2
我用ZBLOG建站后后台设置!主页能打开,但是文章打不开怎么解决?
zblog文章太多了吧,文章多查询数据库就会很卡,升级你的服务器,优化mysql以及php时间。
网站题目:zblog数据库调用优化 zblog缓存插件
网页链接:http://hbruida.cn/article/dogegcd.html