Bazele de date sunt depozite de informații specializate și lucrăm cu acestea, operăm pe baza conceptelor de seturi de date și a operațiilor pe aceste date, uitând că în spatele lor este ascuns un echipament real. Creând o interogare SQL, înțelegem că toate acțiunile de pe tabele se realizează simultan, deoarece conceptul de timp din comenzile limbii SQL lipsește. Atunci când baza noastră de date este mică, probabil că nu observăm că serverul bazei de date are nevoie de timp pentru a procesa tabelul specificat, pentru a găsi linia necesară, pentru a recupera înregistrările necesare. Dar, odată cu creșterea informațiilor stocate în baza de date, această problemă devine din ce în ce mai vizibilă și, la un moment dat, devine clar că trebuie luate măsuri speciale. Începem să creștem performanța serverului nostru, punând mereu hardware mai rapid sau încercând să personalizăm un server existent, pentru a stoca performanța maximă din acesta, cu un scop în vedere - pentru a accelera executarea cererilor către baza noastră de date.
Dar, înainte de a analiza întrebarea la nivelul "fizic", este necesar să aflăm dacă este imposibil să folosiți anumite posibilități oferite de serverul de bază de date în sine. Foarte des, motivul executării lente a interogării este că tabelele nu sunt indexate. În mod tipic, dacă tabelele nu au indexuri, în majoritatea cazurilor este puțin probabil să îmbunătățească în mod semnificativ performanța bazei de date în alte moduri.
Dacă utilizați indexuri, serverul bazei de date va extrage rapid date
Luați în considerare modul în care tabela indexului poate accelera procesarea cererilor. Tabelul care nu are intrări din index sunt stocate într-un mod haotic, și atunci când încearcă să preia serverul de baze de date de informații va scana toate înregistrările pentru a stabili potrivirea cu condiții. De exemplu, luați baza de date server MySQL. în care sunt stocate informații despre bunuri. Să presupunem că avem nevoie pentru a obține toate rândurile de bunuri produse într-o anumită țară, iar în cazul în care această operațiune este efectuată în mod frecvent, în loc de iterarea prin toate liniile putem să indice tabelul cu elementele de mărfuri de pe teren care conține numărul country_id țării. Indexul creat va conține o înregistrare a fiecărui rând din tabel, iar intrările sale vor fi clasificate în funcție de câmpul country_id. Acum, când cererile de server de baze de date pot afla ce va fi nevoie de înregistrări din index, iar dacă avem nevoie de o țară cu numărul 5, este atins în indicele de până la numărul 6, serverul de baze de date se poate opri în căutarea - deoarece liniile cu numărul 5 în index este în mod clar mai mult nu va.
În mod similar, fiecare server de baze de date, există algoritmi pentru a găsi rapid rânduri în mijlocul listei de index care vă permite să optimizați căutarea pentru siruri de caractere necesare. Exemplul de mai sus nu explică beneficiile creării unui indice, de exemplu, pentru a sorta tabelul de acest domeniu, și păstrați-l în această formă. Da, o astfel de decizie ar putea fi aplicată în cazul în care au fost făcute toate cererile de căutare pe acest domeniu, dar am putea avea nevoie de sortare, și în alte domenii, astfel încât să putem crea un tabel mai mulți indici pentru cele mai populare interogări - de exemplu, pentru cantitatea de bunuri, sa preț și alți parametri.
Atunci când selectați informații din mai multe tabele, indicii sunt chiar mai eficienți
Atunci când se utilizează indicii, este necesar să se țină seama de neajunsurile lor
Pe lângă optimizarea interogărilor cu clauze WHERE, indicii pot beneficia și în alte cazuri. Evident, sortarea datelor selectate va fi și mai rapidă la indexarea peste acest câmp. De asemenea, prelevarea de date va fi mai rapidă atunci când se utilizează funcțiile agregate MIN () și MAX () pentru a obține valorile maxime și minime pentru grupările de linii. În unele cazuri, dacă doriți să obțineți informații pe care indexul însuși le poate furniza, nu se realizează deloc accesul la tabela de baze de date. Poate fi o concepție greșită că trebuie să indexați fiecare câmp în tabel - nu va fi mai rău. Nu este așa - indicii, în ciuda tuturor beneficiilor lor evidente, au unele dezavantaje. Cea mai evidentă problemă este că fișierul oricărui index ocupă un anumit loc pe disc și deoarece nevoia de a utiliza indexuri este cea mai relevantă pentru tabelele mari, fișiere index index suplimentare vor crește cu acesta.
A doua problemă constă în faptul că indicii ca informația de selectare a vitezei și încetini funcționarea adăugarea, editarea și ștergerea înregistrărilor - de fapt, în acest caz, este necesar să se facă schimbări în toate indicii ale variabilei tabel. Există, de asemenea, încă câteva linii directoare, care poate crește eficiența indicelui, minimizând în același timp punctele slabe ale acestora. O recomandare a fost deja menționat: să indice următoarele domenii care sunt căutate, și nu pot fi selectate, care este un bun candidat pentru indexare ar fi domeniul menționat în starea în care. De asemenea, rețineți că indexurile sunt mult mai eficiente pentru câmpurile cu valori unice. Dacă câmpul conține mai multe valori identice, indicele nu se poate justifica. Când creați indici în special pentru câmpurile de caractere lung, este necesar să se analizeze - este posibil să se asigure că cheia nu este unic pe toată suprafața câmpului, iar primele 10-20 de caractere din acest domeniu, care salvează foarte mult dimensiunea fișierului de index și pentru a asigura accelerarea punerii în aplicare a cererilor. Este recomandată o constrângere similară pentru câmpurile de caractere, iar pentru câmpurile tip TEXT și BLOB este obligatorie.
Foarte des, dacă ați creat indexul nu pentru un câmp, ci pentru mai multe câmpuri simultan, este posibil să îl utilizați pentru eșantioane și în alte cazuri. În acest caz, se folosește regula "stânga". De exemplu, pentru o masă cu un produs, am creat un index pentru țara, categoria, cantitatea câmpurilor - de exemplu, pentru a sorta tabelul în ordinea respectivă. Același index poate fi folosit și în acele cazuri când avem nevoie de un index pentru căutarea câmpului țării, precum și, dacă este necesar, de un index pentru sortarea simultană pe câmpuri de țară și de categorie. Prin urmare, dacă creați un index pentru mai multe câmpuri, atunci când adăugați un nou index, ar fi frumos să verificați dacă acesta duplică pe cele existente.
Creați indici după cum este necesar
Puteți crea un index pentru tabel atât la momentul creării sale, cât și după aceea adăugați-l, urmând regula simplă pe care ar trebui să o creați indiciile după cum este necesar. La crearea unei tabele, câmpul care oferă unicitatea trebuie declarat cu câmpurile cheie PRIMARY KEY sau UNIQUE, care creează automat un index pentru acest câmp. Astfel de câmpuri nu pot conține valori duplicate sau NULL egal și, prin urmare, sunt procesate foarte rapid. În mod similar, când creați un tabel, puteți specifica un cuvânt cheie
INDEX index_name list_fields.
unde toți parametrii după cuvântul cheie INDEX sunt opțional. Dar o astfel de oportunitate este folosită extrem de rar - este mult mai des necesară adăugarea unui indice la un tabel existent. Pentru a face acest lucru, puteți utiliza instrucțiunea ALTER TABLE, care este utilizată pentru a modifica tabelele existente:
ALTER TABLE nume_tabel INDEX index_name field_list;
Indexul este creat de coloanele specificate în list_fields. Dacă index_name-ul nu este specificat, acesta este creat automat de numele primului câmp indexat. Pentru câmpurile de caractere, puteți micșora lungimea valorilor indexate prin specificarea numărului de caractere n pentru indexare în numele_nume (n) Astfel, pentru tabelul nostru, putem crea un index:
ALTER TABLE articole INDEX country_id;
Dacă nevoia de index a dispărut, atunci poate fi ușor eliminată prin specificarea numelui indexului:
ALTER TABLE articole DROP INDEX country_id;
Există, de asemenea, sinonime pentru aceste comenzi cu o sintaxă mai ușor de înțeles:
CREAȚI INDEX index_name ON table_name list_fields;
DROP INDEX index_name ON tabel_name;