SQL Query Performance
i det här fallet kommer du inte att märka en stor skillnad eftersom 30 000 rader inte är för svåra för databasen att bearbeta. Men om du pratade om hundratals miljoner rader eller mer, skulle du se en märkbar förbättring genom att aggregera innan du gick med. När du gör detta, se till att det du gör är logiskt konsekvent — du bör oroa dig för noggrannheten i ditt arbete innan du oroar dig för körhastighet.
13 tips för FRÅGEPRESTANDA
kom ihåg att prefixa objektnamn (dvs. tabell, lagrad procedur, vy) med dess ägare/schema namn.
orsak: om namnet ägare/schema inte anges försöker SQL Server-motorn hitta det i alla scheman tills objektet hittar det. SQL Server engine kommer inte att söka efter tabellen utanför dess ägare/schema om ägaren / schema namn tillhandahålls.
operatorn *
använd inte operatorn * i Select-satserna. Använd istället kolumnnamn.
orsak: SQL Server söker efter alla kolumnnamn och ersätter * med alla kolumnnamn i tabellen / tabellerna i SQL SELECT-satsen. Att tillhandahålla kolumnnamn undviker denna sökning och ersätter och förbättrar prestanda.
Nullable Columns
Undvik att använda inte vid jämförelse med nullable columns. Använd inte existerar istället.
orsak: när inte IN används i frågan (även om frågan inte returnerar rader med null-värdena) kommer SQL Server att kontrollera varje resultat för att se om det är null eller inte. Att använda inte existerar kommer inte att göra jämförelsen med nulls. Dessutom returnerar NOT EXISTS endast två stater (sant eller falskt), medan inte IN kan returnera upp till tre stater (sant, falskt, NULL) och kanske inte ger dig det resultat du förväntade dig.
tabellvariabler och kopplingar
Undvik att använda tabellvariabler i kopplingar. Använd tillfälliga tabeller, CTE (vanliga Tabelluttryck) eller härledda tabeller i kopplingar istället.
orsak: även om tabellvariabler är mycket snabba och effektiva i många situationer ser SQL Server-motorn det som en enda rad. På grund av denna anledning kommer SQL att producera en exekveringsplan som kommer att fungera hemskt när den används i kopplingar.
lagrade Procedurnamn
börja inte ditt lagrade procedurnamn med sp_.
orsak: när den lagrade proceduren heter sp_ eller SP_, kontrollerar SQL Server alltid i system / master-databasen även om ägaren/schemanamnet tillhandahålls. Att ge ett namn utan SP_ till en lagrad procedur undviker denna onödiga kontroll i system / master-databasen i SQL Server.
använd SET NOCOUNT på
använd SET NOCOUNT på med DML-operationer.
orsak: när du utför DML-operationer (dvs. Infoga, Ta bort, markera och uppdatera) returnerar SQL Server alltid antalet berörda rader. I komplexa frågor med många kopplingar blir detta ett stort prestationsproblem. Att använda SET NOCOUNT ON kommer att förbättra prestanda eftersom det inte kommer att hålla reda på antalet rader som påverkas.
Undvik att använda GROUP BY, ORDER BY och DISTINCT
Undvik att använda GROUP BY, ORDER BY och DISTINCT när det är möjligt.
orsak: när du använder GROUP BY, ORDER BY eller DISTINCT skapar SQL Server engine en arbetsbord och lägger data på arbetsbordet. Därefter organiserar den dessa data i arbetstabellen enligt begäran av frågan, och sedan returnerar det slutliga resultatet.
kontrollera index
det bör finnas index på alla fält som används i var och gå delar av SQL-satsen.
orsak: när fält inte indexeras gör SQL Server vanligtvis en fullständig tabellsökning och detta kan minska prestanda. Om inte tabellen är mycket liten tenderar en tabellsökning att ge den värsta prestandan av alla typer av databasläsningar.
Använd samma datatyp på JOIN och där klausuler
Detta är lättare sagt än gjort beroende på dina behörigheter för att göra ändringar i schemat.
orsak: när du sammanfogar eller jämför två fält med olika datatyper måste SQL göra en on-the-fly-konvertering av fältet innan det kan göra en jämförelse, även om fälten är indexerade. Om felaktiga datatyper är oundvikliga, försök att kasta den större datatypen till den mindre datatypen när det är möjligt.
Undvik att använda beräknade fält i JOIN och där klausuler
detta kan göras genom att skapa ett fält med de beräknade värdena som används i join på bordet. Se nedan.