http://www.simple-talk.com/sql/performance/performance-tuning-tips-for-database-developers/
- Ustawiaj klucz główny, dla każdej tabeli którą tworzysz. Dopóki nie będziesz posiadał odpowiedniej wiedzy aby wymyślić coś lepszego, zadeklaruj go jako indeks klastrowy (warto pamiętać, że jeśli ustawimy klucz główny za pomocą narzędzia Enterprise Manager będzie on domyślnie tworzony z indeksem klastrowym).
- Każda kolumna, która przechowuje klucz obcy powinna posiadać indeks. Jeśli wiesz, że ten klucz będzie unikalny, wymuś na indeksie, aby też taki był.
- Nie indeksuj niczego więcej.
- Gdy odwołujesz się do obiektów w zapytaniach TSQL, zawsze podawaj kwalifikator ich właściciela (chyba że potrzebujesz innego rozwiązania). Korzystaj z DBO.SYSDATABASES zamiast samego SYSDATABASES.
- Na początku każdej procedury składowanej ustawiaj SET NOCOUNT (a na końcu SET NOCOUNT OFF).
- Dokładnie przemyśl potrzebę korzystania z blokad. Jeśli nie tworzysz oprogramowania bankowego, czy będzie miało znacznie jeśli wystąpi brudny odczyt (ang. dirty read)? Możesz zastosować NOLOCK, ale często dużo łatwiej jest ustawić na początku procedury SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED, a następnie przywrócić ustawienia za pomocą READ COMMITTED na jej końcu.
- Pewnie słyszałeś już to milion razy, ale pobieraj tylko te kolumny i wiersze, których w danym momencie naprawdę potrzebujesz.
- Korzystaj z transakcji kiedy wydaje się to odpowiednie, ale nie pozwól żeby jakikolwiek użytkownik mógł wpłynąć na jej wykonanie. Osobiście staram się wykonywać wszystkie transakcje wewnątrz procedur składowanych.
- Jeśli tylko możesz, unikaj tabel tymczasowych. Jeżeli jednak będziesz ich potrzebować, twórz je wykorzystując jawne wywołanie CREATE TABLE #TEMP.
- Staraj się nie korzystać z NOT IN, zamiast tego stosuj LEFT OUTER JOIN. Nawet wtedy gdy łatwiejsze i czytelniejsze wydaje się wykorzystanie NOT IN.
- Jeśli upierasz się przy stosowaniu dynamicznego sql (konkatenacja stringów) wykorzystuj do tego nazwane parametry oraz SP_EXECUTESQL (zamiast EXEC), dzięki temu masz szansę na ponowne użycie planu wykonania zapytania (ang. query plan). Uproszczeniem byłoby powiedzieć, że procedury składowane są odpowiedzią na każdy problem, jednak z duża dozą prawdopodobieństwa można stwierdzić, że za ich pomocą nie da się zrobić czegoś źle.
- Wyrób w sobie nawyk kontrolowania swojego kodu przed oraz po każdej jego zmianie (narzędzie SQL Server Profiler). Mając na uwadze rodzaj wprowadzonych zmian, sprawdź czy wykorzystanie procesora, odczyty i zapisy serwera nie wzrosły o więcej niż 10-15%. Jeśli tak, to najprawdopodobniej procedura będzie wymagała przemyślenia.
- Jeśli to tylko możliwe, staraj się ograniczać liczbę zapytań kierowanych do serwera. Jedną z metod jest formułowanie zapytania tak, aby serwer za jednym razem zwrócił większy zbiór wyników.
- Unikaj stosowania wskazówek dla indeksów oraz złączeń.
- Kiedy skończysz pisanie kodu, ustaw program Profiler tak aby monitorował zapytania tylko z Twojego komputera, następnie uruchom swoja aplikację od początku do końca. Sprawdź liczbę zapisów oraz odczytów, a także liczbę odwołań do serwera. Postaraj się wychwycić nietypowe zachowania procedury. Bardzo często można zauważyć wywołania procedur już niewykorzystywanych albo wywołania podwójne. Postaraj się przeanalizować swoje spostrzeżenia razem z administratorem bazy.
