1. För att optimera frågan bör du försöka undvika fullständig tabellskanning och först överväga att skapa ett index över kolumnerna i var och sortera efter.
2. Försök undvika nullvärdesbedömning på fält i where-klausulen, annars kommer det att göra att motorn överger användningen av index och utför fullständig tabellskanning, såsom:
Välj ID från t där num är null
Du kan sätta standardvärdet 0 på num, se till att det inte finns något nullvärde i num-kolumnen i tabellen, och sedan fråga så här:
Välj id från t där num=0
3. Försök undvika att använda != eller <> operatorer i where-klausulen, annars kommer motorn att överge användningen av index och istället utföra fullständig tabellsscanning.
4. Du bör försöka undvika att använda OR i where-klausulen för att ansluta till villkoret, annars kommer det att göra att motorn överger användningen av index och gör en fullständig tabellskanning, till exempel:
Välj ID från t där num=10 eller num=20
Du kan fråga så här:
Välj id från t där num=10
Förening alla
Välj ID från t där num=20
5.in och inte i bör också användas med försiktighet, annars leder det till fullständig bordsscanning, såsom:
Välj ID från t där num in(1,2,3)
För kontinuerliga värden, använd inte i om du kan använda mellan:
Välj ID från t där numet ligger mellan 1 och 3
6. Följande fråga kommer också att resultera i en fullständig tabellskanning:
Välj ID från t där namn som '%abc%'
För att förbättra effektiviteten, överväg fulltextsökning.
7. Om du använder en parameter i en where-klausul kommer det också att orsaka en fullständig tabellskanning. Eftersom SQL endast löser lokala variabler vid körning, men optimeraren inte kan skjuta upp valet av åtkomstplaner till körtid; Den måste väljas vid kompilering. Om dock en åtkomstplan upprättas vid kompileringstillfället är variabelns värde fortfarande okänt och kan därför inte användas som en indata för indexval. Följande uttalanden kommer att skannas i sin helhet:
Välj ID från t där num=@num
Du kan tvinga frågan att använda ett index istället:
Välj ID från t med(index(index(index(indexnamn)) där num=@num
8. Försök undvika att uttrycka fält i where-klausulen, vilket gör att motorn överger användningen av index till förmån för fullständig tabellskanning. Till exempel:
Välj ID från t där num/2=100
bör ändras till:
Välj id från t där num=100*2
9. Försök undvika att utföra funktionsoperationer på fält i where-klausulen, vilket gör att motorn överger användningen av index till förmån för fullständig tabellskanning. Till exempel:
Välj id från t där substring(name,1,3)='abc' --namn-id som börjar med abc
Välj ID från t där datediff(day,createdate,'2005-11-30')=0--'2005-11-30' genererat id
bör ändras till:
Välj ID från T där namn som 'abc%'
Välj ID från t där CreateDate>='2005-11-30' och CreateDate<'2005-12-1'
10. Utför inte funktioner, aritmetiska operationer eller andra uttrycksoperationer till vänster om "=" i where-satsen, annars kan systemet kanske inte använda indexet korrekt.
11. När ett indexfält används som villkor, om indexet är ett sammansatt index, måste det första fältet i indexet användas som villkor för att säkerställa att systemet använder indexet, annars kommer indexet inte att användas, och ordningen på fälten bör vara så konsekvent som möjligt med indexordningen.
12. Skriv inte meningslösa frågor, som att generera en tom tabellstruktur:
Välj kol1,kol2 i #t från t där 1=0
Denna typ av kod returnerar ingen resultatuppsättning, men den förbrukar systemresurser, så den bör ändras till något i stil med detta:
skapa tabell #t(...)
13. Ofta är det ett bra val att ersätta med att det finns:
Välj Num från A där Num In (Välj Num från B)
Ersätt med följande påstående:
Välj Num från A där finns (välj 1 från B där Num=A.Num)
14. Alla index är inte giltiga för frågor, SQL baseras på data i tabellen för att optimera frågan, när indexkolumnen har mycket dataduplicering kan SQL-frågor inte använda indexet, till exempel om en tabell har ett fält kön, hane, kvinna är nästan hälften var, och även om indexet byggs på kön kommer det inte att spela någon roll för frågeeffektiviteten.
15. Ju fler index inte är desto bättre, indexet kan visserligen förbättra effektiviteten för motsvarande select, men det minskar också effektiviteten vid insättning och uppdatering, eftersom indexet kan byggas om vid insättning eller uppdatering, så hur man bygger ett index måste noggrant övervägas beroende på den specifika situationen. Det är bäst att inte ha fler än 6 index i en tabell, och om det finns för många, överväg om det är nödvändigt att bygga index på några sällan använda kolumner.
16. Undvik att uppdatera klustrade indexdatakolumner så mycket som möjligt, eftersom ordningen på klustrade indexdatakolumner är den fysiska lagringsordningen för tabellposter, och när kolumnvärdet ändras leder det till att ordningen på hela tabellposten justeras, vilket kommer att förbruka betydande resurser. Om din applikation behöver uppdatera klustrade indexkolumner ofta behöver du överväga om du ska bygga indexet som ett klustrat index.
17. Försök använda numeriska fält och försök att inte designa fält som endast innehåller numerisk information som tecken, vilket minskar prestandan för frågor och anslutningar och ökar lagringsöverhead. Detta beror på att motorn jämför varje tecken i strängen en efter en vid bearbetning av frågor och joins, medan den för numeriska typer bara behöver jämföras en gång.
18. Använd varchar/nvarchar istället för char/nchar så mycket som möjligt, eftersom det första kan det längre fältlagringsutrymmet spara lagringsutrymme, och för det andra, för frågor är sökeffektiviteten i ett relativt litet fält uppenbarligen högre.
19. Använd inte select * från t någonstans, ersätt "*" med en specifik lista med fält, och returnera inga fält som inte används.
20. Försök använda tabellvariabler istället för temporära tabeller. Om tabellvariabeln innehåller en stor mängd data, observera att indexet är mycket begränsat (endast primärnyckelindexet).
21. Undvik att ofta skapa och ta bort tillfälliga tabeller för att minska förbrukningen av systemtabellresurser.
22. Tillfälliga tabeller är inte oanvändbara, och att använda dem på rätt sätt kan göra vissa rutiner mer effektiva, till exempel när du behöver referera till en datamängd upprepade gånger i en stor eller vanligt använd tabell. Men för engångshändelser är det bäst att använda en exporttabell.
23. När du skapar en tillfällig tabell, om mängden data som infogas samtidigt är stor, kan du använda select i istället för create table för att undvika att orsaka ett stort antal loggar för att förbättra hastigheten; Om datamängden inte är stor, för att underlätta resurserna i systemtabellen, bör du först skapa en tabell och sedan infoga.
24. Om en tillfällig tabell används, se till att uttryckligen ta bort alla temporära tabeller i slutet av den lagrade proceduren, kapa tabellen först och sedan ta bort tabellen, för att undvika att systemtabellen låses under lång tid.
25. Försök undvika att använda markören, eftersom markörens effektivitet är dålig, om datan som styrs av markören överstiger 10 000 rader bör du överväga att skriva om.
26. Setbaserade lösningar bör sökas för att lösa problem innan man använder markörbaserade eller tillfälliga tabellmetoder, som ofta är mer effektiva.
27. Precis som temporära tabeller är markörer inte oanvändbara. Att använda FAST_FORWARD markörer för små datamängder är ofta bättre än andra rad-för-rad-bearbetningsmetoder, särskilt om du måste referera till flera tabeller för att få den data du behöver. Rutiner som inkluderar "total" i resultatuppsättningen är vanligtvis snabbare än de som körs med markören. Om utvecklingstiden tillåter kan både kursorbaserade och mängdbaserade metoder testas för att se vilken som fungerar bäst.
28. Sätt SET NOCOUNT ON i början av alla lagrade procedurer och triggers, och SET NOCOUNT OFF i slutet. Det finns inget behov av att skicka DONE_IN_PROC meddelanden till klienten efter att varje sats i den lagrade proceduren och triggern har exekverats.
29. Försök undvika stora transaktionsoperationer och förbättra systemets samtidighetskapacitet.
30. Försök undvika att returnera stora data till klienten, om datavolymen är för stor bör du överväga om motsvarande efterfrågan är rimlig. |
Publicerad på 2015-01-27 20:09:54
|
|
|
