Se creează un tabel simplu de date:
După cum puteți vedea din acest exemplu, cheile unice sunt create în coloana id (pe cheltuiala AUTO_INCREMENT). Câmpul user_id conține, de asemenea, valori de identificare utilizator unice generate de script (folosind mt_rand) în timpul înregistrării în contul meu.
Pentru eșantionare fac următoarea solicitare:
M-am gândit să folosesc indicii din tabelul de date pentru a accelera eșantionarea. Documentația spune:
Prezența unui index poate crește în mod semnificativ viteza de execuție a unor interogări și poate scurta timpul de căutare a datelor necesare datorită ordonării fizice sau logice.
Trebuie să creez indexuri pentru câmpul user_id pentru a grăbi eșantionarea a milioane de înregistrări, dacă toate valorile ID din acest câmp sunt deja unice?
Dacă este necesar același lucru, atunci ce indice ar trebui creat: grupat sau nu în cluster (nu înțelegeți destul de bine diferențele dintre ele)?
Clauza WHERE (în exemplul de mai sus) determină ca DBMS să sorteze toate înregistrările din tabel? Sau se bazează DBMS direct numai acele înregistrări care satisfac condițiile de căutare (user_id = 28572), fără a afecta restul înregistrărilor?
setat pe 24 aprilie '15 la 6:38
Trebuie să creez indexuri pentru câmpul user_id pentru a grăbi eșantionarea a milioane de înregistrări, dacă toate valorile ID din acest câmp sunt deja unice?
Da, trebuie să - pentru că veți alege de multe ori din tabel pe baza conținutului acestui câmp. Deoarece arhitectura este cauzată de unicitatea datelor care intră în acest domeniu, ar fi o idee bună să folosiți indicele UNIQUE. Dacă un câmp este atribuit unui index unic, baza de date nu va permite introducerea unei înregistrări cu o valoare dublă. Acest pas spre normalizare.
Dacă este necesar același lucru, atunci ce indice ar trebui creat: grupat sau nu în cluster (nu înțelegeți destul de bine diferențele dintre ele)?
Clauza WHERE provoacă DBMS-ul să treacă prin toate înregistrările din tabel?
Da. Puteți afla acest lucru (și mult mai mult) executând interogarea cu cuvântul cheie EXPLAIN înaintea lui (EXPLAIN SELECT * FROM FROM WHERE ORDER BY LIMIT.). Dacă este selectată o condiție și condiția include un câmp care nu este acoperit de un index adecvat, MySQL va efectua, cel mai probabil, o scanare completă a mesei. Este scump din punct de vedere al operării intrare-ieșire, astfel încât un aranjament competent al indexurilor este jumătate din succesul optimizării bazei de date pentru o muncă rapidă.
Voi adăuga răspunsul @Mirdin
Indicele cache organiză fizic tabelul după index. Cel mai rapid (pentru căutare). Este evident că el nu poate fi decât unul. PK este întotdeauna indexul implicit în grup.
Puteți scurta timpul de execuție cu 50% (în medie) dacă adăugați LIMIT 0,1 - pentru că Baza de date nu cunoaște unicitatea coloanei tale. Fără o limită, va trece prin toate valorile mesei, chiar dacă va găsi deja un meci.
Dar pe bună dreptate, faceți această coloană:
În general, după cum probabil înțelegeți că nu există un răspuns clar. Acționați secvențial, adăugați un index și examinați rezultatul. Este posibil ca un indice să fie suficient.
răspuns dat 24 Apr '15 la 7:34
Vă mulțumim pentru răspunsurile dvs. Acum văd diferența dintre indicii clusteri și cei fără cluster. Am o întrebare finală despre indicii combinați. Și anume. În funcție de sarcină, baza de date poate fi preluată din unul sau mai multe câmpuri. Este corect să creați indexuri separate pentru fiecare câmp și un index (combinat) pentru toate câmpurile? - StasHappy Apr 24 '15 la 7:45 am
Depinde de cereri. EXPLAIN vă va ajuta să găsiți răspunsul. - AntonioK 24 aprilie '15 la 7:51 am
@stashappy Am adaugat ca raspuns. - Petr Abdulin 24 aprilie '15 la 8:05
Vă binecuvântez Prieteni. Voi încerca diferite opțiuni. Voi vedea ce va reveni EXPLAIN, comparați rezultatele. - StasHappy Apr 24 '15 la 8:15 am
- Da, dacă filtrezi frecvent acest câmp.
- Nu sunt grupate, aveți deja PK.
- Serverul nu deține magie, așa că, dacă nu există nici un index, va trece prin toate înregistrările din tabel, dacă aveți plimbarea prin structura pusă în aplicare de index, dar nu este „doar se referă în mod specific numai la acele înregistrări.“
P.S. Scriit în general, este specific în MySQL pot exista diferențe.
răspuns dat 24 Apr '15 la 7:02 am
Trimiteți-le prietenilor: