SQL Query Performance
în acest caz particular, nu veți observa o diferență uriașă, deoarece 30.000 de rânduri nu sunt prea greu de procesat pentru baza de date. Cu toate acestea, dacă ați vorbi despre sute de milioane de rânduri sau mai multe, ați vedea o îmbunătățire vizibilă prin agregarea înainte de a vă alătura. Când faceți acest lucru, asigurați — vă că ceea ce faceți este logic consecvent-ar trebui să vă faceți griji cu privire la acuratețea muncii dvs. înainte de a vă îngrijora de viteza de rulare.
13 sfaturi pentru performanța interogării
nu uitați să prefixați numele obiectelor (adică. tabel, procedură stocată, vizualizare) cu numele proprietarului/schemei.
motiv: Dacă numele proprietarului/schemei nu este furnizat, motorul SQL Server încearcă să-l găsească în toate schemele până când obiectul îl găsește. Motorul SQL Server nu va căuta tabelul în afara proprietarului / schemei sale dacă este furnizat numele proprietarului/schemei.
operatorul *
nu utilizați operatorul * în instrucțiunile de selectare. În schimb, utilizați numele coloanelor.
motiv: SQL Server scanează toate numele coloanelor și înlocuiește * cu toate numele coloanelor tabelului(tabelelor) din instrucțiunea SQL SELECT. Furnizarea de nume de coloane evită această căutare și înlocuire și îmbunătățește performanța.
coloane Nullabile
evitați utilizarea nu în atunci când se compară cu coloane nullabile. Utilizarea nu există în schimb.
motiv: când nu este utilizat în interogare (chiar dacă interogarea nu returnează rânduri cu valorile null), SQL Server va verifica fiecare rezultat pentru a vedea dacă este null sau nu. Utilizarea nu există nu va face comparația cu nulls. De asemenea, nu există returnează doar două stări (adevărat sau fals), în timp ce nu se poate întoarce până la trei stări (adevărat, fals, NULL) și s-ar putea să nu vă dea rezultatul pe care îl așteptați.
variabile de tabel și se alătură
evitați utilizarea variabilelor de tabel În se alătură. Utilizați tabele temporare, CTEs (expresii comune de tabel) sau tabele derivate în joins în schimb.
motiv: chiar dacă variabilele tabelului sunt foarte rapide și eficiente într-o mulțime de situații, motorul SQL Server îl vede ca pe un singur rând. Din acest motiv, SQL va produce un plan de execuție care va efectua oribil atunci când este utilizat în se alătură.
nume proceduri stocate
nu începeți numele procedurii stocate cu sp_.
motiv: când procedura stocată este denumită sp_ sau SP_, SQL Server verifică întotdeauna în baza de date system/master chiar dacă este furnizat numele proprietarului/schemei. Furnizarea unui nume fără SP_ unei proceduri stocate evită această verificare inutilă în baza de date system / master din SQL Server.
Utilizare set NOCOUNT ON
Utilizare SET NOCOUNT on cu operații LMD.
motiv: la efectuarea operațiilor LMD (adică. Inserare, ștergere, selectare și actualizare), SQL Server returnează întotdeauna numărul de rânduri afectate. În interogări complexe cu o mulțime de alăturări, aceasta devine o problemă uriașă de performanță. Utilizarea SET NOCOUNT on va îmbunătăți performanța, deoarece nu va ține evidența numărului de rânduri afectate.
evitați să folosiți GROUP BY, ORDER BY și DISTINCT
evitați să folosiți GROUP BY, ORDER BY și DISTINCT ori de câte ori este posibil.
motiv: când se utilizează GROUP BY, ORDER BY sau DISTINCT, motorul SQL Server creează un tabel de lucru și pune datele pe tabelul de lucru. După aceea, organizează aceste date în tabelul de lucru, așa cum este solicitat de interogare, apoi returnează rezultatul final.
verificați indexurile
ar trebui să existe indexuri pe toate câmpurile utilizate în porțiunile WHERE and JOIN ale instrucțiunii SQL.
motiv: când câmpurile nu sunt indexate, SQL Server va face de obicei o Scanare completă a tabelului și acest lucru poate reduce performanța. Cu excepția cazului în care tabelul este foarte mic, o scanare a tabelului tinde să producă cea mai slabă performanță din toate tipurile de citire a bazei de date.
utilizați același tip de date pe JOIN și unde clauzele
acest lucru este mai ușor de spus decât de făcut, în funcție de permisiunile dvs. pentru a face modificări la schemă.
motiv: atunci când se alătură sau se compară două câmpuri cu diferite tipuri de date, SQL trebuie să facă o conversie on-the-fly a câmpului înainte de a putea face o comparație, chiar dacă câmpurile sunt indexate. Dacă tipurile de date nepotrivite sunt inevitabile, încercați să aruncați tipul de date mai mare la tipul de date mai mic ori de câte ori este posibil.
evitați utilizarea câmpurilor calculate în JOIN și unde clauzele
acest lucru se poate face prin crearea unui câmp cu valorile calculate utilizate în join pe tabel. Vezi mai jos.