Find langsomme databasekald med Query Monitor

Kort svar: Query Monitor er et gratis plugin, der pr. sidevisning viser, hvilke databasekald der kører, hvor lang tid de tager, og – vigtigst – hvilken komponent (plugin, tema eller kerne) der udløste dem. Installér det, åbn en langsom side, og se „Queries by Component“ og de langsomme queries: synderen står øverst. Brug det på staging eller kortvarigt på live (kun administratorer ser panelet), og afinstallér efter brug – det er et diagnoseinstrument, ikke fast inventar.

Fagligt gennemgået: 2. oktober 2026

Når en ucachet side er langsom, gættes der ofte: „det er nok hostingen“ eller „det er nok det nye plugin“. Query Monitor erstatter gætteriet med en regning: hvert databasekald med tid, kilde og kaldsstak. Ti minutter med værktøjet afgør som regel, om problemet er koden eller serveren – og præcis hvilket plugin der i så fald sender regningen.

Guiden viser, hvordan du måler rigtigt, hvordan du læser panelet, hvilke mønstre du skal kende, og hvad du gør med fundet bagefter.

Før du ændrer noget: Mål helst på en staging-kopi. Skal du måle på live, så gør det kortvarigt og som administrator, og afinstallér pluginnet igen bagefter. Deaktivér aldrig plugins på et live-site for at „se om det hjælper“ uden backup og et roligt tidspunkt.

1. Installér og mål det rigtige

Query Monitor installeres som ethvert andet plugin fra WordPress’ pluginkatalog. Efter aktivering får admin-bjælken en ny statuspost med sidetid, hukommelsesforbrug, databasetid og antal queries.

Det vigtigste er at måle en visning, der faktisk rammer databasen. En page-cachet side kører slet ikke PHP og databasekald – så Query Monitor kan kun vise noget om visninger, hvor cachen er gået uden om. Som indlogget administrator er du typisk allerede uden om page cachen. Vil du se siden som en besøgende uden login, har Query Monitor en indstilling til en godkendelsescookie, så panelet også vises, når du er logget ud.

• Mål de sider, der føles langsomme: kategorisider, søgning, kurv, checkout og tunge forsider.
• Genindlæs siden et par gange og se på et typisk resultat, ikke det første kolde kald.
• Notér sidetid, databasetid og antal queries før du ændrer noget.

2. Sådan læser du panelet

Klik på statusposten i admin-bjælken for at åbne panelet. De visninger, der afgør næsten alle sager:

• Queries by Component: samlet antal og tid pr. plugin, tema og kerne. Start altid her – den fortæller på ti sekunder, om ét plugin dominerer.
• Slow Queries: enkeltkald over tærsklen for „langsomt“ (som standard 0,05 sekunder), markeret med kilde og kaldsstak.
• Duplicate Queries: samme forespørgsel stillet flere gange på samme side.
• Queries by Caller: hvilken funktion i koden der stillede spørgsmålet – nyttigt, når du skal forklare en udvikler, hvad der skal rettes.

Query Monitor kan lægge en lille hjælpefil (db.php) i wp-content for at få mere detaljerede data. Den hører til pluginnet og bør være væk, når du har afinstalleret det igen – tjek det, hvis du ser en db.php, du ikke kender.

3. De tre klassiske mønstre

• Få, langsomme queries: én forespørgsel på flere hundrede millisekunder – typisk en søgning uden indeks, et tungt JOIN eller en meget stor tabel bag. Synderen står i kaldets komponent og stak.
• Mange små queries (N+1): hundredvis af næsten ens kald – et plugin, der spørger pr. produkt eller indlæg i en liste i stedet for samlet. Hvert kald er billigt; summen er dyr.
• Dublerede queries: samme spørgsmål stillet flere gange på én side. Ofte tegn på manglende object cache, som netop genbruger svarene.

Mønster	Typisk årsag	Typisk løsning
Få, langsomme	Manglende indeks, stor tabel, tung meta-søgning	Indeks, oprydning eller anden forespørgsel
Mange små (N+1)	Kald pr. element i en løkke	Hent data samlet eller cache resultatet
Dublerede	Ingen genbrug af svar	Object cache eller cache i koden

4. Fra fund til handling

Fundet bestemmer vejen. Er synderen et plugin, så tjek først indstillingerne (logs, statistik og „live“-funktioner kan ofte slås fra), dernæst om en opdatering løser det – og ellers om et lettere alternativ findes. Er det temaet, er det typisk tællere og „relaterede indlæg“-funktioner uden cache. Er det egne tilpasninger, så cache resultatet, fx med en transient.

Er kaldene sunde, men alting jævnt langsomt, er det ikke databasens skyld – gå til næste afsnit. Store oprydninger i selve databasen – autoload, revisioner og transients – hører til i databaseoprydnings-guiden.

5. Hvornår er det serveren?

Query Monitor giver også det ærlige svar den anden vej: når queries er få og hurtige, men sidetiden stadig høj, ligger tiden i PHP-afvikling, eksterne HTTP-kald eller ventetid på serveren. Kig i panelet efter HTTP API-kald: et plugin, der henter data fra en ekstern tjeneste ved hver sidevisning, kan alene koste et sekund.

Sammenlign samme side på staging og live og på forskellige tidspunkter: svinger tallene med døgnet, er det belastning – og så er det TTFB-sporet og i sidste ende serverkraft, der flytter noget. Med Query Monitor-tal i hånden bliver dialogen med hostingudbyderen også konkret: „95 queries på 80 ms, men 1,8 sekunders sidetid“ er en helt anden samtale end „sitet er langsomt“.

Mere end databasen: de andre paneler

Query Monitor er mest kendt for databasekald, men flere af de andre paneler er lige så nyttige i fejlfinding:

• PHP Errors: advarsler og deprecated-meddelelser fra den aktuelle sidevisning, med plugin eller tema som kilde – praktisk efter en PHP-opgradering.
• HTTP API Calls: eksterne kald, som WordPress foretager under sidevisningen, med svartid og status.
• Scripts og Styles: hvilke JavaScript- og CSS-filer der indlæses, og hvem der har tilføjet dem.
• Hooks: hvilke funktioner der er koblet på hvilke hooks – nyttigt, når du leder efter, hvem der ændrer noget.

Ajax- og REST-kald vises ikke i det almindelige panel, fordi der ikke er en side at vise det på. Query Monitor kan i stedet sende oplysningerne med i svarets headere til indloggede administratorer, så du kan se dem i browserens Netværk-fane.

Når du ikke kan installere plugins

På nogle sites må der ikke installeres ekstra plugins, heller ikke kortvarigt. Så kan databasens egen log over langsomme forespørgsler (slow query log) give et tilsvarende billede på serverniveau – den viser de langsomste forespørgsler på tværs af alle sidevisninger, men uden oplysning om, hvilket plugin der stod bag. Den slås til af hostingudbyderen eller serveradministratoren, så spørg dem om et udtræk for et bestemt tidsrum.

6. Verifikation

Diagnosen er færdig, når du kan pege på komponenten bag den langsomme side, rettelsen er målt på samme side før og efter (gerne tre kørsler hver), og Query Monitor er afinstalleret igen.

• Databasetiden og antallet af queries på den målte side er faldet.
• Ingen nye PHP-fejl eller advarsler i Query Monitors fejlpanel.
• Siden fungerer stadig: filtre, søgning og kurv er testet.
• Pluginnet og eventuel db.php er fjernet igen.

Notér fundet i jeres driftslog: „plugin X’s statistikmodul kostede 400 ms på kategorisiderne“ er guld værd, næste gang nogen overvejer at slå modulet til igen.

Læs også

• Hub: WordPress performance og cache
• Langsomt wp-admin
• Høj TTFB i WordPress
• Object cache med Redis
• Databaseoprydning i LiteSpeed Cache
• WordPress hosting hos Hostious – Redis object cache understøttes fra WP StartUp

Ofte stillede spørgsmål om Query Monitor

Kan jeg have Query Monitor kørende på live?

Kortvarigt, ja – panelet vises kun for administratorer, og besøgende mærker næsten intet. Men det tilføjer selv måle-overhead, så brug det som termometer: ind, mål, ud.

Hvad er et „normalt“ antal queries?

Som tommelfingerregel ligger en slank side på 30–100 og komplekse WooCommerce-sider gerne på 100–200. Tallet alene dømmer ikke – 200 hurtige kald kan være fint, mens 40 med ét på 800 ms er et problem. Kig på tid før antal.

Virker Query Monitor sammen med cache?

Ja – men husk, at page-cachede visninger slet ikke kører queries. Mål som logget ind (cache-bypass) eller på ucachebare sider som checkout og søgning – det er alligevel dem, databasetiden gør ondt på.

Hvornår markerer Query Monitor en query som langsom?

Som standard, når den tager mere end 0,05 sekunder. Tærsklen kan ændres med konstanten QM_DB_EXPENSIVE i wp-config.php, men standarden er et godt udgangspunkt.