wordpress优化数据库(wordpress优化版)

本文目录：

• 1、wordpress百万级数据如何优化数据库
• 2、如何提高WordPress访问速度与性能的四大方法
• 3、wordpress 源代码中内嵌了一些无法访问的url拖累访问速度？
• 4、怎么清理优化wordpress数据库
• 5、Wordpress插件过多很臃肿，怎么优化
• 6、wordpress 数据库很大怎么解决

wordpress百万级数据如何优化数据库

MySQL是一个关系型数据库管理系统，由瑞典MySQL AB 公司开发，目前属于 Oracle 旗下产品。MySQL 是最流行的关系型数据库管理系统之一，在 WEB 应用方面，MySQL是最好的 RDBMS (Relational Database Management System，关系数据库管理系统) 应用软件。“总是在灾难发生后，才想起容灾的重要性。总是在吃过亏后，才记得曾经有人提醒过。”，所以此处列出一些MySQL的必要的优化和建议。

1. 核心类

♦ 不在数据库做计算，cpu计算务必移至业务层；

♦ 控制单表数据量，单表记录控制在千万级；

♦ 控制列数量，字段数控制在20以内；

♦ 平衡范式与冗余，为提高效率可以牺牲范式设计，冗余数据；

♦ 拒绝3B(big)，大sql，大事务，大批量；

2. 字段类

♦ 用好数值类型

tinyint(1Byte)

smallint(2Byte)

mediumint(3Byte)

int(4Byte)

bigint(8Byte)

bad case：int(1)/int(11)

♦ 有些字符转化为数字

例如：用int而不是char(15)存储ip

♦ 优先使用enum或set

例如：sex enum (‘F’, ‘M’)

♦ 避免使用NULL字段

NULL字段很难查询优化

NULL字段的索引需要额外空间

NULL字段的复合索引无效

bad case：

name char(32) default null

age int not null

good case：

age int not null default 0

♦ 不在数据库里存图片

3. 索引类

♦ 谨慎合理使用索引

改善查询、减慢更新

索引一定不是越多越好（能不加就不加，要加的一定得加）

覆盖记录条数过多不适合建索引，例如“性别”

♦ 字符字段必须建前缀索引

♦ 不在索引做列运算

bad case：

select id where age +1 = 10;

♦ innodb 主键合理使用自增列

主键建立聚簇索引

主键不应该被修改

字符串不应该做主键

如果不指定主键，innodb会使用唯一且非空值索引代替

♦ 不用外键，请由程序保证约束

4. sql类

♦ sql语句尽可能简单

一条sql只能在一个cpu运算

大语句拆小语句，减少锁时间

一条大sql可以堵死整个库

♦ 简单的事务

事务时间尽可能短

bad case：

上传图片事务

♦ 避免使用触发器，用户自定义函数，请由程序取而代之

♦ 不用select *

消耗cpu，io，内存，带宽

这种程序不具有扩展性

♦ OR改写为IN()

♦ OR改写为UNION

PS：最新的mysql内核已经进行了相关优化

♦ limit高效分页

limit越大，效率越低

select id from t limit 10000, 10;

应该改为 =

select id from t where id 10000 limit 10;

♦ 使用union all替代union，union有去重开销

♦ 尽量不用连接join

♦ 务必请使用“同类型”进行比较，否则可能全表扫面

♦ 打散批量更新

♦ 使用新能分析工具

show profile;

mysqlsla;

mysqldumpslow;

explain;

show slow log;

show processlist;

show query_response_time(percona)

如何提高WordPress访问速度与性能的四大方法

一、插件加速WordPress

主要是通过控制插件数量，配合使用页面缓存插件，以及数据库优化插件等结合。具体使用教程这里不详细说明，大家可以搜索相关教程即可。

二、主题优化加速WordPress

1.主题代码加速：

代码决定了WordPress加载的速度，浏览你博客的速度在很大程度上是这个因素决定的（在同样的网络环境下），用户加载网页的时间有80%花在这上面。要想你的WordPress飞速跑起来，代码层次的优化是非常必要的。其实，压缩CSS和JS也是非常简单的事情，真的，不是你想象中的那么难。压缩CSS，推荐使用styleneat.com，操作方式非常简单，但是却能带来很大的速度提升。

推荐方法是：把CSS放在开头，把JS放在结尾 ；用Gzip压缩网页，WP CSS插件也可以实现这一功能；不要把CSS和js直接写入网页中，应加载外部；去除JS和CSS中的冗余，最好把JS文件放在主题的footer.php里，在CSS和JS的优化上，CSS要首先载入，JS要最后载入；外部调用调用Google Code里面的大型框架 – Ajax Libraries API。对这些框架的载入，让Google的服务去承担:) 常用的有:

jQuery

prototype

script.aculo.us

MooTools

dojo

调用方法就不必介绍了吧。

2.主题图片优化：

优化图片的好处是显而易见的，首先减少HTTP请求数，可以节省大量的带宽资源，这是代码优化中很基础也很重要的一个环节，其次，图片优化，可以大大提供博客整体的载入速度。而一个网页中的所使用到的图片（诸如小图标之类的）往往占有很大部分的HTTP请求，所以将这些图片合并成一张大的背景图时，不但可以减少图片整体的大小外，最重要的还是可以减少HTTP请求数。

相关方法就是利用CSS SCRIPT技术和一些图片压缩优化的方法来实现。

图片压缩建议使用，smush.it。

3.删除冗余的主题函数：

WordPress主题函数很多，每个函数也都有自己的作用，但是在一些时候，我们可以不使用函数，而直接使用具体的链接地址，这样就避免了函数对数据库的操作，从而提高了WordPress主题整体的载入速度。

三、数据库优化加速WordPress

优化和修复你的数据库

你应该定时(每周或每半个月)登录一下你的phpmyadmin，然后对你的各个WordPress表进行优化和修复，很简单，你只需要选中这些表，然后进行”Optimize table”和”Repair table”即可。(如果要慎重起见，你最好还是同时备份一下你的数据库。安全和性能同时抓，何乐而不为？)

或者使用插件优化数据库：目前公认最好的数据库优化插件是：Optimize DB

四、其他方法加速WordPress：

1.使用可靠的图片托管服务

尽可能将文章中的图片保存到其他地方，如Google Picasa、Flickr等。而不是上传到你的服务器上。这样做可以使Web服务器减少很多平均CPU负载/存储要求。

2.服务器层次加速WordPress

置换更好的主机，部分博友有自己的服务器或者VPS，可以针对VPS或者独立服务器的。使用轻量级、高性能的Nginx，PHP字节码缓存组件apc

3.为网页静态元素设置过期时间（以Nginx为例），以及增加Etags等。

4.关闭日志修订记录功能

禁用并删除 WordPress 文章修订记录，或者定期用Delete-Revision插件清理。

wordpress 源代码中内嵌了一些无法访问的url拖累访问速度？

wordpress必装插件，wordpress网站装好了之后，为了更好的优化网站少不了安装插件优化。今天给大家推荐wordpress必装插件以及工具。只需输入域名选择wordpress主题或模板（内置90000套主题模板选择）。一个网站就这样搭建完成。软件上还覆盖各种主题功能以及全套SEO插件。等下会以图片的形式给大家展示。大家注意看图。一键建站+行业内容采集+伪原创+主动推送给搜索引擎收录。

网站地图，又称站点地图，它就是一个页面，上面放置了网站上需求搜索引擎抓取的一切页面的链接（注：不是一切页面）。大多数人在网站上找不到本人所需求的信息时，可能会将网站地图作为一种弥补措施。搜索引擎蜘蛛十分喜欢网站地图。

制作网站地图的工具十分多，如sitemapX，其他软件功用大同小异。网站地图放置在网站的根目录，有一份或者多份，只要一份的状况是页面比较少，网站地图文件较小，蜘蛛读取速度快，反之蜘蛛读取速度慢，所以分开多个文件放置，不由于读取问题影响权重。另外，robots协议文件控制搜索引擎抓取范围、时间频率等，所以应该把网站地图放在robots的最后面，先恪守robots抓取范围。

出现404错误是在网站页面被收录了之后，后面又被删除，在搜索引擎再次点击即出现404错误。这对用户体验来说是相当糟糕的，但404错误又是无法避免的，中小型网站页面数量不会很多，但是大型门户网站，论坛等，数量就多了。404在seo优化中，尤其是在跳出率和PV上，起到关键作用。

什么是404错误

先看看seo名词解释：HTTP 404或Not Found错误信息是HTTP的其中一种“标准回应信息”（HTTP状态码），此信息代表客户端在浏览网页时，服务器无法正常提供信息，或是服务器无法回应且不知原因。

出现404错误的影响

自定义404错误页面是增强用户体验的很好的做法，但在应用过程中往往并未注意到对搜索引擎的影响。 搜索引擎蜘蛛在请求某个URL时得到“404”状态回应时，即知道该URL已经失效，便不再索引该网页，并向数据中心反馈将该URL表示的网页从索引数据库中删除，删除过程有可能需要很长时间；

搜索引擎得到“200”状态码时，则会认为该url是有效的，便会去索引，并会将其收录到索引数据库，结果是这两个不同的url具有完全相同的内容，搜索赢球认为这是复制的网页。轻则被搜索引擎降权，重则会K掉网站。静态页面为路径的网站，在优化和删除某些后台编辑的文章时，一定要把网站的生成静态页面（完整路径的页面）删除，同时向百度进行死链提交。

这里要提到特殊的tag功能，dedecms能按照文章关键字自动生成tag标签。如果tag标签也被收录，而你删除了某些tag标签，都会弹出“dedecms提示：该标签已删除”的错误页面，会产生非常多重复且低质量的页面。由于不是返回404，无法通过提交404错误，删除这些快照。如果你有大量的tag标签页被收录，404页面的设置方法很多，以万网虚拟机为例，Apache下设置404错误页面。方法很简单，只需在.htaccess 文件中加入如下内容即可：ErrorDocument 404 /notfound.php。也可在万网空间设置里面设置404页面，只要选好404模板。

制作死链文件筛查网站内部存在的死链，并将这些死链页面设置成为404页面，即百度访问它们时返回404代码。将需提交的死链列表制作成一个死链文件，制作方法请参阅百度错误页面提交帮助文档（与sitemap格式及制作方法一致）

怎么清理优化wordpress数据库

一、数据库表清理

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;

WordPress插件过多很臃肿，怎么优化

缓存就指很多方便了，比如 CDN 缓存、静态缓存、数据库缓存、浏览器缓存等等。

1、CDN 缓存：CDN 的话最好是备案了再起飞，因为大多数没备案的 CDN 都是给美国节点，而很多人是香港服务器，那岂不是绕着太平洋跑？另外，CDN 需要正确的配置（写缓存规则）才能够达到最好的效果。

2、静态数据库缓存：这个呢就不做推荐了，各有各的优点，自己比较效果吧。

3、浏览器缓存：这里呢说一下，如果长期更新浏览器缓存不要搞太久，很多人在百度云加速设置个一年什么的。Service Worker 的话可以试试，离线打开是不是很装逼呢

精简是重要的

很多优秀的主题包含了很多不必要的功能，这时候就需要适当的精简，毕竟只有骨骼轻才可以飞。

插件的话能用纯代码就用纯代码，插件什么的卡死了。

压缩合并让请求更快

一些 CSS/JS 文件要适当的压缩合并，减少请求数，因为在 HTTP/1.1中每个文件都要握手。

Gzip 的话是有必要开的，大家也知道打包文件更小吧。

动静分离让静态资源国内加载

如果你是国外主机的话，这个方法十分管用，可以把图片、CSS、JS文件等托管到国内，不过如果有了 HTTP/2 的话建议不要搞，因为又要与一个域名握手了。

HTTP/2 SPDY 大法好

HTTP/2 压缩了请求头，而且合并了请求，也就是说全站两个域名只需两次请求。

SPDY 的话是谷歌的一个项目，本身是为了加快 HTTP，不过现在的 HTTP/2 已经包含了其大部分功能，谷歌也要放弃该项目了

支持 HTTP/2 的 CDN有CloudFlare、腾讯云、又拍云、上海云盾、360网站卫士、魔门云（非联盟已回源，备案无国内，只有一两个节点，巨坑！）等等。

InstantClick 预加载

这个之前提到过，InstantClick 当访客鼠标悬浮在 a 链接时，InstantClick 会异步请求这个页面，当访客点击时，便瞬间切页，有木有飞起？不过这玩意会扯出一大堆 Bug，像统计、高亮什么的都需要重载，萌新就别弄了，国内估计也就泽泽大佬的 Yodu 模板自带了，至于 WordPress 还没见过，主题作者也不想撤扯出一大堆问题让用户天天问吧。

定时清理 WordPress 的垃圾

经常听一群人说清电脑辣鸡，windows 有垃圾，WordPress 当然也有，例如自动草稿这样的肯定是不要的东西，这里呢推荐 WP Clean Up 插件，国人写的。

希望可以帮助到你，望采纳！

wordpress 数据库很大怎么解决

登陆PHPMYADMIN执行以下三条命令。将删除WORDPRESS所有自动修定和自动保存的操作。

DELETE FROM wp_postmeta WHERE post_id IN(SELECT id FROM wp_posts WHERE post_type=’revision’);

DELETE FROM wp_term_relationships WHERE object_id IN(SELECT id FROM wp_posts WHERE post_type=’revision’);

DELETE FROM wp_posts WHERE post_type=’revision’;

【wordpress优化数据库】的内容来源于互联网，如引用不当，请联系我们修改。