Mysql indexek és adat mintavétel gyorsítása - verem túlcsordulás oroszul
Egy egyszerű adattáblázat jön létre:
Amint ebből a példából látható, egyedi kulcsokat hoz létre az id oszlopban (az AUTO_INCREMENT rovására). A user_id mező egyedi felhasználói azonosító értékeket is tartalmaz, amelyeket a forgatókönyv (a mt_rand használatával) generál a regisztráció során a fiókomban.
A mintavételhez az alábbi kérést kell tennie:
Gondoltam arra, hogy az adattáblázatomban indexeket használtam fel a mintavétel gyorsítására. A dokumentáció szerint:
Az index jelenléte jelentősen növelheti bizonyos lekérdezések végrehajtásának sebességét, és lerövidítheti a fizikai vagy logikai rendelések miatt szükséges adatok keresését.
Kell-e létrehozni indexeket a user_id mezőhöz, hogy felgyorsítsa a több millió rekord mintavételezését, ha az összes azonosító értéke ezen a területen már egyedülálló?
Ha mindez szükségessé válik, milyen indexet kell létrehozni: fürtözött vagy nem fürtözött (nem értem meg teljesen a köztük lévő különbségeket)?
A WHERE klauzula (a fenti példában) a DBMS-t rendezi a táblázat összes rekordja között? Vagy adatbázis jog vonatkozik kifejezetten csak azokat a rekordokat, amelyek megfelelnek a keresési feltételeknek (user_id = 28572), anélkül, hogy a többi rekord?
április 24-15-én 6:38 órakor
Kell-e létrehozni indexeket a user_id mezőhöz, hogy felgyorsítsa a több millió rekord mintavételezését, ha az összes azonosító értéke ezen a területen már egyedülálló?
Igen, meg kell - mert gyakran választasz az asztaltól a mező tartalma alapján. Mivel az architektúrát az erre a területre eső adatok egyedisége okozza, jó ötlet lenne használni az UNIQUE indexet. Ha a mezőbe egyedi index van hozzárendelve, akkor az adatbázis nem engedélyezi a rekord ismételt értékű beillesztését. Ez a lépés a normalizálás felé.
Ha mindez szükségessé válik, milyen indexet kell létrehozni: fürtözött vagy nem fürtözött (nem értem meg teljesen a köztük lévő különbségeket)?
A WHERE záradék arra készteti a DBMS-t, hogy végigmenjen a táblázatban szereplő összes rekordon?
Igen. Tudják ezt (és több) kitöltésével a kérelem a kulcsszó fejtse előtte (fejtse SELECT * FROM. WHERE. ORDER BY. LIMIT.). Ha a minta a beteg állapotával és az állapot magában foglalja a területen nem terjed ki a megfelelő index - MySQL teljesítménye valószínű polnotablichnoe szkennelés. Ez drága az input-output szempontjából művelet, így az illetékes igazítás indexek - a fél siker az adatbázis optimalizálás a jobb teljesítmény.
Hozzáteszem a @Mirdin válaszhoz
A gyorsítótár index fizikailag rendezi a táblázatot index alapján. Leggyorsabb (kereséshez). Nyilvánvaló, hogy csak egy lehet. A PK mindig az alapértelmezett fürtözött index.
Lekelheti a végrehajtási időt 50% -kal (átlagosan), ha hozzáadja a LIMIT 0,1 értéket - mert Az adatbázis nem tudja az oszlop egyediségét. Korlát nélkül az asztal összes értéke megy keresztül, még akkor is, ha már talál egy mérkőzést.
De helyesen tegyük ezt az oszlopot:
Általában, ahogyan valószínűleg megérted, nincs határozott válasz. Végezzen egymás után egy indexet, és nézze meg az eredményt. Lehetséges, hogy egy index elég lesz.
válaszolt 24 április 15-én 7:34-kor
Köszönjük a választ. Most látom a különbséget a fürtözött és a nem fürtözött indexek között. Utolsó kérdésem van az egyesített indexekkel kapcsolatban. Nevezetesen. A feladattól függően az adatbázis egy vagy több mezőből származhat. Helyes-e az egyes mezők számára külön indexek létrehozása és egy (kombinált) index minden mező számára? - StasHappy 24: 15-kor, 7: 45-kor
A kérések függvénye. Az EXPLAIN segít megtalálni a választ. - AntonioK 24 április 15-én, 07:51-kor
@stashappy válaszul adtam hozzá. - Petr Abdulin április 24-15-én 8: 05-kor
Boldoglak barátokat. Megpróbálok más lehetőségeket. Megnézem, hogy az EXPLAIN visszatér, és hasonlítsa össze az eredményeket. - StasHappy április 24-15-én 8: 15-kor
- Igen, ha gyakran szűri ezt a mezőt.
- Nem fürtözött, már van PK.
- A szerver nem rendelkezik a mágia, így ha nincs index, megy át az összes rekordot a táblázatban, ha a séta a szerkezet által végrehajtott index, de ez nem „csak kimondottan csak azokat a rekordokat.”
Ui Általában azt írta, hogy a MySQL specifikus, lehetnek különbségek.
válaszolt április 24-én, 15-kor 7: 02-kor