先森最近在梳理網(wǎng)站的代碼，想辦法為網(wǎng)站加速，主要從代碼、軟件、網(wǎng)絡(luò)層面進(jìn)行優(yōu)化，這一切都是從網(wǎng)站切換到HTTPS開(kāi)始的。先森已經(jīng)連續(xù)觀察了多日的CDN了，目前也就到了查缺補(bǔ)漏的階段了。先森還將整個(gè)網(wǎng)站目前備份到了另一臺(tái)服務(wù)器，將網(wǎng)站在本地解析到這臺(tái)服務(wù)器上，開(kāi)始了對(duì)代碼的檢查。開(kāi)啟了debug，把大的一些問(wèn)題都處理了，然后也把主題的代碼理了一遍，并且網(wǎng)站也加上了Redis緩存。但是先森發(fā)現(xiàn)，即使加上了Redis，有時(shí)候網(wǎng)頁(yè)打開(kāi)生成時(shí)間還是得一秒多，先森就很納悶，一直想搞明白到底是什么情況。排查工具很早以前，先森就在主題的footer.php末尾，添加了下面的代碼，以便于登錄之后可以看到當(dāng)前網(wǎng)頁(yè)的查詢次數(shù)，生成時(shí)間：<?php ?if?(is_user_logged_in()){????echo?"

".get_num_queries().'次查詢，用時(shí)';????timer_stop(3);????echo?'秒';?>這個(gè)代碼網(wǎng)絡(luò)上到處都是，相信很多人都添加的有。先森網(wǎng)站加Redis之前，網(wǎng)頁(yè)的查詢次數(shù)都是150+次，生成時(shí)間2-3秒，甚至更多。用上之后減少到50+次，但是有時(shí)還是會(huì)需要1秒多，讓先森百思不得其解。然后先森把主題代碼該優(yōu)化的都優(yōu)化后，查詢次數(shù)30+次，生成時(shí)間降到1秒左右，但是先森還是不太滿足，所以想看看到底是執(zhí)行了哪些查詢，然后就在網(wǎng)上找到了這段代碼，和上面的有些類(lèi)似。首先需要先在WordPress的根目錄配置文件wp-config.php中添加保存查詢的代碼：define('SAVEQUERIES',?true);然后也是在footer.php的網(wǎng)頁(yè)最后部分添加打印代碼：<?phpif ?(current_user_can('administrator')){????global?$wpdb;????echo?" ";????print_r($wpdb->queries);????echo?"";}?>但是先森添加后看了一下，差點(diǎn)當(dāng)場(chǎng)去世，這樣打印出來(lái)的是一個(gè)很大的多維數(shù)組，看的人眼花繚亂，重點(diǎn)是太長(zhǎng)了還顯示不全。先森將打印復(fù)制出來(lái)，拿到NotePad++里面打開(kāi)，依舊顯得很亂。查詢的打印不過(guò)大概看了一下，大數(shù)組的每一個(gè)鍵值表示一個(gè)查詢，然后一個(gè)查詢數(shù)組了，第一個(gè)值是執(zhí)行的SQL，第二個(gè)值是使用的時(shí)間，第三個(gè)值是調(diào)用的代碼位置。其實(shí)可以用循環(huán)做一個(gè)網(wǎng)格，讓前端顯示看著方便一點(diǎn)，但是先森很懶，網(wǎng)上看了一下，有插件可以做到相關(guān)功能，且不用修改wp-config.php，即Debug Queries，所以先森就懶得自己寫(xiě)了，直接裝了一個(gè)來(lái)進(jìn)行排查。需要注意的是，Debug Queries很久沒(méi)有更新了，安裝可能會(huì)報(bào)錯(cuò)，不過(guò)還是可以正常使用的。其實(shí)Debug Queries介紹頁(yè)也推薦使用Debug Objects插件，但是先森試了一下Debug Queries可以用，也就懶得再試另一個(gè)插件了。排查問(wèn)題工具準(zhǔn)備好了，先森就來(lái)好好排查到底是哪里查詢比較慢了。插件裝好了，再去看打印出來(lái)的查詢信息，就比較清晰了。先森對(duì)比了一下，大部分的查詢都是0.00x秒的，就是幾毫秒的，但是只要涉及到wp_al_urls的查詢，就會(huì)是即時(shí)甚至上百毫秒。wp_al_urls的查詢先森看了一下，這個(gè)表是插件anylink的，這個(gè)插件主要是將網(wǎng)站上的外鏈全都轉(zhuǎn)化成內(nèi)鏈，點(diǎn)擊后可以跳轉(zhuǎn)到外鏈。對(duì)于anylink，先森這里也發(fā)過(guò)兩篇相關(guān)的文章：WordPress為anylink插件外鏈跳轉(zhuǎn)添加漂亮的跳轉(zhuǎn)頁(yè)面WordPress：WPJAM BASIC插件與anylink沖突這個(gè)插件先森也是從建站伊始就在用了，是一個(gè)很好用的插件，但沒(méi)有想到這個(gè)插件會(huì)出現(xiàn)慢查詢。通過(guò)上面的截圖可以看到，對(duì)wp_al_urls的查詢條件是網(wǎng)站鏈接，看了一下數(shù)據(jù)庫(kù)，這個(gè)SQL是為了去拿到內(nèi)鏈的slug記錄：anylink獲取slug這里去查的，實(shí)際上是網(wǎng)頁(yè)正文里的外鏈、各位評(píng)論大佬的網(wǎng)址對(duì)應(yīng)的內(nèi)鏈地址。先森看了一下這個(gè)表，沒(méi)想到竟然有10M的大小，接近10萬(wàn)條數(shù)據(jù)，而且這里查詢的是al_origURL字段，先森看了一下，這個(gè)字段是沒(méi)有索引的。解決問(wèn)題對(duì)于MySQL的查詢，先森能想到的優(yōu)化方法就是加索引，所以先森直接就操作加索引，但是報(bào)錯(cuò)了：給al_origURL字段加索引報(bào)錯(cuò)看報(bào)錯(cuò)是跟字段格式有關(guān)的，看了一下這個(gè)字段的類(lèi)型是mediumtext的，這個(gè)字段是存URL的，有些URL非常的長(zhǎng)，如果該varchar的話，可能會(huì)出問(wèn)題，varchar最長(zhǎng)255個(gè)字符。網(wǎng)上找了一陣子解決方案，都是說(shuō)text相關(guān)的類(lèi)型無(wú)法加索引。先森本來(lái)就對(duì)數(shù)據(jù)庫(kù)索引什么的不太了解，所以只能放棄這條路。先森還能想到的辦法，就是看下這個(gè)查詢的代碼，想辦法把結(jié)果存到Redis上緩存起來(lái)。至于怎么找到實(shí)際執(zhí)行的代碼，先森看了一下，直接找調(diào)用的最后一段就可以了。找到慢查詢的調(diào)用代碼可以看到，兩個(gè)SQL實(shí)際上是一樣的，查的是同個(gè)網(wǎng)址，結(jié)果執(zhí)行的時(shí)間竟然都比較長(zhǎng)，所以確實(shí)得把結(jié)果緩存起來(lái)。為了優(yōu)化代碼，先森把整個(gè)網(wǎng)站都作為了一個(gè)PhpStorm里的一個(gè)項(xiàng)目，不得不說(shuō)一個(gè)好的IDE工具寫(xiě)起代碼來(lái)是真的舒服。直接全局搜索，尋找get_slug_by_url這個(gè)函數(shù)，順利找到了代碼所在。搜索get_slug_by_url函數(shù)這里有兩個(gè)結(jié)果，第一個(gè)是原本的函數(shù)，已經(jīng)被先森注釋起來(lái)了，第二個(gè)是先森改了之后的。可以看到這個(gè)函數(shù)就是調(diào)用$wpdb來(lái)執(zhí)行SQL語(yǔ)句，將得到的結(jié)果再返回一下。函數(shù)比較簡(jiǎn)單，也很利于先森修改。然后先森又找了一下WordPress如何添加緩存，結(jié)果找到一下，發(fā)現(xiàn)非常簡(jiǎn)單。WordPress操作緩存WordPress 為我們提供了使用對(duì)象緩存的函數(shù)，方便我們使用對(duì)象緩存。wp_cache_add() ：添加數(shù)據(jù)到緩存中，如果數(shù)據(jù)已存在，返回 flasewp_cache_set() ：添加數(shù)據(jù)到緩存中，如果數(shù)據(jù)已存在，會(huì)覆蓋數(shù)據(jù)wp_cache_get() ：獲取緩存中的數(shù)據(jù)，如果數(shù)據(jù)不存在，返回 falsewp_cache_delete() ： 從緩存中刪除數(shù)據(jù)wp_cache_replace() ：替換緩存中的數(shù)據(jù)，類(lèi)似 wp_cache_set，但是如果數(shù)據(jù)不存在，不自動(dòng)添加wp_cache_flush()：清除所有緩存如果沒(méi)有裝redis緩存插件，上面的這些函數(shù)是在./wp-includes/cache.php里。如果裝了Redis Object Cache等插件，就會(huì)自動(dòng)增加一個(gè)./wp-content/object-cache.php文件，這些函數(shù)也會(huì)存在于這個(gè)文件中，用于存入緩存。WordPress 對(duì)象緩存使用使用示例$result?=?wp_cache_get(?'my_result'?);if?(?false?===?$result?)?{????$result?=?$wpdb->get_results(?$query?);????wp_cache_set(?'my_result',?$result?);}對(duì)anylink的get_slug_by_url函數(shù)改造有了上面這個(gè)案例，先森為anylink的函數(shù)增加緩存就很方便了。示例很簡(jiǎn)單，get_slug_by_url函數(shù)本身也簡(jiǎn)單，所以改造后如下：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;}因?yàn)槭纠秃瘮?shù)太契合了，所以這個(gè)函數(shù)幾乎就和示例結(jié)構(gòu)一樣。首先去Redis獲取緩存數(shù)據(jù)，獲取不到就去MySQL查詢，查到后再存到Redis。檢查效果代碼修改后，同步到測(cè)試服務(wù)器，訪問(wèn)了兩次之前訪問(wèn)的頁(yè)面，查詢次數(shù)和用時(shí)都降下來(lái)了。然后看到查詢次數(shù)還是有33次，其中有部分是查詢wp_al_urls_index這個(gè)表的，雖然速度不慢，但是次數(shù)比較多，先森重復(fù)上面的方法也修改了一下相關(guān)函數(shù)，最終效果如下圖：最終效果查看Redis的keys上面改造的代碼中，是拿url地址去做的key名稱，那么先森也來(lái)看下緩存數(shù)據(jù)在Redis里的情況：redis的緩存上面改造的代碼比較簡(jiǎn)陋，直接拿的URL做的key名稱，如果URL比較短還好，如果長(zhǎng)的話就可能出現(xiàn)問(wèn)題，key名稱其實(shí)可以做一下長(zhǎng)度限制。提示：Redis最好不要使用默認(rèn)端口6379，除非安全做的非常好。使用Redis時(shí)注意以下幾點(diǎn)：1、一定要配置強(qiáng)密碼；2、安全組、防火墻一定要最小范圍放通Redis端口，即針對(duì)指定IP放通訪問(wèn)；3、盡量不要使用默認(rèn)端口。因?yàn)镽edis而導(dǎo)致服務(wù)器中木馬病毒的保障，先森這邊經(jīng)常遇到。總結(jié)先森以前以為給WordPress配上Redis很麻煩，實(shí)際使用發(fā)現(xiàn)真香，建議有能力的朋友都上一下，畢竟生命不止，折騰不息。本文最主要的還是記錄一下排查網(wǎng)頁(yè)查詢慢的過(guò)程和解決方法，希望能夠給其他朋友提供思路。

總結(jié)

以上是生活随笔為你收集整理的mysql 重复航_mysql的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。