Azért nem találsz erre nagyon "részletes" leírásokat mert hiányzik túl sok információ ahhoz hogy megértsd. Megpróbálom leírni a dolgot ami belefér 5 percbe:

A feleslegesen nagy mezők feleslegesen nagy memóriát használnak. Az adat betöltésénél egy bejegyzés amiben van 10 ilyen adat 2560 byte-ot fog elfoglalni. Ez önmagában nem tűnik soknak, de amikor egy select 100 ilyen adatot hoz ki akkor ez 256000 byte, ami 250 kB-ba fér el. Ezzel szemben az adat pl lehetne egy uuid, 3 int, 3 varchar 64 karakter alatt és 3 varchar 255-ig, ami 991 byte, azaz ugyan az a lekérdezés mindössze 99100 byte, 97 kB. Miért számít ez? Több száz GB memória van a szerverben! Viszont az a több száz GB még mindig csak lapozófájlokban van, amiket a szerver egy egységként kezel. Egy lapozófájl 4 kB, azaz az egyik megoldás 63 a másik 25 lapozófájl. Ez azt jelenti hogy a szerver \~2,5-szer annyi memória olvasást kell elvégezzen egyetlen átlagos méretű query-hez, azaz hiába az erősebb hardver, hiába a nagyobb memória, nagyságrendileg a lekérés 2,5-szer lassabb lesz mint lehetne. Csak az eredmény összeszedésében.

Egy másik vetülete az indexelés, tegyük fel hogy ezeknek az értékeknek valamelyike egy primary vagy foreign key. Ez esetben indexelve van, ami egy bináris fában van tárolva. A bináris fa értékeket és mutatókat tárol, ebben az esetben az érték lehet egy 255 varchar ami 256 byte, vagy lehet egy int ami 4 byte. A pointer ebben az esetben 8 byte, lehetne más is, de vegyük egyszerűre. A bináris fa szintekben tárol adatokat, amikor egy új elemet kell beszúrni akkor a fának egy új node-ja készül, optimalizálás miatt egy lapozófájl több node-t tartalmaz. A 4kB tartalmaz 15 vagy 341 elemet. A fát bejárni annyi ideig tart ahány lépést meg kell tenni ahhoz hogy eljussunk a keresett végső elemhez. Ha lapozófájlonként 15 elem van, akkor 1M bejegyzésből 5+ lépés megkeresni, míg 341 elem esetén 2+. Az is sokat számít hogy mekkora is ez a teljes index, az első változatban az index 285+ MB, a másodikban 11+ MB.

Ezek még lehet így sem néznek ki túl nagy számoknak, de egy viszonylag egyszerű db-ben százával vannak ilyen mértékű indexek, és sok ezer bejegyzés van lekérve másodpercenként. Mármint ha nem komolytalan a termék. 10 perc lett.

És ez csak két vetülete, ami a teljesítményt közvetlen érinti. Van még egy rakás másik probléma is vele, remélem nem fogsz a karriered következő 20 évében sem DB-kkel dolgozni.