SELECT * FROM membrii WHERE id = '1' - deci de ce indexul functioneaza mai repede? Ce face acest index aici? - bună_evening 20 mai 17 la 18:00
În principiu, indexul din tabel funcționează ca un indice în cartea (de unde a venit numele):
Să presupunem că aveți o carte despre bazele de date și doriți să găsiți informații despre, de exemplu, un depozit. Fără un index (fără nici un alt ajutor, cum ar fi un cuprins), va trebui să treceți prin pagini unul câte unul până când găsiți subiectul (aceasta este scanarea completă a mesei). Pe de altă parte, indicele este o listă de cuvinte cheie, astfel încât ar trebui să se refere la index și a vedea ce stocare este menționat la paginile 113-120, 231 și 354. Apoi, aveți posibilitatea să comutați la aceste pagini în mod direct, fără a fi nevoie pentru a căuta (indexul de căutare este oarecum mai rapid).
Desigur, cât de util este indexul depinde de multe lucruri - câteva exemple care utilizează comparația de mai sus:
- Dacă aveți o carte în baze de date și cuvântul "baza de date" este indexat, veți vedea că este menționat pe paginile 1-59,61-290 și 292-400. În acest caz, indexul nu ajută prea mult și poate trece mai repede paginile unul câte unul (în baza de date aceasta este "selectivitate scăzută").
- Pentru o carte de 10 pagini are nici un sens pentru a face indexul ca rezultat puteți obține o carte de 10 pagini cu prefixul index 5 pagini, asta e doar prostie - trebuie doar să scanați 10 pagini și să fie făcut cu ea,
- Indicele ar trebui să fie, de asemenea, util - de obicei, nu există nici un punct în indexarea, de exemplu, frecvența literei "L" pe pagină.
răspunsul dat de Piskvor în data de 20 mai 17 la ora 18:00
Primul lucru pe care ar trebui să știți este că indexurile sunt o modalitate de a evita scanarea unei mese complete pentru obținerea rezultatului pe care îl căutați.
Există diferite tipuri de indexuri și sunt implementate la nivel de stocare, astfel încât nu există un standard între acestea și depind, de asemenea, de mecanismul de stocare pe care îl utilizați.
InnoDB și indicele arborelui B +
Pentru InnoDB, cel mai frecvent tip de index este indicele B + Tree, care stochează elementele în ordine ordonată. În plus, nu este nevoie să accesați tabelul real pentru a obține valorile indexate, ceea ce accelerează interogarea.
"Problema" cu acest tip de index este că trebuie să interogați valoarea din stânga pentru a utiliza indexul. Deci, dacă indexul are două coloane, spune last_name și first_name, ordinea în care interogați aceste câmpuri este de mare importanță.
Deci, având în vedere următorul tabel:
Această interogare va utiliza indexul:
Dar următorul nu va fi
Deoarece mai întâi solicitați coloana first_name. Aceasta nu este coloana din stânga a indexului.
Acest ultim exemplu este și mai rău:
Deoarece acum comparați partea din dreapta a câmpului din dreapta în index.
Indicele hash
Acesta este un tip diferit de index, care, din păcate, suportă numai backendul de memorie. Este rapid, dar este util doar pentru o căutare completă, ceea ce înseamnă că nu o puteți folosi pentru operații precum>. <или LIKE.
Deoarece funcționează numai cu memoria internă, probabil că nu o veți folosi prea des. Cazul principal pe care îl pot aminti acum este că creați o tabelă temporară în memorie cu un set de rezultate dintr-un altul selectați și efectuați multe alte selecții în acest tabel temporar utilizând indici de hash.
Dacă aveți un câmp mare VARCHAR. Puteți să "emulați" utilizarea unui indice de hash atunci când utilizați un arbore B, creând o altă coloană și salvând un hash cu o valoare mare pe acesta. Să presupunem că stocați urlul într-un câmp și că valorile sunt suficient de mari. Puteți crea, de asemenea, un câmp întreg cu numele url_hash și utilizați o funcție hash, cum ar fi CRC32 sau orice altă funcție hash pentru hashing url când este lipită. Și atunci când trebuie să interogați această valoare, puteți face ceva de genul:
Problema cu exemplul de mai sus este că, deoarece funcția CRC32 generează un hash destul de mic, veți întâlni mai multe coliziuni în valorile hashed. Dacă aveți nevoie de valori exacte, puteți remedia această problemă făcând următoarele:
Merită totuși să distrugi lucrurile, chiar dacă numărul de coliziune este ridicat, deoarece veți efectua doar oa doua comparație (șir) cu hashes repetate.
Din păcate, utilizând această metodă, trebuie să loviți tabelul pentru a compara câmpul url.
împacheta
Unele fapte pe care le puteți lua în considerare de fiecare dată când doriți să discutați despre optimizare:
O comparație între cifre este mult mai rapidă decât compararea șirurilor. Acest lucru poate fi ilustrat de exemplul de emulare a indexului hash în InnoDB.
Poate că adăugarea mai multor pași în proces o face mai rapidă, nu mai lentă. Acest lucru poate fi ilustrat de faptul că puteți optimiza SELECT. rupându-l în două etape, făcând prima salvând valorile din tabelul nou creat în memorie și apoi efectuând interogări mai grele la acest al doilea tabel.
MySQL are și alți indicatori, dar cred că B + Tree este cel mai folosit și hash unul dintre ei este bine de știut, dar puteți găsi alții în documentația MySQL.
Vă recomandăm cu insistență să citiți cartea "MySQL de înaltă performanță", răspunsul de mai sus a fost în mod cert bazat pe capitolul despre indici.
Răspuns dat de clarete la 20 mai 17 la 18:00
În aceste cazuri, beneficiile vor fi următoarele întrebări: 1. last_name SELECT, first_name de la persoana UNDE last_name = "Constantin" 2. SELECT nume, prenume de la persoană UNDE last_name LIKE "% Constantin" - Akshay Țâru 20 mai '17, la ora 18:00
Mi-a crescut ratingul pentru că erați la 127 și răspundeți la numărul 1 la 256. Nu puteam să fac totul într-un mod binar frumos și curat. - pbarney 20 mai 17 la 18:00
Aceasta a fost o informație nouă pentru mine: "Ordinul prin care solicitați aceste domenii este de o mare importanță." Mulțumesc. - Khatri 20 mai la ora 18:00
Îmi place acest răspuns mai mult decât răspunsul acceptat. mulțumiri - Rahul Goyal 20 mai 17 la 18:00
Deci, ce este un index? Indicele este o structură de date (cel mai adesea un arbore B), care stochează valori pentru o anumită coloană din tabel. Indexul este creat în coloana din tabel. Prin urmare, rețineți că indexul constă din valorile coloanelor dintr-o tabelă și că aceste valori sunt stocate în structura de date. Un index este o structură de date - amintiți-vă acest lucru.
Să începem tutorialul nostru și să explicăm de ce aveți nevoie de un indice de bază de date trecând printr-un exemplu foarte simplu. Să presupunem că avem un tabel de baze de date numit Angajat cu trei coloane - Employee_Name, Employee_Age și Employee_Address. Să presupunem că tabela Employee conține mii de rânduri.
Să presupunem acum că vrem să facem o interogare pentru a găsi toate detaliile oricărui angajat numit "Isus"? Deci, am decis să rulați o interogare simplă:
Ce se va întâmpla fără indexul de pe masă?
Cum poate un indice de baze de date să contribuie la performanță
Care structură de date este un index?
Arborii B sunt cele mai utilizate structuri de date pentru indexuri. Motivul pentru care arborele B este cea mai populară structură de date pentru indexuri se datorează faptului că acestea sunt eficiente în timp - întrucât căutarea, ștergerea și inserarea pot fi efectuate în timp logaritmic. Și un alt motiv important pentru care arborii B sunt utilizați mai des este că datele stocate în interiorul arborelui B pot fi sortate. RDBMS determină, de obicei, care structură de date este de fapt utilizată pentru index. Dar, în anumite scenarii cu RDBMS specifice, puteți specifica structura de date pe care doriți să o utilizați pentru baza de date atunci când creați indexul însuși.
Cum îmbunătățește indexul performanța?
Cum se creează un index în SQL:
Iată ce ar arăta SQL-ul real ca să creezi un index în coloana Employee_Name din exemplul nostru mai devreme:
Cum se creează un index cu mai multe coloane în SQL:
De asemenea, am putea crea un index pe două coloane din tabelul Angajat, după cum se arată în acest SQL:
răspuns dat de Pankaj katiyar la data de 20 mai 17 la ora 18:00
@ user64141 În mod ideal, acest index este utilizat pentru a scurta timpul de căutare. Acestea fiind spuse, la sfârșitul zilei, valorile vor fi selectate din linia exactă. Nu le poți face parte din index. Dacă trebuie să căutați în mai multe valori ale coloanei, puteți crea un index compozit. Rândurile încă sunt selectate numai aici, valorile sunt selectate din șirul sursă. - Karthikeyan 20 mai la 18:00
Indexul unei baze de date, sau pur și simplu un index, ajută la accelerarea preluării datelor din tabele. Când solicitați date dintr-o tabelă, mai întâi MySQL verifică dacă există indici, atunci MySQL utilizează indicii pentru a selecta rândurile fizice de potrivire a tabelului în locul scanării întregului tabel.
Indexul bazei de date este similar cu indexul cărții. Dacă doriți să găsiți un subiect, parcurgeți mai întâi indexul, apoi deschideți pagina cu subiectul fără a naviga prin întreaga carte.
Este recomandat să creați un index pentru coloanele din tabel, de la care solicitați frecvent date. Rețineți că toate coloanele cheii primare se află automat în indexul principal al tabelului.
Dacă indexul ajută la accelerarea procesării interogărilor, de ce nu folosim indexuri pentru toate coloanele? Dacă creați un index pentru fiecare coloană, MySQL trebuie să creeze și să mențină un tabel de index. Ori de câte ori se fac modificări într-o intrare de tabel, MySQL trebuie să reconstruiască indexul, ceea ce necesită timp și, de asemenea, reduce performanța serverului de baze de date. Crearea unui index MySQL
Adeseori creați indexuri atunci când creați tabele. MySQL adaugă automat la index orice coloană declarată ca PRIMARY KEY, KEY, UNIQUE sau INDEX. În plus, puteți adăuga indexuri la tabele care au deja date.
Pentru a crea indexuri, utilizați instrucțiunea CREATE INDEX. Sintaxa instrucțiunii CREATE INDEX este următoarea: 1 2 3
Mai întâi, specificați un index pe baza tipului de tabel sau a mecanismului de stocare:
UNIQUE înseamnă că MySQL va crea o limită, astfel încât toate valorile din index să fie unice. O valoare dublă NULL este acceptabilă în toate sistemele de stocare, cu excepția BDB. Indicele FULLTEXT este acceptat numai de mecanismul de stocare MyISAM și este acceptat numai într-o coloană care are tipul de date CHAR, VARCHAR sau TEXT. Indexul SPATIAL susține o coloană spațială și este disponibil pe motorul de stocare MyISAM. În plus, valoarea coloanei nu trebuie să fie NULL.
Apoi, denumiți indexul și tipul acestuia după cuvântul cheie UTILIZĂRI, de exemplu, BTREE, HASH sau RTREE, de asemenea bazat pe mecanismul de stocare a tabelului.
Următoarele sunt mecanismele de stocare a tabelului cu tipurile corespunzătoare de indici autorizați: tipurile admise de stocare a datelor indexate MyISAM BTREE, RTREE InnoDB BTREE MEMORY / HEAP HASH, BTREE NDB HASH
În al treilea rând, declarați numele tabelului și coloanele listei pe care doriți să o adăugați la index. Exemplu de creare a unui index în MySQL
În baza de date de exemple, puteți adăuga coloana officeCode a tabelului angajaților la index utilizând instrucțiunea CREATE INDEX după cum urmează: 1
CREATE INDEX officeCode ON angajați (officeCode)
În plus față de crearea unui index, puteți șterge și indexul folosind instrucțiunea DROP INDEX. Interesant este că instrucțiunea DROP INDEX este de asemenea mapată la instrucțiunea ALTER TABLE. Următoarea este sintaxa pentru ștergerea indexului: 1
DROP INDEX index_name ON tabel_name
De exemplu, dacă doriți să eliminați indexul officeCode al tabelului angajaților pe care l-am creat mai sus, puteți rula următoarea interogare: 1
DROP INDEX officeCode ON angajați
răspunsul dat de șerif în data de 20 mai 17 la ora 18:00