1. Pentru a optimiza interogarea, ar trebui să încerci să eviți scanarea completă a tabelelor și mai întâi să iei în considerare crearea unui index pentru coloanele implicate în unde și ordine după .
2. Încercați să evitați judecata de valoare nulă asupra câmpurilor din clauza where, altfel motorul va renunța la utilizarea indicilor și va efectua scanarea completă a tabelelor, cum ar fi:
Selectează ID din T, unde num este nul
Poți seta valoarea implicită de 0 pe num, să te asiguri că nu există nicio valoare nulă în coloana num din tabel și apoi să interogezi astfel:
selectează ID din t, unde num=0
3. Încercați să evitați folosirea operatorilor != sau <> în clauza where, altfel motorul va renunța la utilizarea indicilor și va efectua scanarea tabelului complet.
4. Ar trebui să încerci să eviți folosirea OR în clauza where pentru a se alătura condiției, altfel motorul va renunța la utilizarea indicilor și va efectua o scanare completă a tabelului, cum ar fi:
selectează ID din t, unde num=10 sau num=20
Poți interoga astfel:
selectează ID din t, unde num=10
Uniunea tuturor
selectează ID din t unde num=20
5.in și "not in" trebuie folosite cu prudență, altfel va duce la scanarea completă a tabelului, cum ar fi:
Selectează ID din t unde num în(1,2,3)
Pentru valori continue, nu folosi în dacă poți folosi între:
selectează ID de la t unde num între 1 și 3
6. Următoarea interogare va duce, de asemenea, la o scanare completă a tabelului:
Selectează ID de la T, unde numele este '%abc%'
Pentru a îmbunătăți eficiența, luați în considerare căutarea în text integral.
7. Dacă folosești un parametru într-o clauză where, acesta va provoca și o scanare completă a tabelului. Pentru că SQL rezolvă doar variabilele locale la rulare, dar optimizatorul nu poate amâna selecția planurilor de acces către timpul de execuție; Trebuie selectat în timpul compilației. Totuși, dacă un plan de acces este stabilit la compilare, valoarea variabilei rămâne necunoscută și, prin urmare, nu poate fi folosită ca element de intrare pentru selecția indicelui. Următoarele declarații vor fi scanate integral:
selectează ID de la t, unde num=@num
Poți forța interogarea să folosească un index în schimb:
selectează ID din t cu(index(index(index name)) unde num=@num
8. Încercați să evitați exprimarea câmpurilor în clauza where, ceea ce va determina motorul să abandoneze utilizarea indexurilor în favoarea scanării complete a tabelelor. De exemplu:
selectează ID de la t, unde num/2=100
Ar trebui să fie schimbat în:
selectează ID din t unde num=100*2
9. Încercați să evitați efectuarea operațiilor funcționale pe câmpurile din clauza where, ceea ce va determina motorul să abandoneze utilizarea indicilor în favoarea scanării complete a tabelelor. De exemplu:
Selectează ID din t unde substring(name,1,3)='abc' --ID nume care începe cu abc
selectează ID-ul de la T, unde datediff(day,createdate,'2005-11-30')=0--'2005-11-30' a generat ID-ul
Ar trebui să fie schimbat în:
Selectează ID-ul de la T unde numele este "ABC%"
selectează ID-ul de la T unde se creează>='2005-11-30' și creează<'2005-12-1'
10. Nu efectuați funcții, operații aritmetice sau alte operații de expresie în stânga "=" din clauza where, altfel sistemul s-ar putea să nu poată folosi corect indexul.
11. Când se folosește un câmp de index ca condiție, dacă indicele este un indice compus, atunci primul câmp din index trebuie folosit ca condiție pentru a asigura că sistemul folosește indicele, altfel indicele nu va fi folosit, iar ordinea câmpurilor trebuie să fie cât mai consistentă cu ordinea indicilor.
12. Nu scrie unele interogări lipsite de sens, cum ar fi generarea unei structuri de tabel goale:
Selectați col1,col2 în #t de la t unde 1=0
Acest tip de cod nu returnează niciun set de rezultate, dar consumă resurse de sistem, deci ar trebui schimbat în ceva de genul:
creează tabel #t(...)
13. De multe ori este o alegere bună să înlocuiești în cu exists:
selectează num din a unde num în (selectează num din b)
Înlocuiește cu următoarea afirmație:
Selectează num din a unde există (selectează 1 din b unde num=a.num)
14. Nu toate indexurile sunt valide pentru interogări, SQL se bazează pe datele din tabel pentru a optimiza interogarea, iar când coloana de index are o mulțime de duplicaturi de date, interogările SQL pot să nu folosească indexul, de exemplu un tabel are un sex, masculin, feminin aproape jumătate fiecare, deci chiar dacă indexul este construit pe sex, nu va juca un rol în eficiența interogării.
15. Cu cât mai mulți indici nu sunt mai buni, cu atât mai bine, indexul poate îmbunătăți cu siguranță eficiența selectării corespunzătoare, dar reduce și eficiența inserării și actualizării, deoarece indexul poate fi reconstruit la inserare sau actualizare, așa că modul de construire a unui index trebuie analizat cu atenție, în funcție de situația specifică. Este mai bine să nu ai mai mult de 6 indici într-un tabel și, dacă sunt prea mulți, să te gândești dacă este necesar să construiești indici pe unele coloane folosite rar.
16. Evitați actualizarea coloanelor de date indexate clusterizate cât mai mult posibil, deoarece ordinea coloanelor de date indexate clusterizate este ordinea fizică a stocării înregistrărilor tabelelor, iar odată ce valoarea coloanei se schimbă, acest lucru va duce la ajustarea ordinii întregii înregistrări de tabel, ceea ce va consuma resurse considerabile. Dacă aplicația ta trebuie să actualizeze frecvent coloanele de index clusterizate, trebuie să iei în considerare dacă ar trebui să construiești indicele ca un index clusterizat.
17. Încearcă să folosești câmpuri numerice și să nu proiectezi câmpuri care conțin doar informații numerice ca caractere, ceea ce va reduce performanța interogărilor și conexiunilor și va crește costul de stocare. Acest lucru se datorează faptului că motorul compară fiecare caracter din șir, unul câte unul, când procesează interogările și join-urile, în timp ce pentru tipurile numerice trebuie comparat o singură dată.
18. Folosiți varchar/nvarchar în loc de char/nchar cât mai mult posibil, pentru că, în primul rând, spațiul mai lung de stocare pe câmp poate economisi spațiu, iar în al doilea rând, pentru interogări, eficiența căutării într-un câmp relativ mic este evident mai mare.
19. Nu folosiți select * din t nicăieri, înlocuiți "*" cu o listă specifică de câmpuri și nu returnați câmpuri care nu sunt folosite.
20. Încearcă să folosești variabile de tabel în loc de tabele temporare. Dacă variabila tabelului conține o cantitate mare de date, rețineți că indexul este foarte limitat (doar indexul cheii primare).
21. Evitați crearea și ștergerea frecventă a tabelelor temporare pentru a reduce consumul de resurse din tabelele sistemului.
22. Tabelele temporare nu sunt inutilizabile, iar folosirea lor corespunzătoare poate face unele rutine mai eficiente, de exemplu, atunci când este nevoie să consulti repetat un set de date într-un tabel mare sau într-un tabel folosit frecvent. Totuși, pentru evenimente unice, cel mai bine este să folosești un tabel de export.
23. Când se creează un tabel temporar, dacă cantitatea de date introduse simultan este mare, atunci puteți folosi select into în loc de create table pentru a evita creșterea vitezei unui număr mare de loguri; Dacă cantitatea de date nu este mare, pentru a ușura resursele tabelului de sistem, ar trebui să creezi mai întâi tabelul și apoi să introduci.
24. Dacă se folosește un tabel temporar, asigurați-vă că ștergeți explicit toate tabelele temporare la sfârșitul procedurii stocate, trunchiați tabelul mai întâi, apoi eliminați tabelul, pentru a evita blocarea tabelului de sistem pentru o perioadă lungă.
25. Încearcă să eviți folosirea cursorului, deoarece eficiența cursorului este slabă; dacă datele operate de cursor depășesc 10.000 de linii, ar trebui să iei în considerare rescrierea.
26. Soluțiile bazate pe seturi trebuie căutate pentru a rezolva probleme înainte de a folosi metode bazate pe cursor sau tabele, care sunt adesea mai eficiente.
27. La fel ca tabelele temporare, cursoarele nu sunt inutilizabile. Folosirea cursoarelor FAST_FORWARD pentru seturi mici de date este adesea mai bună decât alte metode de procesare rând cu rând, mai ales dacă trebuie să consulți mai multe tabele pentru a obține datele de care ai nevoie. Rutinele care includ "total" în setul de rezultate sunt de obicei mai rapide decât cele executate cu cursorul. Dacă timpul de dezvoltare permite, pot fi încercate atât metode bazate pe cursor, cât și pe seturi pentru a vedea care funcționează mai bine.
28. Setați SETAȚI NOCOUNT ON la începutul tuturor procedurilor și declanșatoare stocate și SETAȚI NOCOUNT OFF la final. Nu este nevoie să se trimită DONE_IN_PROC mesaje clientului după executarea fiecărei instrucțiuni a procedurii stocate și a declanșării.
29. Încercați să evitați operațiunile mari de tranzacții și să îmbunătățiți capacitatea de concurență a sistemului.
30. Încercați să evitați să returnați date mari către client; dacă volumul de date este prea mare, ar trebui să luați în considerare dacă cererea corespunzătoare este rezonabilă. |
Postat pe 27.01.2015 20:09:54
|
|
|
