最近一直在整理网站的代码，试图加快网站的速度，主要是从代码、软件和网络方面，都是从网站切换到 HTTPS 开始的。
已经连续观察 CDN 多天了，现在是检查缺口和陷阱的时候了。目前也把整个网站备份到另一个服务器，把网站解析到这个服务器本地，开始查代码。调试已打开，一些大问题已得到处理。然后对主题的代码进行了整理，网站还增加了 Redis 缓存。然而，仙森发现，即使使用 Redis，有时打开和生成一个网页也需要一秒多的时间。很不解，一直想弄清楚是什么情况。
故障排除工具
很久以前，在主题 footer.php 的末尾添加了以下代码，这样登录后就可以看到当前网页的查询次数和生成时间:
这个代码网络无处不在，相信很多人都添加了。在网站加入 Redis 之前，网页查询次数为 150+次，生成时间为 2-3 秒甚至更长。用了之后减少到 50+次，但有时候还是要 1 秒多，犯难了。
然后对所有优化后的主题代码进行优化后，查询次数为 30+次，生成时间减少到 1 秒左右，但是还是不满意，所以想看看执行了哪些查询，然后在网上找到了这段代码，和上面的有点类似。
首先，您需要添加代码，将查询保存在 WordPress 的根配置文件 wp-config.php 中:
define('SAVEQUERIES', true);
然后也是在 footer.php 的网页最后部分添加打印代码：
但是添加后看了一下，差点当场去世，这样打印出来的是一个很大的多维数组，看的人眼花缭乱，重点是太长了还显示不全。先将打印复制出来，拿到 NotePad++里面打开，依旧显得很乱。
但是，简单看一下，大数组的每个键值代表一个查询，然后出现一个查询数组。第一个值是执行的 SQL，第二个值是使用的时间，第三个值是调用代码的位置。其实我们可以做一个带循环的格子，让前端显示看起来更方便，但是比较懒。在线检查后，有一些插件可以在不修改 wp-config.php 的情况下执行相关功能，即调试查询。所以仙森懒得自己写，就装了一个来排除故障。
需要注意的是，Debug Queries 已经很久没有更新了，安装可能会报错，但仍然可以正常使用。其实 Debug query 的介绍页面也推荐使用 Debug Objects 插件，但是先试了 Debug query 之后，就懒得再试别的插件了。
疑难解答问题
当工具准备好了，就会来找出查询到底慢在哪里。
插件安装好之后，看打印出来的查询信息会更清晰。森先比较了一下。大部分的查询都是 0.00x 秒，也就是几毫秒，但只要涉及到 wp _ al _ urls 的查询，就会是瞬间甚至几百毫秒。
Wp _ al _ urls 查询-2
wp _ al _ urls 的查询
看了一下。这个表属于插件 anylink。这个插件主要是把网站上所有的外链转换成内链。单击后，您可以跳转到外部链。
对于 anylink，也在这里发了两篇相关文章:
WordPress 为 anylink 插件的跳转添加了一个漂亮的跳转页面。
WPJAM BASIC 插件与任何链接冲突
这个插件从网站建起就一直在用。这是一个非常有用的插件，但是我没想到这个插件的查询速度会很慢。
从上面的
截图
可以看到，wp _ al _ urls 的查询条件是网站链接。看看数据库。这个 SQL 是为了得到内链的 slug 记录:
Anylink 获得 slug -3
任何链接都会被删除
我在这里查找的其实是网页主体中的外部链接，以及每个评论老板的网址对应的内部链接地址。
看了一下表，没想到是 10M 大小，接近 10 万条数据，这里查询的是 al _ origURL 字段。看了一下，这个字段没有索引。
解决问题
对于 MySQL 查询，能想到的优化方法就是添加索引，所以仙森直接操作添加索引，但是报错了:
索引 al _ origURL 字段时出现错误-4
索引 al _ origURL 字段时出错
错误报告与字段的格式有关。看看这个字段的类型，它是 mediumtext。此字段用于存储网址。有些网址很长。如果是 varchar，可能会有问题。varchar 长度为 255 个字符。我在网上搜索了一段时间的解决方案，所有这些都意味着与文本相关的类型无法索引。对数据库索引了解不多，只好放弃这条路。
能想到的第一种方法是查看这个查询的代码，并找到一种方法将结果保存到 Redis 进行缓存。至于如何找到实际执行的代码，先看了一下，直接找调用的最后一段就行了。
如您所见，这两个 SQL 实际上是相同的。他们在查找同一个 URL，但是结果的执行时间实际上更长，所以我们真的要缓存结果。
为了优化代码，仙森在 PhpStorm 中将整个网站作为一个项目，不得不说一个好的 IDE 工具写代码真的很舒服。直接全局搜索，寻找 get_slug_by_url 的函数，成功找到代码。
搜索 get_slug_by_url 函数-6
搜索 get_slug_by_url 函数
这里有两个结果。第一个是原函数，已经被仙森注释了，第二个是仙森修改后的。
可以看到，这个函数是调用$wpdb 来执行 SQL 语句并返回结果。功能比较简单，先修改一下也有好处。
然后仙森发现 WordPress 是怎么增加缓存的，发现很简单。
WordPress 操作缓存
WordPress 为我们提供了使用对象缓存的功能，方便我们使用对象缓存。
Wp_cache_add():将数据添加到缓存中，如果数据已经存在，则返回 flase。
Wp_cache_set():将数据添加到缓存中，如果数据已经存在，缓存将覆盖该数据。
Wp_cache_get():获取缓存中的数据，如果数据不存在则返回 false。
Wp_cache_delete():从缓存中删除数据
Wp_cache_replace():替换缓存中的数据，类似于 wp_cache_set，但如果数据不存在，则不会自动添加。
Wp_cache_flush():清除所有缓存
如果没有安装redis缓存插件，则上述功能都在。/WP-includes/cache.php .如果安装了 Redis Object Cache 等插件，会自动添加一个/wp-content/object-cache.php 文件，这些函数也会存在于这个文件中存储在缓存中。
对象缓存使用示例
$result = wp_cache_get( 'my_result' );
if ( false === $result ) {
$result = $wpdb->get_results( $query );
wp_cache_set( 'my_result', $result );
}
对 anylink 的 get_slug_by_url 函数改造
any link get _ slug _ by _ URL 函数的转换
有了上面的情况，为 anylink 功能添加缓存就非常方便了。这个例子非常简单，get_slug_by_url 函数本身也很简单，所以转换如下:
public function get_slug_by_url( $url ) {
$arr_slug = wp_cache_get( $url );
if ( false === $arr_slug ) {
global $wpdb;
$arr_slug = array();
$arr_slug = $wpdb->get_row($wpdb->prepare(
"SELECT *
FROM " . ANYLNK_DBTB . "
WHERE al_origURL = %s",
$url
), ARRAY_A);
wp_cache_set( $url, $arr_slug );
}
return $arr_slug;
}
因为示例和函数非常匹配，所以该函数与示例结构几乎相同。首先，去 Redis 获取缓存的数据。如果拿不到，就去 MySQL 查询，然后保存到 Redis。
提示:Redis 最好不要使用默认端口 6379，除非安全性非常好。
使用 Redis 时要注意以下几点:
1.请务必配置强密码；
2.安全组和防火墙必须在最小范围内让 Redis 端口通过，即让通过访问指定的 IP；
3.尽量不要使用默认端口。
由于 Redis 的存在，仙森经常会遇到服务器中的木马病毒防护。
摘要
一开始觉得给 WordPress 加 Redis 很麻烦。在实践中，他发现它真的很香。他建议所有有能力的朋友都去看看。毕竟，生命是无穷无尽的。本文最重要的是记录慢网页查询的过程和解决方法，希望能为其他朋友提供思路。
转载请注明：汇站网 » WordPress 优化：为 anylink 插件增加缓存
