标签：mysql

先森最近在梳理网站的代码，想办法为网站加速，主要从代码、软件、网络层面进行优化，这一切都是从网站切换到HTTPS开始的。先森已经连续观察了多日的CDN了，目前也就到了查缺补漏的阶段了。先森还将整个网站目前备份到了另一台服务器，将网站在本地解析到这台服务器上，开始了对代码的检查。开启了debug，把大的一些问题都处理了，然后也把主题的代码理了一遍，并且网站也加上了Redis缓存。但是先森发现，即使加上了Redis，有时候网页打开生成时间还是得一秒多，先森就很纳闷，一直想搞明白到底是什么情况。排查工具很早以前，先森就在主题的footer.php末尾，添加了下面的代码，以便于登录之后可以看到当前网页的查询次数，生成时间：<?php if (is_user_logged_in()){    echo "<pre>".get_num_queries().'次查询，用时';    timer_stop(3);    echo '秒</pre>';?>这个代码网络上到处都是，相信很多人都添加的有。先森网站加Redis之前，网页的查询次数都是150+次，生成时间2-3秒，甚至更多。用上之后减少到50+次，但是有时还是会需要1秒多，让先森百思不得其解。然后先森把主题代码该优化的都优化后，查询次数30+次，生成时间降到1秒左右，但是先森还是不太满足，所以想看看到底是执行了哪些查询，然后就在网上找到了这段代码，和上面的有些类似。首先需要先在WordPress的根目录配置文件wp-config.php中添加保存查询的代码：define('SAVEQUERIES', true);然后也是在footer.php的网页最后部分添加打印代码：<?phpif (current_user_can('administrator')){    global $wpdb;    echo "<pre>";    print_r($wpdb->queries);    echo "</pre>";}?>但是先森添加后看了一下，差点当场去世，这样打印出来的是一个很大的多维数组，看的人眼花缭乱，重点是太长了还显示不全。先森将打印复制出来，拿到NotePad++里面打开，依旧显得很乱。查询的打印不过大概看了一下，大数组的每一个键值表示一个查询，然后一个查询数组了，第一个值是执行的SQL，第二个值是使用的时间，第三个值是调用的代码位置。其实可以用循环做一个网格，让前端显示看着方便一点，但是先森很懒，网上看了一下，有插件可以做到相关功能，且不用修改wp-config.php，即Debug Queries，所以先森就懒得自己写了，直接装了一个来进行排查。需要注意的是，Debug Queries很久没有更新了，安装可能会报错，不过还是可以正常使用的。其实Debug Queries介绍页也推荐使用Debug Objects插件，但是先森试了一下Debug Queries可以用，也就懒得再试另一个插件了。排查问题工具准备好了，先森就来好好排查到底是哪里查询比较慢了。插件装好了，再去看打印出来的查询信息，就比较清晰了。先森对比了一下，大部分的查询都是0.00x秒的，就是几毫秒的，但是只要涉及到wp_al_urls的查询，就会是即时甚至上百毫秒。wp_al_urls的查询先森看了一下，这个表是插件anylink的，这个插件主要是将网站上的外链全都转化成内链，点击后可以跳转到外链。对于anylink，先森这里也发过两篇相关的文章：WordPress为anylink插件外链跳转添加漂亮的跳转页面WordPress：WPJAM BASIC插件与anylink冲突这个插件先森也是从建站伊始就在用了，是一个很好用的插件，但没有想到这个插件会出现慢查询。通过上面的截图可以看到，对wp_al_urls的查询条件是网站链接，看了一下数据库，这个SQL是为了去拿到内链的slug记录：anylink获取slug这里去查的，实际上是网页正文里的外链、各位评论大佬的网址对应的内链地址。先森看了一下这个表，没想到竟然有10M的大小，接近10万条数据，而且这里查询的是al_origURL字段，先森看了一下，这个字段是没有索引的。解决问题对于MySQL的查询，先森能想到的优化方法就是加索引，所以先森直接就操作加索引，但是报错了：给al_origURL字段加索引报错看报错是跟字段格式有关的，看了一下这个字段的类型是mediumtext的，这个字段是存URL的，有些URL非常的长，如果该varchar的话，可能会出问题，varchar最长255个字符。网上找了一阵子解决方案，都是说text相关的类型无法加索引。先森本来就对数据库索引什么的不太了解，所以只能放弃这条路。先森还能想到的办法，就是看下这个查询的代码，想办法把结果存到Redis上缓存起来。至于怎么找到实际执行的代码，先森看了一下，直接找调用的最后一段就可以了。找到慢查询的调用代码可以看到，两个SQL实际上是一样的，查的是同个网址，结果执行的时间竟然都比较长，所以确实得把结果缓存起来。为了优化代码，先森把整个网站都作为了一个PhpStorm里的一个项目，不得不说一个好的IDE工具写起代码来是真的舒服。直接全局搜索，寻找get_slug_by_url这个函数，顺利找到了代码所在。搜索get_slug_by_url函数这里有两个结果，第一个是原本的函数，已经被先森注释起来了，第二个是先森改了之后的。可以看到这个函数就是调用$wpdb来执行SQL语句，将得到的结果再返回一下。函数比较简单，也很利于先森修改。然后先森又找了一下WordPress如何添加缓存，结果找到一下，发现非常简单。WordPress操作缓存WordPress 为我们提供了使用对象缓存的函数，方便我们使用对象缓存。wp_cache_add() ：添加数据到缓存中，如果数据已存在，返回 flasewp_cache_set() ：添加数据到缓存中，如果数据已存在，会覆盖数据wp_cache_get() ：获取缓存中的数据，如果数据不存在，返回 falsewp_cache_delete() ： 从缓存中删除数据wp_cache_replace() ：替换缓存中的数据，类似 wp_cache_set，但是如果数据不存在，不自动添加wp_cache_flush()：清除所有缓存如果没有装redis缓存插件，上面的这些函数是在./wp-includes/cache.php里。如果装了Redis Object Cache等插件，就会自动增加一个./wp-content/object-cache.php文件，这些函数也会存在于这个文件中，用于存入缓存。WordPress 对象缓存使用使用示例$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函数改造有了上面这个案例，先森为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。2022年4月4日更新：此代码存在亿点点bug，修复参考此文章：修复anylink增加Redis缓存后存在的bug检查效果代码修改后，同步到测试服务器，访问了两次之前访问的页面，查询次数和用时都降下来了。然后看到查询次数还是有33次，其中有部分是查询wp_al_urls_index这个表的，虽然速度不慢，但是次数比较多，先森重复上面的方法也修改了一下相关函数，最终效果如下图：最终效果查看Redis的keys上面改造的代码中，是拿url地址去做的key名称，那么先森也来看下缓存数据在Redis里的情况：redis的缓存上面改造的代码比较简陋，直接拿的URL做的key名称，如果URL比较短还好，如果长的话就可能出现问题，key名称其实可以做一下长度限制。提示：Redis最好不要使用默认端口6379，除非安全做的非常好。使用Redis时注意以下几点：1、一定要配置强密码；2、安全组、防火墙一定要最小范围放通Redis端口，即针对指定IP放通访问；3、尽量不要使用默认端口。因为Redis而导致服务器中木马病毒的保障，先森这边经常遇到。总结先森以前以为给WordPress配上Redis很麻烦，实际使用发现真香，建议有能力的朋友都上一下，毕竟生命不止，折腾不息。本文最主要的还是记录一下排查网页查询慢的过程和解决方法，希望能够给其他朋友提供思路。

一个网站，甚至一个业务，数据库都是防护的重中之重，如果MySQL存在匿名用户，那么危险可想而知。先森在这里做个记录，查找和删除匿名用户的SQL，其实变换一下也可以查无密码用户。查看匿名用户SQL很简单，最简单的查：mysql> select host,user from mysql.user where user='';通常mysql会默认有两个匿名用户，如果在安装MySQL的时候没有特殊措施，那么一般都存在如下结果：匿名用户删除匿名用户删除的SQL也很简单，只是没有查询那么常用：mysql> delete from mysql.user where user='';