Prezentacja 20141129
-
Upload
magda3695 -
Category
Technology
-
view
69 -
download
0
Transcript of Prezentacja 20141129
SQL ≠ SQL żyje i ma się dobrze
Bardzo krótki przewodnik po best practises w MS SQLBardzo krótki przewodnik po worst practises w MS SQL
SELECT ≠ SELECT * to zwykle nie jest dobry pomysł.
• Znaj nazwy kolumn.
• Pobieraj tylko niezbędne dane.
• Pamiętaj o indeksach.
• TOP może się przydać.
• …albo SET ROWCOUNT.
WHERE ≠ WHERE nie jest ozdobą.
• Używaj warunków w celu ograniczenia ilości pobieranych danych.
• Konstruuj warunki tak aby poprawnie korzystały z indeksów.
• …lub twórz indeksy tak aby wspomagały warunki.
• Porównując daty, nie korzystaj z funkcji niedeterministycznych.
SELECT * FROM tabela WHEREYEAR(DataUtworzenia) = 2014 AND MONTH(DataUtworzenia) = 9
SELECT * FROM tabela WHEREDataUtworzenia >= `2014-09-01T00:00:00’ AND DataUtworzenia < `2014-09-01T00:00:00’
JOIN ≠ .Join()JOIN to nie .Join(…).
• Poznaj różnice między rodzajami złączeń.
• Korzystaj ze złączeń w zapytaniach
SELECT A.Id
FROM A
LEFT JOIN B ON A.Id = B.Id
WHERE B.Id IS NOT NULL
• Nie zapominaj o CROSS JOIN.
• Nie zawsze JOIN jest wydajniejszy od podzapytania!
No, nie tylko.
poprawnie i świadomie.
SELECT A.Id
FROM A
INNER JOIN B ON A.Id = B.Id
INT ≠ VARCHARTypy danych są ważne. I różne.
• Pamiętaj żeby dane przechowywać w polach o odpowiednich typach.
• Ograniczaj wielkość pól do realnych wartości.
• W zapytaniach używaj parametrów odpowiedniego typu.
SELECT * FROM A WHERE Id = '1234'
SELECT * FROM A WHERE Id = 1234
NF ≠ Normalizacja to nie wiedza akademicka.
• Przemyśl i zaplanuj struktury danych przed implementacją.
• Używaj kluczy obcych.
• Pamiętaj, że normalizacja służy „eliminacji redundancji danych przy jednoczesnym zapewnieniu ich spójności”, co niekoniecznie przekłada się na wydajność.
• …więc po co o niej wspominam?
deNF ≠ Denormalizacja to nie zuoooo
• W uzasadnionych przypadkach pozwól sobie na redundancję danych.
• …ale żeby bazę zdenormalizować, to najpierw powinna być znormalizowana!
• Denormalizacja nie może być uzasadnieniem bur bałaganu w bazie.
…w niektórych przypadkach.
Indeks ≠ Indeksy to nic strasznego.
• Nie twórz indeksów rozbudowanych ponad potrzeby.
• Pamiętaj, że klucz obcy to nie indeks.
• Naucz się korzystać z narzędzi optymalizacyjnych.
• Widoki też można indeksować
• Dowiedz się co to jest indeks kryjący.
• Nie każdy indeks ma sens.
pod pewnymi warunkami.
Procedura ≠ SELECTProcedura to nie to samo co zwykły SELECT
• Korzystaj z procedur do wieloetapowego przetwarzania dużej ilości danych.
• Pamiętaj, że nie zawsze zwykłe zapytanie jest lepsze od procedury.
• ...ale też nie zawsze procedura jest lepsza od zwykłego zapytania.
• Uważaj na „parameter sniffing”.
• …również przy zwykłych SELECTach.
• Unikaj kursorów
(chociaż może nim być).
, zwłaszcza jeżeli są wymówką dla braku znajomości SQL.
Transakcja ≠Transakcja to nie jest niepotrzebny bagaż.
• Korzystaj z transakcji.
• …tam, gdzie jest to potrzebne!
• Obejmuj transakcją tylko kluczowy fragment zapytania.
• Pamiętaj o ustawieniu odpowiedniego poziomu izolacji transakcji.
Inne, też ważneW skrócie• Pamiętaj o hintach typu LOCK.
• Znaj różnicę między tablicą tymczasową a zmienną tabelaryczną.
• …i pomiędzy tymi strukturami a CTE.
• Naucz się korzystać z MERGE
• …oraz OUTPUT
• …oraz ROW_NUMBER() OVER (ORDER BY…)
• MYŚL!
Baza ≠Baza danych to nie niewzruszona struktura.
• Weryfikuj zapytania w miarę przyrostu ilości danych.
• Optymalizuj indeksy.
• Odświeżaj statystyki.
• Och, no po prostu zadbaj trochę o bazę danych, ok?