1. A lekérdezés optimalizálásához érdemes elkerülni a teljes táblázatszkennelést, és először fontolóra venni, hogy létrehozz egy indexet az oszlopokról, amelyek hol és sorrendben szerepelnek.
2. Próbáld elkerülni a null értékítéletet a where klauzus mezőin, különben a motor feladja az indexek használatát és teljes táblázatszkennelést végez, például:
Válassz azonosítót a T-ből, ahol null
Beállíthatod az alapértelmezett értéket 0-nak a számon, meggyőződhetsz róla, hogy nincs null érték a táblázat num oszlopában, majd így kérdezheted:
Válassz azonosítót a T-ből, ahol num=0
3. Próbáld elkerülni a != vagy <> operátorok használatát a where klauzulatban, különben a motor feladja az indexek használatát és teljes táblázatos szkennelést végez.
4. Próbáld meg elkerülni, hogy az OR használata a hol klauzuladékban a feltételhez csatlakozzon, különben a motor feladja az indexek használatát, és teljes táblázat-szkennelést végez, például:
Válassz azonosítót a T-ből, ahol num=10 vagy num=20
Ilyen kérdéseket tehetsz:
Válassz azonosítót a T-ből, ahol num=10
Mindenki egyesülése
Válassz azonosítót a T-ből, ahol num=20
5.in és nem be, óvatosan kell használni, különben teljes táblázatszkenneléshez vezet, például:
Válassz ID-t a T-ből, ahol num in(1,2,3)
Folytonos értékekhez ne használd az in-t, ha használhatod a közötti:
Válassz azonosítót a T-ből, ahol az Num 1 és 3 között
6. A következő lekérdezés teljes táblázatszkennelést is eredményez:
Válassz ID-t a T-ből, ahol a név például '%ABC%'
A hatékonyság növelése érdekében fontoljuk meg a teljes szöveges keresést.
7. Ha egy paramétert használsz egy hol klauzulatban, az teljes táblázatszkennelést is eredményez. Mivel az SQL csak helyi változókat oldja meg futásidőben, de az optimalizáló nem halaszthatja a hozzáférési tervek kiválasztását futásidőre; A fordításkor kell kiválasztani. Azonban, ha a fordításkor létrehoznak hozzáférési tervet, a változó értéke továbbra is ismeretlen, ezért nem használható bemeneti elemként az indexválasztáshoz. Az alábbi nyilatkozatokat teljes egészében átvizsgáljuk:
Válassz azonosítót a t-ből, ahol num=@num
Kényszerítheted a lekérdezést, hogy helyette indexet használjon:
Válassz ID-t a t-ből with(index(index(index name)), ahol num=@num
8. Próbáld meg elkerülni, hogy a where klauszadban fejezd ki a mezőket, ami arra készteti a motort, hogy elhagyja az indexek használatát a teljes táblázatszkennelés javára. Például:
Válassz azonosítót a T-ből, ahol num/2=100
A következőkre kell változtatni:
Válassz azonosítót a T-ből, ahol num=100*2
9. Próbáld meg elkerülni, hogy a where klauzulat szereplő mezőkön végrehajtsd a függvényműveleteket, ami miatt a motor feladja az indexek használatát a teljes táblázatszkennelés javára. Például:
Válassz azonosítót a t-ből, ahol substring(name,1,3)='abc' --név azonosító, amely abc-vel kezdődik
Válassz azonosítót a T-ből, ahol datediff(day,createdate,'2005-11-30')=0--'2005-11-30' generált azonosító
A következőkre kell változtatni:
Válassz azonosítót a T-ből, ahol a név például 'abc%'
Válassz azonosítót a T-ből, ahol createdate>='2005-11-30' és createdate<'2005-12-1'
10. Ne végezzen funkciókat, aritmetikai műveleteket vagy más kifejezési műveleteket a "=" bal oldalán a where klauzadban, különben a rendszer nem tudja helyesen használni az indexet.
11. Amikor az indexmezőt feltételként használjuk, ha az index összetett index, akkor az index első mezőjét kell feltételként használni, hogy biztosítsák, hogy a rendszer használja az indexet, különben az index nem lesz használatos, és a mezők sorrendje a lehető leginkább összhangban kell legyen az indexsorral.
12. Ne írj értelmetlen lekérdezéseket, például üres táblastruktúrát generálni:
Válassz col1,col2 #t-be a t-ből, ahol 1=0
Ez a kódtípus nem ad eredményhalmazt, de rendszererőforrásokat fogyaszt, ezért valami ilyesmire kell változtatni:
create table #t(...)
13. Gyakran jó választás helyettesíteni a létező betűkkel:
Válassz num-ot az a-ból, ahol num be-be (Válaszd a num-ot a b-ből)
Helyettesítse a következő állítást:
Válassz num-ot az a-ból, ahol létezik (válassz 1-et a b-ből, ahol num=a.num)
14. Nem minden index érvényes lekérdezésekhez, az SQL a táblázatban szereplő adatokon alapul a lekérdezés optimalizálásához; ha az index oszlopban nagy mennyiségű adatduplikáció van, az SQL lekérdezések nem feltétlenül használják az indexet, például egy táblázatban van egy mező a nemű, a férfi és nő szinte fele, akkor még ha az index nemre épül, nem is játszik szerepet a lekérdezés hatékonyságában.
15. Minél több index nem jobb, az index kétségtelenül javíthatja a megfelelő kiválasztó hatékonyságát, de csökkenti a behelyezés és frissítés hatékonyságát is, mert az index újraépíthető beillesztés vagy frissítés során, ezért az index építésének módját alaposan meg kell fontolni, a konkrét helyzettől függően. A legjobb, ha egy táblázatban nem lesz több mint 6 index, és ha túl sok van, fontold meg, szükséges-e indexeket építeni néhány ritkán használt oszlopon.
16. Kerüld a klaszterezett indexadat-oszlopok frissítését, amennyire csak lehet, mert a klaszterizált indexadat-oszlopok sorrendje a táblázat rekordok fizikai tárolási sorrendje, és ha az oszlop értéke változik, az egész táblázat rekordok sorrendjének módosításához vezet, ami jelentős erőforrásokat igényel. Ha az alkalmazásnak gyakran frissítenie kell a klaszterelt indexoszlopokat, akkor fontolóra kell venni, hogy az indexet klaszterelt indexként kell-e létrehozni.
17. Próbálj meg numerikus mezőket használni, és ne tervezz olyan mezőket, amelyek csak karakterként tartalmaznak numerikus információkat, ami csökkenti a lekérdezések és kapcsolatok teljesítményét, és növeli a tárolási költségeket. Ennek oka, hogy a motor egyenként hasonlítja össze a láncszál minden karakterét lekérdezések és csatlakozások feldolgozásakor, míg numerikus típusoknál csak egyszer kell összehasonlítani.
18. Használd a varchar/nvarchart a char/nchar helyett, mert először is, a hosszabb mezőtárolóhely megtakarítást jelenthet, másodszor pedig lekérdezéseknél a keresési hatékonyság viszonylag kis mezőn nyilvánvalóan magasabb.
19. Ne használd sehol a *-t válassz *-ból, cseréld a "*" betűt egy adott mezőlistára, és ne küldj vissza olyan mezőket, amelyeket nem használnak.
20. Próbálj meg táblázatváltozókat használni ideiglenes táblák helyett. Ha a táblaváltozó nagy mennyiségű adatot tartalmaz, vegyük figyelembe, hogy az index nagyon korlátozott (csak az elsődleges kulcsindex).
21. Kerüld a rendszertábla erőforrásainak fogyasztásának csökkentése érdekében a gyakori ideiglenes táblák létrehozását és törlését.
22. Az ideiglenes táblák nem használhatatlanok, és megfelelő használatuk egyes rutinokat hatékonyabbá tehet, például amikor egy adatbázist ismételten kell hivatkozással egy nagy táblában vagy egy gyakran használt táblában. Azonban egyszeri eseményeknél a legjobb exportálási táblát használni.
23. Ideiglenes tábla létrehozásakor, ha egyszerre nagy az adat beillesztése, akkor a select in (create table) (select in) (create table helyett) használhatod, hogy elkerüld a nagy mennyiségű naplót a sebesség javításában; Ha az adatmennyiség nem nagy, a rendszer tábla erőforrásainak megkönnyítése érdekében először kell létrehozni egy táblát, majd beilleszteni.
24. Ha ideiglenes táblát használnak, mindenképp törlöd az összes ideiglenes táblát a tárolt eljárás végén, először vágd le a táblát, majd hagyd el a táblát, hogy elkerüld a rendszer tábla hosszú távú zárolását.
25. Próbáld elkerülni a kurzor használatát, mert a kurzor hatékonysága gyenge; ha a kurzor által működtetett adat meghaladja a 10 000 sort, akkor érdemes újraírni.
26. A halmaz-alapú megoldásokat a problémák megoldásához érdemes keresni, mielőtt kurzor-alapú vagy ideiglenes táblamódszereket alkalmaznának, amelyek gyakran hatékonyabbak.
27. Mint az ideiglenes táblák, a kurzorok sem használhatatlanok. A FAST_FORWARD kurzorok használata kis adathalmazoknál gyakran jobb, mint más soronként feldolgozási módszerek, különösen, ha több táblára kell hivatkozni a szükséges adatok eléréséhez. Azok a rutinok, amelyek az eredményhalmazban "total" szerepelnek, általában gyorsabbak, mint azok, amelyeket a kurzorral hajtanak végre. Ha a fejlesztési idő engedi, mind kurzor-alapú, mind halmaz-alapú módszereket kipróbálhatunk, hogy megnézzük, melyik működik jobban.
28. Állítsuk be a NO COUNT -t bekapcsolni az összes tárolt eljárás és trigger elején, és a végén NO COUNT beállítást ki. Nem szükséges DONE_IN_PROC üzeneteket küldeni az ügyfélnek minden tárolt eljárás és trigger utasítás végrehajtása után.
29. Próbáld elkerülni a nagy tranzakciós műveleteket, és javítsd a rendszer egyidejű kapacitását.
30. Próbáld elkerülni, hogy nagy adatokat küldj vissza az ügyfélnek, ha az adatmennyiség túl nagy, érdemes mérlegelni, hogy a megfelelő igény ésszerű-e. |
Közzétéve 2015. 01. 27. 20:09:54
|
|
|
