2026.08.21.
Weboldal fejlesztés és SEO

N plusz egy lekérdezés javítása WordPress optimalizálással.

Temesvári László

Az N+1 lekérdezési probléma: Láthatatlan sebességgyilkos a weboldaladban

Belegondoltál már, hogy a gyönyörű, új WordPress weboldalad miért tölt be lassan, annak ellenére, hogy minden „modernnek” tűnik? A problémák forrása gyakran nem a látványban, hanem a háttérben, az adatbázisban rejtőzik. Ma egy olyan technikai buktatóról fogok mesélni, amely kisvállalkozásoktól a nagyvállalati portálokig mindenkit érinthet: az N+1 lekérdezési problémáról. Ez nem csak fejlesztői zsargon, hanem egy konkrét, pénztárcába is ütő teljesítménykérdés.

Mi az az N+1 probléma? Egy analógia

Képzeld el, hogy rendelsz 100 könyvet egy könyvesboltból. Az N+1 probléma esetén a pultos egyszerre csak egy könyvet hoz neked: először lefut a polchoz a megrendelésedért (1 lekérdezés), majd minden egyes könyvnél külön-külön visszafut, hogy megkeresse a szerzőjének a nevét (plusz N lekérdezés). Ez hihetetlenül pazarló! Logikusabb lenne egyszerre, egyetlen út alkalmával elhozni mind a 100 könyvet a szerzőik nevével együtt.

A weboldalaknál ugyanez történik. Amikor megnyitod egy blog oldalt, ahol 20 bejegyzés és mindegyikhez a szerző neve van megjelenítve, a rosszul megírt kód 1 lekérdezést indít a bejegyzésekért, majd a ciklusban további 20-at a szerzők adatainak lekéréséhez. Ez 21 adatbázis-körülményt jelent, ahelyett, hogy 1 lett volna.

Hogyan néz ki a gyakorlatban? Egy WordPress/PHP példa

Tegyük fel, hogy egy egyedi WordPress sablonban vagy pluginban szeretnénk megjeleníteni a legfrissebb bejegyzéseket a szerzőikkel. Az N+1 problémát tartalmazó kód gyakran így néz ki:

// 1. Lekérdezzük a bejegyzéseket (EZ AZ "1")
$posts = get_posts(['numberposts' => 10]);

foreach ($posts as $post) {
    echo '<h2>' . $post->post_title . '</h2>';
    
    // 2. A cikluson BELÜL kérdezzük le a szerzőt minden bejegyzéshez (EZ A "+N")
    $author = get_userdata($post->post_author);
    echo '<p>Szerző: ' . $author->display_name . '</p>';
}

Itt a get_posts() hívás az „1”, a cikluson belüli get_userdata() hívások pedig a „+10”. Minél több bejegyzés, annál több felesleges adatbázis-terhelés.

A megoldás: Prefetchelés és összekapcsolt lekérdezések

A helyes megközelítés az, hogy egyetlen, okosabban megfogalmazott lekérdezéssel behozzuk az összes szükséges adatot előre. WordPress esetében erre vannak eszközeink, de az elv univerzális.

// Először gyűjtjük az összes szerző ID-t
$post_ids = [];
$posts = get_posts(['numberposts' => 10]);
foreach ($posts as $post) {
    $post_ids[] = $post->post_author;
}

// Egyetlen lekérdezés az összes releváns szerzővel
$author_ids = array_unique($post_ids);
$authors = get_users(['include' => $author_ids]);

// Szerzők tárolása egy gyorsan elérhető tömbben (ID => Név)
$author_lookup = [];
foreach ($authors as $author) {
    $author_lookup[$author->ID] = $author->display_name;
}

// Most a megjelenítés gyors és hatékony
foreach ($posts as $post) {
    echo '<h2>' . $post->post_title . '</h2>';
    // Itt már NINCS adatbázis-lekérdezés, csak egy tömb-keresés
    echo '<p>Szerző: ' . $author_lookup[$post->post_author] . '</p>';
}

Látod a különbséget? 1 vagy 2 jól tervezett lekérdezés ahelyett, hogy 11-et generálnánk. Ez hatalmas spórolás a szerveren és mérhetően gyorsabb oldalbetöltés a látogatónak.

Miért fontos ez neked, akár kisvállalkozó vagy?

1. Felhasználói élmény (UX): A lassú oldal = frusztrált látogató = magas visszautasítási arány. Egy 3 másodperc helyett 1 másodperc alatt betöltődő oldal óriási előnyt jelent. 2. Keresőoptimalizálás (SEO): A Google és társai számítanak az oldal sebességére a rangsorolásnál. Az N+1 probléma láthatatlanul rontja a SEO pozíciódat. 3. Szerverköltségek: Minden felesleges adatbázis-lekérdezés terheli a szervert. Optimalizálva a kódot, kisebb, olcsóbb hosting csomagok is kielégítőek lehetnek, vagy több látogatót bír a meglévő infrastruktúra. 4. Skálázhatóság: Amikor növekszik a forgalom az oldalon, az optimalizált kód sokkal jobban „tartja a terhet”. A nem optimalizált rendszer pedig váratlanul leállhat egy forgalmi csúcs alatt.

A frontend oldalon sem szabad elfelejteni

Bár az N+1 klasszikus backend probléma, a frontend fejlesztésben is előfordulhat hasonló logika, például API hívásoknál. jQuery-val így kerülhetjük el:

// ROSSZ: Cikluson belüli API hívás
// $.each(posts, function(index, post) {
//     $.get('/api/author/' + post.authorId, function(author) {
//         // ...
//     });
// });

// JO: Összegyűjtjük az ID-ket, egyetlen összetett kérés
var authorIds = posts.map(function(post) { return post.authorId; });
var uniqueIds = [...new Set(authorIds)]; // Duplikátumok eltávolítása

$.ajax({
    url: '/api/authors',
    method: 'POST',
    data: { ids: uniqueIds },
    success: function(authorsBatch) {
        // Itt van minden szerző adata, összekötjük a bejegyzésekkel
        renderPostsWithAuthors(posts, authorsBatch);
    }
});

Gyakori buktatók és ellenőrzési tippek

* „De nálam működik!” A probléma gyakran csak éles környezetben, nagyobb adatmennyiség mellett bukkan fel. Ne a fejlesztői gépen teszteld. * Lustán betöltött kapcsolatok ORM-eknél: Az Object-Relational Mapping eszközök (pl. egyes PHP keretrendszerekben) könnyen rejtett N+1 problémákat generálnak, ha nem használjuk expliciten a „with” vagy „join” függvényeket. * Hogyan derítsd fel? Kérdezd meg a fejlesztőcsapatodat, vagy nézd meg a weboldalad Query Monitor (WordPress) vagy Debug Bar pluginokkal. Ezek pontosan megmutatják, hány adatbázis-lekérdezést generál egy oldal.

Összegzés: Egyszerű elv, óriási hatás

Az N+1 lekérdezési probléma felismerése és kiküszöbölése nem csillagászat. Egy alapvető, de rendkívül hatékony optimalizálási lépés. Amikor legközelebb webfejlesztővel beszélsz egy új weboldal készítés vagy WordPress weboldal készítés projektről, kérdezd meg tőle, hogyan gondoskodnak az adatbázis-lekérdezések hatékonyságáról. Egy jó fejlesztő nem csak a látványra, hanem a láthatatlan, de érezhető teljesítményre is fogékony.

Egy ilyen beállításokkal készült honlap nem csak szép, hanem gyors, költséghatékony és jövőbiztos is – ami végül is minden vállalkozás álma, nemde?

A weboldalon megjelenő szöveges és vizuális tartalmak előállításához mesterséges intelligenciát (AI) használunk.

Kapcsolódó cikkek