让客户满意是我们工作的目标,不断超越客户的期望值来自于我们对这个行业的热爱。我们立志把好的技术通过有效、简单的方式提供给客户,将通过不懈努力成为客户在信息化领域值得信任、有价值的长期合作伙伴,公司提供的服务项目有:域名注册、网络空间、营销软件、网站建设、乐业网站维护、网站推广。
我们一起看看wordpress数据库中的wp_options表。当涉及到整体WordPress和数据库性能时,这是一个经常被忽视的领域。尤其是在较旧的大型网站上,由于第三方插件和主题留下的自动加载数据,这可能是导致网站查询时间变慢的罪魁祸首。查看以下有关如何检查、排除故障和清理wp_options表的提示。
wp_options表中包含的各种资料为你的WordPress网站,如:
wp_options表
该表包含以下字段,我们在性能方面更关心其中一个字段:
wp_options表自动加载
了解wp_options表的重要事项之一是autoload字段。这包含是或否值(标志)。这基本上控制它是否由wp_load_alloptions() 函数加载。自动加载的数据是在WordPress网站的每个页面上加载的数据。就像我们向您展示了如何禁止某些脚本在站点范围内加载一样,同样的想法在这里也适用。默认情况下,开发人员的自动加载属性设置为“yes”,但并非每个插件理论上都应该在每个页面上加载他们的数据。
WordPress网站可能遇到的问题是wp_options表中有大量自动加载的数据。这通常是以下原因造成的:
太多自动加载的数据是多少?这当然可以变化,但理想情况下,您希望它在300KB 到1MB之间。一旦开始接近3-5MB 范围或更多,很可能可以优化或删除自动加载的内容。任何超过10MB 的内容都应该立即解决。这并不总是意味着它会导致问题,但这是一个很好的起点。
如果您的WordPress网站运行缓慢,可能是由于旧WordPress插件遗留的查询或自动加载数据。下面我们将向您展示如何检查数据库中自动加载的大小,以及深入了解实时站点的数据并分享我们为清理它所做的工作。
首先要做的是检查WordPress网站上当前自动加载的大小。为此,请登录到phpMyAdmin。单击左侧的数据库,然后单击SQL选项卡。然后输入以下命令并点击“Go”。
SELECT SUM(LENGTH(option_value)) as autoload_size FROM wp_options WHERE autoload='yes';
如果您的WordPress站点使用wp_ 以外的其他前缀,您可能需要调整上面的查询。
phpMyAdmin中的自动加载大小查询
autoload_size将以字节为单位返回。KB中有1024字节,MB中有1024KB。所以在我们的例子中,249,025字节等于0.25MB。所以对于这个网站,这是一个很好的尺寸!如果您返回低于1MB的任何内容,您不必担心。但是,如果结果要大得多,请继续本教程。
自动加载大小
下面是我们正在测试的站点,其中返回了137,724,715个字节,或者更确切地说是137MB。这是一个网站肯定有问题的一个很好的例子,或者说有一些事情需要优化。
wp_options表中的大型自动加载数据
您还可以使用更长的查询,如下所示。这将显示自动加载的数据大小、表中有多少条目以及按大小排列的前10个条目。
SELECT 'autoloaded data in KiB' as name, ROUND(SUM(LENGTH(option_value))/ 1024) as value FROM wp_options WHERE autoload='yes' UNION SELECT 'autoloaded data count', count(*) FROM wp_options WHERE autoload='yes' UNION (SELECT option_name, length(option_value) FROM wp_options WHERE autoload='yes' ORDER BY length(option_value) DESC LIMIT 10)
高级自动加载数据MySQL查询
如果您有权访问New Relic,您还可以使用它来帮助解决连接到wp_options表的查询。数据库选项卡将指出消耗最多时间的表和查询类型。如果您选择列表中的条目之一,您可以看到更多详细信息,包括一些示例查询。在下面的这个示例中,您可以看到数据指向wp_options表中自动加载的数据。果然,对该站点的快速分析证实了近250MB的自动加载数据。
New Relic慢查询 – wp_options表
下一步是使用自动加载的数据快速排序顶部项目。这是一个可以用来列出前10名的快速SQL命令:
SELECT option_name, length(option_value) AS option_value_length FROM wp_options WHERE autoload='yes' ORDER BY option_value_length DESC LIMIT 10;
同样,如果您的WordPress站点使用wp_ 以外的其他前缀,您可能需要调整上面的查询。
wp_options表中自动加载的顶部数据
下一步是挖掘一些最重要的自动加载数据。
301重定向
正如我们在上面看到的,顶部的自动加载选项是301_redirects。这可能与站点上的重定向插件或WordPress SEO插件直接相关,该插件也具有重定向功能。在这种情况下,最好的建议是在服务器级别实际实施重定向。
为什么?因为使用免费的WordPress插件来实现重定向有时会导致性能问题,因为它们中的大多数使用wp_redirect函数,这需要额外的代码执行和资源。当然,它还自动将数据加载到wp_options表中。
如果您是宝塔面板,您可以使用我们的301重定向配置在服务器级别轻松添加重定向。这不仅提高了性能,而且您可能少了一个插件需要担心!
登入您的宝塔面板,点击网站菜单,找到你需要配置301重定向的网站,点击“设置”操作项:
宝塔面板网站管理
然后在弹出窗口中,选择301重定向,选择重定向类型为路径,然后再设置源地址及重定向URL即可。(注:不同宝塔面板,界面可能有出入)
在宝塔面板中添加重定向规则
wpurp_custom_template_
下一个自动加载数据选项是wpurp_custom_template_#。我们可以看到有很多不同的行。通常,您应该能够通过查看您的主题或插件文件夹来找到此选项名称并连接点。在这种情况下,我们从服务器执行了grep命令以查看是否可以找到它。您也可以通过SFTP进行抽查。
grep -Ri "wpurp_custom_template_"
但是,上面的命令没有返回任何内容,因此我们转到 Google 并进行了搜索。我们很快发现它与网站上不再安装的WordPress插件有关,称为WP Ultimate Recipe。这是留下不必要的自动加载数据的经典示例。我们有一个关于如何卸载WordPress插件(正确方法)的冗长教程。适当的,我们的意思是实际清理留下的东西。
wpurp_custom_template_
um_cache_userdata_
下一个自动加载数据选项是um_cache_userdata_#。我们可以看到有很多不同的行。由于这是在底部,我们快速修改了我们的MySQL命令以显示前40个自动加载的数据:
SELECT option_name, length(option_value) AS option_value_length FROM wp_options WHERE autoload='yes' ORDER BY option_value_length DESC LIMIT 40;
或者将所有具有该前缀的值相加:
SELECT 'sum size in KiB', ROUND(SUM(length(option_value))/1024,0) FROM wp_options WHERE autoload='yes' AND option_name like "um_cache_userdata_%"
我们可以看到 wp_options 表中有更多的um_cache_userdata_#条目。我们再次运行grep命令来检查我们的插件和主题文件夹。
grep -Ri "um_cache_userdata_"
然后我们能够快速确定这与Ultimate Member插件有关。另一个快速的Google搜索返回了针对此问题的一些很好的解决方案(请参阅支持文章)。永远不要低估Google搜索的力量!事实证明,插件中有几个不同的选项可以解决这个问题。
查看自动加载选项的另一个选项是点击编辑按钮,这可以列出插件/主题的目录,或列出开发人员的网站。
定时任务
我们在大量自动加载数据中看到的另一个常见选项是cron。为此,它可以是任何与cron相关的东西。所以你可以做的是点击“edit”按钮,看看是什么导致了它。下面是一个示例,其中很明显是“do_pings”导致了问题。再次,快速的谷歌搜索揭示了清理 do_pings的快速修复。
cron – do_pings
如果您看到很多我们上面提到的内容,那么可能是时候清理 wp_options 表中所有自动加载的数据了。还建议您尝试将wp_options表上的行数保持在最低限度。在删除数据库中的数据之前,请始终进行备份。
就像我们之前所做的那样,您需要登录到phpMyAdmin。单击左侧的数据库,然后单击SQL选项卡。然后输入以下命令并点击“Go”。
SELECT * FROM `wp_options` WHERE `autoload` = 'yes'
如果您的WordPress站点使用wp_ 以外的其他前缀,您可能需要调整上面的查询。这将显示wp_options表中设置为自动加载的所有数据。
在wp_options中查找自动加载的数据
向下滚动行,我们会看到网站不再安装或使用的各种插件。这只是我们将要使用的一个示例,但在这种情况下,我们注意到了一堆Jetpack行。Jetpack不再在相关网站上使用。
旧的自动加载数据
检查插件开发人员的文档总是好的,因为有时他们可以选择清理遗留的表格。在这种情况下,有时只需再次安装插件,检查其自动清理选项,然后正确删除插件,会更安全、更容易。但是,我们将向您展示如何手动清理表。
因此,在这种情况下,我们运行以下查询以从Jetpack插件的wp_options表中查找自动加载的数据。要使用您自己的查询修改查询,只需替换 %jetpack%。
SELECT * FROM `wp_options` WHERE `autoload` = 'yes' AND `option_name` LIKE '%jetpack%'
然后,您可以选择所有行并单击“删除”。
删除自动加载的表
或者您可以运行以下命令:
DELETE FROM `wp_options` WHERE `autoload` = 'yes' AND `option_name` LIKE '%jetpack%'
删除wp_options表中自动加载的数据
然后,您可以清洗并重复wp_options表中插件和主题留下的其他自动加载数据。
除非您使用对象缓存,否则WordPress会在wp_options表中存储临时记录。通常这些都有一个过期时间,应该会随着时间的推移而消失。然而,情况并非总是如此。我们已经看到一些数据库中有数千条旧的临时记录。同样重要的是要注意瞬态默认情况下不会自动加载。您可以使用如下查询来查看是否有任何自动加载的瞬态数据。
SELECT * FROM `wp_options` WHERE `autoload` = 'yes' AND `option_name` LIKE '%transient%'
然而,更好、更安全的选择是使用像Transient Cleaner这样的免费插件,它只能从wp_options表中清除过期的瞬态。
我们看到的另一个常见问题是有时cron作业不同步或不能正确触发,因此会话没有得到清理。您可能会_wp_session_
在数据库中获得大量行。在下面的示例中,所讨论的站点在其 wp_options
表中有超过300万行。表的大小已经超过了600MB。
具有数百万行的wp_options表
您可以使用如下所示的查询来查看您是否遇到此问题:
SELECT * FROM `wp_options` WHERE `option_name` LIKE '_wp_session_%'
_wp_session_ 行
在大多数情况下,您可以使用以下命令安全地删除这些(作为cron作业应该具有的):
DELETE FROM `wp_options` WHERE `option_name` LIKE '_wp_session_%'
清理完所有剩余_wp_session_ rows
的表后,该表只有不到1,000行,大小减少到11MB。
WP会话已清理
它还修复了站点在MySQL中出现的峰值。
MySQL网络事务
如果清理wp_options表还不够,您可以尝试向自动加载字段添加“index”。这基本上可以帮助它更有效地搜索。10up的出色团队在wp_options表上执行了一些测试场景,其中包含典型的自动加载记录数,以展示向wp_options查询添加自动加载索引如何提高性能。
wp_options查询时间 (Img src: 10up )
我们还建议您从WP Bullet查看这两个额外的资源:
有关更多优化技巧,请确保您查看我们的深入指南: 如何加速您的WordPress网站(终极指南)
网页标题:如何清理wp_options表和自动加载的数据
网页链接:http://www.shufengxianlan.com/qtweb/news28/144778.html
网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联