建站
咨詢
售后
建站咨詢
新聞中心
讓客戶滿意是我們工作的目標，不斷超越客戶的期望值來自于我們對這個行業(yè)的熱愛。我們立志把好的技術(shù)通過有效、簡單的方式提供給客戶，將通過不懈努力成為客戶在信息化領(lǐng)域值得信任、有價值的長期合作伙伴，公司提供的服務(wù)項目有：域名注冊、網(wǎng)絡(luò)空間、營銷軟件、網(wǎng)站建設(shè)、樂業(yè)網(wǎng)站維護、網(wǎng)站推廣。
我們一起看看wordpress數(shù)據(jù)庫中的wp_options表。當涉及到整體WordPress和數(shù)據(jù)庫性能時，這是一個經(jīng)常被忽視的領(lǐng)域。尤其是在較舊的大型網(wǎng)站上，由于第三方插件和主題留下的自動加載數(shù)據(jù)，這可能是導致網(wǎng)站查詢時間變慢的罪魁禍首。查看以下有關(guān)如何檢查、排除故障和清理wp_options表的提示。
wp_options表是什么？
wp_options表中包含的各種資料為你的WordPress網(wǎng)站，如：
- 站點URL、主頁URL、管理員電子郵件、默認類別、每頁文章、時間格式等
- 插件、主題、小部件的設(shè)置
- 臨時緩存的數(shù)據(jù)
wp_options表
該表包含以下字段，我們在性能方面更關(guān)心其中一個字段：
- option_id
- option_name
- option_value
- autoload
wp_options表自動加載
了解wp_options表的重要事項之一是autoload字段。這包含是或否值（標志）。這基本上控制它是否由wp_load_alloptions() 函數(shù)加載。自動加載的數(shù)據(jù)是在WordPress網(wǎng)站的每個頁面上加載的數(shù)據(jù)。就像我們向您展示了如何禁止某些腳本在站點范圍內(nèi)加載一樣，同樣的想法在這里也適用。默認情況下，開發(fā)人員的自動加載屬性設(shè)置為“yes”，但并非每個插件理論上都應(yīng)該在每個頁面上加載他們的數(shù)據(jù)。
WordPress網(wǎng)站可能遇到的問題是wp_options表中有大量自動加載的數(shù)據(jù)。這通常是以下原因造成的：
- 數(shù)據(jù)由插件自動加載，而實際上它應(yīng)該設(shè)置為“no”。一個很好的例子就是聯(lián)系表單插件。它需要在每個頁面上加載數(shù)據(jù)還是只在聯(lián)系頁面上加載數(shù)據(jù)？
- 插件或主題已從WordPress站點中刪除，但它們的選項仍留在wp_options表中。這可能意味著每次請求都會查詢不必要的自動加載數(shù)據(jù)。
- 插件和主題開發(fā)人員正在將數(shù)據(jù)加載到wp_options表中，而不是使用他們自己的表。這方面存在爭議，因為一些開發(fā)人員更喜歡不創(chuàng)建額外表的插件。但是， wp_options表也不是為保存數(shù)千行而設(shè)計的。
太多自動加載的數(shù)據(jù)是多少？這當然可以變化，但理想情況下，您希望它在300KB 到1MB之間。一旦開始接近3-5MB 范圍或更多，很可能可以優(yōu)化或刪除自動加載的內(nèi)容。任何超過10MB 的內(nèi)容都應(yīng)該立即解決。這并不總是意味著它會導致問題，但這是一個很好的起點。
對wp_options表中的自動加載數(shù)據(jù)進行故障排除
如果您的WordPress網(wǎng)站運行緩慢，可能是由于舊WordPress插件遺留的查詢或自動加載數(shù)據(jù)。下面我們將向您展示如何檢查數(shù)據(jù)庫中自動加載的大小，以及深入了解實時站點的數(shù)據(jù)并分享我們?yōu)榍謇硭龅墓ぷ鳌?/p>
檢查自動加載的數(shù)據(jù)大小
首先要做的是檢查WordPress網(wǎng)站上當前自動加載的大小。為此，請登錄到phpMyAdmin。單擊左側(cè)的數(shù)據(jù)庫，然后單擊SQL選項卡。然后輸入以下命令并點擊“Go”。
SELECT SUM(LENGTH(option_value)) as autoload_size FROM wp_options WHERE autoload='yes';
如果您的WordPress站點使用wp_ 以外的其他前綴，您可能需要調(diào)整上面的查詢。
phpMyAdmin中的自動加載大小查詢
autoload_size將以字節(jié)為單位返回。KB中有1024字節(jié)，MB中有1024KB。所以在我們的例子中，249,025字節(jié)等于0.25MB。所以對于這個網(wǎng)站，這是一個很好的尺寸！如果您返回低于1MB的任何內(nèi)容，您不必擔心。但是，如果結(jié)果要大得多，請繼續(xù)本教程。
自動加載大小
下面是我們正在測試的站點，其中返回了137,724,715個字節(jié)，或者更確切地說是137MB。這是一個網(wǎng)站肯定有問題的一個很好的例子，或者說有一些事情需要優(yōu)化。
wp_options表中的大型自動加載數(shù)據(jù)
您還可以使用更長的查詢，如下所示。這將顯示自動加載的數(shù)據(jù)大小、表中有多少條目以及按大小排列的前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)
高級自動加載數(shù)據(jù)MySQL查詢
如果您有權(quán)訪問New Relic，您還可以使用它來幫助解決連接到wp_options表的查詢。數(shù)據(jù)庫選項卡將指出消耗最多時間的表和查詢類型。如果您選擇列表中的條目之一，您可以看到更多詳細信息，包括一些示例查詢。在下面的這個示例中，您可以看到數(shù)據(jù)指向wp_options表中自動加載的數(shù)據(jù)。果然，對該站點的快速分析證實了近250MB的自動加載數(shù)據(jù)。
New Relic慢查詢 – wp_options表
排序頂部自動加載的數(shù)據(jù)
下一步是使用自動加載的數(shù)據(jù)快速排序頂部項目。這是一個可以用來列出前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_ 以外的其他前綴，您可能需要調(diào)整上面的查詢。
wp_options表中自動加載的頂部數(shù)據(jù)
在wp_options中挖掘單個自動加載的數(shù)據(jù)
下一步是挖掘一些最重要的自動加載數(shù)據(jù)。
301重定向
正如我們在上面看到的，頂部的自動加載選項是301_redirects。這可能與站點上的重定向插件或WordPress SEO插件直接相關(guān)，該插件也具有重定向功能。在這種情況下，最好的建議是在服務(wù)器級別實際實施重定向。
為什么？因為使用免費的WordPress插件來實現(xiàn)重定向有時會導致性能問題，因為它們中的大多數(shù)使用wp_redirect函數(shù)，這需要額外的代碼執(zhí)行和資源。當然，它還自動將數(shù)據(jù)加載到wp_options表中。
如果您是寶塔面板，您可以使用我們的301重定向配置在服務(wù)器級別輕松添加重定向。這不僅提高了性能，而且您可能少了一個插件需要擔心！
登入您的寶塔面板，點擊網(wǎng)站菜單，找到你需要配置301重定向的網(wǎng)站，點擊“設(shè)置”操作項：
寶塔面板網(wǎng)站管理
然后在彈出窗口中，選擇301重定向，選擇重定向類型為路徑，然后再設(shè)置源地址及重定向URL即可。（注：不同寶塔面板，界面可能有出入）
在寶塔面板中添加重定向規(guī)則
wpurp_custom_template_
下一個自動加載數(shù)據(jù)選項是wpurp_custom_template_#。我們可以看到有很多不同的行。通常，您應(yīng)該能夠通過查看您的主題或插件文件夾來找到此選項名稱并連接點。在這種情況下，我們從服務(wù)器執(zhí)行了grep命令以查看是否可以找到它。您也可以通過SFTP進行抽查。
grep -Ri "wpurp_custom_template_"
但是，上面的命令沒有返回任何內(nèi)容，因此我們轉(zhuǎn)到 Google 并進行了搜索。我們很快發(fā)現(xiàn)它與網(wǎng)站上不再安裝的WordPress插件有關(guān)，稱為WP Ultimate Recipe。這是留下不必要的自動加載數(shù)據(jù)的經(jīng)典示例。我們有一個關(guān)于如何卸載WordPress插件（正確方法）的冗長教程。適當?shù)?，我們的意思是實際清理留下的東西。
wpurp_custom_template_
um_cache_userdata_
下一個自動加載數(shù)據(jù)選項是um_cache_userdata_#。我們可以看到有很多不同的行。由于這是在底部，我們快速修改了我們的MySQL命令以顯示前40個自動加載的數(shù)據(jù)：
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_#條目。我們再次運行g(shù)rep命令來檢查我們的插件和主題文件夾。
grep -Ri "um_cache_userdata_"
然后我們能夠快速確定這與Ultimate Member插件有關(guān)。另一個快速的Google搜索返回了針對此問題的一些很好的解決方案（請參閱支持文章）。永遠不要低估Google搜索的力量！事實證明，插件中有幾個不同的選項可以解決這個問題。
- Ultimate Member > Dashboard > User Cache > Clear Cache。
- Ultimate Member -> Settings -> Advanced -> Stop caching user’s profile data（切換到ON），然后保存更改。
查看自動加載選項的另一個選項是點擊編輯按鈕，這可以列出插件/主題的目錄，或列出開發(fā)人員的網(wǎng)站。
定時任務(wù)
我們在大量自動加載數(shù)據(jù)中看到的另一個常見選項是cron。為此，它可以是任何與cron相關(guān)的東西。所以你可以做的是點擊“edit”按鈕，看看是什么導致了它。下面是一個示例，其中很明顯是“do_pings”導致了問題。再次，快速的谷歌搜索揭示了清理 do_pings的快速修復。
cron – do_pings
清理wp_options表
如果您看到很多我們上面提到的內(nèi)容，那么可能是時候清理 wp_options 表中所有自動加載的數(shù)據(jù)了。還建議您嘗試將wp_options表上的行數(shù)保持在最低限度。在刪除數(shù)據(jù)庫中的數(shù)據(jù)之前，請始終進行備份。
就像我們之前所做的那樣，您需要登錄到phpMyAdmin。單擊左側(cè)的數(shù)據(jù)庫，然后單擊SQL選項卡。然后輸入以下命令并點擊“Go”。
SELECT * FROM `wp_options` WHERE `autoload` = 'yes'
如果您的WordPress站點使用wp_ 以外的其他前綴，您可能需要調(diào)整上面的查詢。這將顯示wp_options表中設(shè)置為自動加載的所有數(shù)據(jù)。
在wp_options中查找自動加載的數(shù)據(jù)
向下滾動行，我們會看到網(wǎng)站不再安裝或使用的各種插件。這只是我們將要使用的一個示例，但在這種情況下，我們注意到了一堆Jetpack行。Jetpack不再在相關(guān)網(wǎng)站上使用。
舊的自動加載數(shù)據(jù)
檢查插件開發(fā)人員的文檔總是好的，因為有時他們可以選擇清理遺留的表格。在這種情況下，有時只需再次安裝插件，檢查其自動清理選項，然后正確刪除插件，會更安全、更容易。但是，我們將向您展示如何手動清理表。
因此，在這種情況下，我們運行以下查詢以從Jetpack插件的wp_options表中查找自動加載的數(shù)據(jù)。要使用您自己的查詢修改查詢，只需替換 %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表中自動加載的數(shù)據(jù)
然后，您可以清洗并重復wp_options表中插件和主題留下的其他自動加載數(shù)據(jù)。
清理瞬態(tài)
除非您使用對象緩存，否則WordPress會在wp_options表中存儲臨時記錄。通常這些都有一個過期時間，應(yīng)該會隨著時間的推移而消失。然而，情況并非總是如此。我們已經(jīng)看到一些數(shù)據(jù)庫中有數(shù)千條舊的臨時記錄。同樣重要的是要注意瞬態(tài)默認情況下不會自動加載。您可以使用如下查詢來查看是否有任何自動加載的瞬態(tài)數(shù)據(jù)。
SELECT * FROM `wp_options` WHERE `autoload` = 'yes' AND `option_name` LIKE '%transient%'
然而，更好、更安全的選擇是使用像Transient Cleaner這樣的免費插件，它只能從wp_options表中清除過期的瞬態(tài)。
清理WordPress會話
我們看到的另一個常見問題是有時cron作業(yè)不同步或不能正確觸發(fā)，因此會話沒有得到清理。您可能會_wp_session_在數(shù)據(jù)庫中獲得大量行。在下面的示例中，所討論的站點在其 wp_options 表中有超過300萬行。表的大小已經(jīng)超過了600MB。
具有數(shù)百萬行的wp_options表
您可以使用如下所示的查詢來查看您是否遇到此問題：
SELECT * FROM `wp_options` WHERE `option_name` LIKE '_wp_session_%'
_wp_session_ 行
在大多數(shù)情況下，您可以使用以下命令安全地刪除這些（作為cron作業(yè)應(yīng)該具有的）：
DELETE FROM `wp_options` WHERE `option_name` LIKE '_wp_session_%'
清理完所有剩余_wp_session_ rows的表后，該表只有不到1,000行，大小減少到11MB。
WP會話已清理
它還修復了站點在MySQL中出現(xiàn)的峰值。
MySQL網(wǎng)絡(luò)事務(wù)
添加索引以自動加載
如果清理wp_options表還不夠，您可以嘗試向自動加載字段添加“index”。這基本上可以幫助它更有效地搜索。10up的出色團隊在wp_options表上執(zhí)行了一些測試場景，其中包含典型的自動加載記錄數(shù)，以展示向wp_options查詢添加自動加載索引如何提高性能。
wp_options查詢時間 (Img src: 10up )
我們還建議您從WP Bullet查看這兩個額外的資源：
- 如何將MySQL索引添加到wp_options表
- 使用WP-CLI清理wp_options表
有關(guān)更多優(yōu)化技巧，請確保您查看我們的深入指南： 如何加速您的WordPress網(wǎng)站（終極指南）
網(wǎng)站名稱：如何清理wp_options表和自動加載的數(shù)據(jù)
分享鏈接：http://www.5511xx.com/article/cdhipds.html
