Idag så ska vi ta en titt på tabellen wp_options i din WordPress-databas. Detta är ett område som ofta förbises när det gäller övergripande WordPress- och databasprestanda. Särskilt på äldre och stora webbplatser kan detta vara boven i dramat för långsamma söktider på din webbplats. Detta beror på att autoladdad data lämnas kvar från plugins och teman från tredje part. Kolla in de här tipsen nedan om hur du kan kontrollera, felsöka och rensa upp din wp_options-tabell.
Vad är wp_options-tabellen?
wp_options-tabellen innehåller alla typer av data för din WordPress-webbplats, t.ex:
- Webbplatsens webbadress, hem-webbadress, administratörens e-postadress, standardkategori, inlägg per sida, tidsformat osv.
- Inställningar för plugins, teman och widgets
- Temporärt lagrad data
Tabellen inkluderar följande fält, varav ett som är lite viktigare än de andra när det gäller prestanda:
- option_id
- option_name
- option_value
- autoload
En av de viktiga sakerna att förstå om tabellen wp_options är fältet autoladdning. Detta innehåller ett ja- eller ett nej-värde (flagga). Det kontrollerar i huvudsak om funktionen wp_load_alloptions() laddar eller inte. Autoladdad data är data som laddas på varje sida på din WordPress-webbplats. Vi har ju visat dig hur du kan inaktivera vissa skript från att laddas på hela webbplatsen och samma idé gäller här. Autoladdnings-attributet är inställt på ”ja” som standard för utvecklare, men alla plugins bör teoretiskt sett inte ladda sina data på varje sida.
Problemet som WordPress-webbplatser kan råka ut för är att det finns en stor mängd autoladdad data i tabellen wp_options. Detta är vanligtvis ett resultat av följande:
- Data autoladdas av ett plugin när det egentligen borde vara inställt på ”nej”. Ett bra exempel på detta är ett plugin för kontaktformulär. Behöver det ladda data på alla sidor eller endast på kontaktsidan?
- Plugins eller teman har tagits bort från WordPress-webbplatsen, men deras alternativ finns fortfarande kvar i wp_options-tabellen. Detta kan innebära att onödig autoladdad data frågas ut vid varje begäran.
- Utvecklare av plugins och teman laddar in data i wp_options-tabellen i stället för att använda sina egna tabeller. Det finns argument för båda sidor av detta, eftersom vissa utvecklare föredrar plugins som inte skapar ytterligare tabeller. wp_options-tabellen utformades dock inte för att rymma tusentals rader.
Hur mycket är för mycket autoladdad data? Detta kan naturligtvis variera, men den bör helst ligga på mellan 300 KB och 1 MB. När du börjar närma dig 3-5 MB eller mer så finns det troligtvis saker som kan optimeras eller tas bort från autoladdningen. Och allt över 10 MB bör åtgärdas direkt. Detta betyder inte alltid att det kommer att orsaka problem, men det är en bra början.
Felsökning av autoladdad data i wp_options-tabellen
Om du upplever en långsamhet på din WordPress-webbplats så kan detta bero på en sökfråga eller autoladdad data som har lämnats kvar från ett gammalt WordPress-plugin. Nedan så visar vi dig hur du kontrollerar den autoladdade storleken i din databas, samt djupdyker i data från en live-webbplats och delar med oss av vad vi gjorde för att städa upp.
Kontrollera storleken på autoladdad data
Det första som du ska göra är att kontrollera den aktuella storleken på autoladdningen på din WordPress-webbplats. För att göra detta så loggar du in på phpMyAdmin. Klicka på din databas på vänster sida och sedan på fliken SQL. Ange sedan följande kommando och tryck på ”Kör”.
SELECT SUM(LENGTH(option_value)) as autoload_size FROM wp_options WHERE autoload='yes';Du kan behöva justera sökfrågan ovan om din WordPress-webbplats använder ett annat prefix än wp_.
Autoload_size returneras i bytes. Det finns 1024 bytes i en KB och 1024 KB i en MB. Så i vårt fall så motsvarar 249 025 bytes 0,25 MB. Så för den här webbplatsen är detta en bra storlek! Om du returnerar något som är mindre än 1 MB bör du inte vara orolig. Men om resultatet är mycket större än så ska du fortsätta med den här handledningen.
Nedan så visas en webbplats som vi testade där 137 724 715 bytes returnerades eller snarare 137 MB. Detta är ett bra exempel på en webbplats där något definitivt är fel, eller där det snarare finns saker att optimera.
Du kan även använda en längre sökfråga som exempelvis följande. Detta visar storleken på autoladdad data, hur många poster som finns i tabellen och de tio första posterna efter storlek.
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)
Om du har tillgång till New Relic (licens krävs) så kan du även använda detta för att hjälpa till att felsöka sökfrågor som är kopplade till wp_options-tabellen . Fliken databaser visar vilken tabell och vilken typ av sökfråga som tar mest tid i anspråk. Om du väljer en av posterna i listan så kan du se mer detaljer, inklusive några exempelfrågor. I exemplet nedan så kan du se att uppgifterna visar en stor mängd autoladdad data i wp_options-tabellen. En snabb analys av webbplatsen i fråga bekräftade att det fanns nästan 250 MB autoladdad data.
Sortera uppgifter med mest autoladdad data
Nästa steg skulle vara att snabbt sortera de objekt som har mest autoladdad data. Här är ett snabbt SQL-kommando som du kan använda för att lista de tio största bovarna:
SELECT option_name, length(option_value) AS option_value_length FROM wp_options WHERE autoload='yes' ORDER BY option_value_length DESC LIMIT 10;Du kan behöva justera sökfrågan ovan om din WordPress-webbplats använder ett annat prefix än wp_.
Gräva i enskild autoladdad data i wp_options
Nästa steg var att gräva i några av de mest autoladdade uppgifterna.
301_redirects
Som vi kan se ovan så är 301_redirects det mest autoladdade alternativet. Detta är förmodligen direkt relaterat till ett omdirigeringsplugin på webbplatsen eller WordPress SEO-plugin, som också har en omdirigeringfunktion. I det här fallet så är den bästa rekommendationen att faktiskt implementera omdirigeringarna på servernivå.
Varför? Eftersom användning av kostnadsfria WordPress-plugins för att implementera omdirigeringar ibland kan orsaka prestandaproblem. De flesta av dem använder nämligen wp_redirect-funktionen, vilket kräver ytterligare kodkörning och resurser. Och den autoladdar självklart även data till wp_options-tabellen.
Om du är en Kinsta-klient kan du enkelt lägga till omdirigeringar på servernivå med hjälp av verktyget för omdirigerings-regler i din MyKinsta-instrumentpanel. Detta är inte bara bättre för prestanda, du får dessutom ett plugin mindre att oroa dig för!
wpurp_custom_template_
Nästa toppalternativ för autoladdad data var wpurp_custom_template_#. Vi kan se att det finns ganska många olika rader för detta. Vanligtvis så bör du kunna hitta det här alternativnamnet och lägga ihop två och två genom att titta i din mapp för teman eller plugins. I det här fallet så körde vi ett grep-kommando från servern för att se om vi kunde hitta det. Du kan även göra en stickprovskontroll via SFTP.
grep -Ri "wpurp_custom_template_"Ovanstående kommando gav dock inget resultat och därför så gick vi över till Google och utförde en sökning. Vi upptäckte snabbt att problemet var relaterat till ett WordPress-plugin som inte längre var installerat på webbplatsen, känt som WP Ultimate Recipe. Detta är ett klassiskt exempel på onödig autoladdad data som har lämnats kvar. Vi har en lång handledning om hur man avinstallerar WordPress-plugins (på rätt sätt). Och med korrekt så menar vi att man faktiskt städar upp det som lämnas kvar.
um_cache_userdata_
Det näst största alternativet med autoladdad data var um_cache_userdata_#. Vi kan se att det finns en hel del olika rader för detta. Eftersom detta var längst ner, så ändrade vi snabbt vårt MySQL-kommando för att visa de 40 mest autoladdade uppgifterna:
SELECT option_name, length(option_value) AS option_value_length FROM wp_options WHERE autoload='yes' ORDER BY option_value_length DESC LIMIT 40;Eller summera alla värden med det här prefixet:
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_%"Vi kunde se att det fanns många fler poster för um_cache_userdata_# i tabellen wp_options. Sedan körde vi återigen ett grep-kommando för att kontrollera våra plugins- och tema-mappar.
grep -Ri "um_cache_userdata_"Vi kunde sedan snabbt identifiera detta som relaterat till pluginet Ultimate Member. En annan snabb Google-sökning gav några bra lösningar på det här problemet (se supportartikeln). Underskatta aldrig kraften hos en Google-sökning! Det visade sig att det fanns några olika alternativ i pluginet för att lösa problemet.
- Ultimate Member > Intrumentpanel > Användar Cache > Rensa Cache.
- Ultimate Member -> Inställningar -> Avancerat -> Stoppa cachelagring av användarens profildata (växla till ON) och spara sedan ändringarna.
Ett annat alternativ för att upptäcka en autoladdad uppgift är att trycka på redigeringsknappen, och detta kan lista katalogen för pluginet/temat eller lista utvecklarens webbplats.
Cron-job
Ett annat vanligt alternativ som ofta har en stor mängd autoladdad data är cron. Detta kan gälla vad som helst som är cronrelaterat. Så vad du kan göra är att trycka på knappen ”redigera” för att se vad som orsakar det. Här är ett exempel där det var uppenbart att ”do_pings” orsakade problemet. Återigen, en snabb Google-sökning avslöjade en snabb lösning för att rensa upp do_pings.
Rensa upp i wp_options-tabellen
Om du ser mycket av det som vi nämnde ovan så är det förmodligen dags att rensa upp all autoladdad data i din wp_options-tabell. Det rekommenderas även att du försöker hålla antalet rader i din wp_options-tabell till ett minimum. Ta alltid säkerhetskopior innan du tar bort data i din databas. Om du inte är bekväm med att göra detta själv så rekommenderar vi alltid att du anlitar en WordPress-utvecklare. Det här är även ett bra scenario där en iscensättningsmiljö kan komma till nytta.
Precis som vi gjorde tidigare så måste du logga in på phpMyAdmin. Klicka på din databas på vänster sida och sedan på fliken SQL. Skriv sedan in följande kommando och tryck på ”Kör”.
SELECT * FROM `wp_options` WHERE `autoload` = 'yes'Du kan behöva justera sökfrågan ovan om din WordPress-webbplats använder ett annat prefix än wp_. Detta kommer att visa dig alla data i wp_options-tabellen som är inställda på autoladdning.
När vi scrollar ner genom raderna så ser vi alla slags plugins som inte längre är installerade eller används av webbplatsen. Det här är bara ett exempel som vi kommer att använda, men i det här fallet så upptäckte vi ett gäng Jetpack-rader. Jetpack användes inte längre på webbplatsen i fråga.
Det är alltid bra att kontrollera pluginutvecklarens dokumentation eftersom de ibland har ett alternativ för att rensa upp sina kvarlämnade tabeller. I så fall så är det ibland säkrare och enklare att helt enkelt installera pluginet igen, kontrollera deras automatiska rensningsalternativ och sedan ta bort pluginet korrekt. Vi kommer dock att visa dig hur du rensar upp tabellerna manuellt.
Så i det här fallet kör vi följande sökfråga för att hitta de autoladdade uppgifterna i wp_options-tabellen från Jetpack-pluginet. Om du vill ändra sökfrågan med din egen, byt helt enkelt ut %jetpack%.
SELECT *
FROM `wp_options`
WHERE `autoload` = 'yes'
AND `option_name` LIKE '%jetpack%'Du kan sedan välja alla rader och klicka på ”Ta bort”.
Du kan även köra följande kommando:
DELETE
FROM `wp_options`
WHERE `autoload` = 'yes'
AND `option_name` LIKE '%jetpack%'
Du kan sedan rensa och upprepa för ytterligare autoladdad data som har lämnats kvar från plugins och teman i din wp_options-tabell.
Rensa upp transienter
Om du inte använder en objektcache så lagrar WordPress tillfälliga poster i tabellen wp_options. Dessa har vanligtvis fått en utgångstid och bör försvinna med tiden. Så är dock inte alltid fallet. Vi har sett några databaser där det finns tusentals gamla transienta poster. Det är även viktigt att notera att transienter inte ska autoladdas som standard. Du kan använda en sökfråga som den nedan för att se om det finns någon autoladdad transientdata.
SELECT *
FROM `wp_options`
WHERE `autoload` = 'yes'
AND `option_name` LIKE '%transient%'Ett bättre och säkrare alternativ är dock att använda ett kostnadsfritt plugin som Transient Cleaner som kan rensa upp de utgångna transienterna från din wp_options-tabell.
Rensa upp WordPress-sessioner
Ett annat vanligt problem som vi har sett är att cron-jobs ibland blir osynkroniserade eller inte avfyras ordentligt. Detta kan göra att sessioner inte rensas. Du kan få massor av _wp_session_-rader i din databas. I exemplet nedan så fick webbplatsen i fråga över 3 miljoner rader i wp_options-tabellen. Och tabellen hade vuxit till över 600 MB i storlek.
Du kan använda en sökfråga som den nedan för att se om du stöter på det här problemet:
SELECT *
FROM `wp_options`
WHERE `option_name` LIKE '_wp_session_%'
I de flesta fall så kan du sedan radera dessa på ett säkert sätt (som ett cronjob borde ha gjort) med följande kommando:
DELETE FROM `wp_options`
WHERE `option_name` LIKE '_wp_session_%'Efter att ha rensat upp alla överblivna _wp_session_ rows så hade tabellen mindre än 1 000 rader och var reducerad till 11 MB i storlek.
Detta fixade även de toppar som webbplatsen fick i MySQL.
Lägg till ett index för autoladdning
Och om det inte räckte med att städa upp din wp_options-tabell så kan du försöka att lägga till ett ”index” till autoladdnings-fältet. Detta kan i huvudsak skapa en effektivare sökning. Det grymma teamet på 10up utförde några testscenarier på en wp_options-tabell med ett typiskt antal autoladdnings-poster för att visa hur man kan öka prestandan genom att lägga till ett autoladdnings-index till wp_options-förfrågningar.
Vi rekommenderar även att du kollar in dessa två ytterligare resurser från WP Bullet:
- Hur man lägger till MySQL Index till wp_options-tabellen
- Rensning av wp_options-tabellen med hjälp av WP-CLI
För ännu fler optimeringstips så kan du ta en titt på vår djupgående guide: Hur du snabbar upp din WordPress-webbplats (ultimat guide)
