Pomiędzy moimi podróżami, prezentacjami i moderacją pytań i odpowiedzi rozmawiam z wieloma osobami na temat różnych problemów z wydajnością SQL Server. Ostatnio miałem kilka interakcji, w których ludzie wierzą w rzeczy, które są albo całkowicie niepoprawne, albo są poprawne tylko w bardzo wąskim zestawie przypadków użycia. Jednak ich przekonanie, że te rzeczy są powszechnie prawdziwe, jest niepokojące.
Pomyślałem więc, że zacznę nową serię, aby pomóc stłumić niektóre z tych mitów. Nie po to, by wskazywać na ludzi i udowadniać, że się mylą, ale by powstrzymać rozprzestrzenianie się. Kiedy wygłaszają te ogólne oświadczenia w swoim miejscu pracy, na Twitterze lub na forach, jeśli nie zostaną sprawdzone, mogą „uczyć” wrażliwych lub mniej doświadczonych użytkowników.
Zwróć uwagę, że nie zamierzam udowadniać, że te rzeczy nigdy prawda, ponieważ niektóre z nich z pewnością mogą być prawdziwe w odosobnionych lub wymyślonych scenariuszach . Moim celem jest po prostu zademonstrowanie przynajmniej jednego przypadku, w którym nie jest to prawdą; miejmy nadzieję, że może to zmienić te uparte nastawienie.
Oto kilka „faktów”, które ostatnio mi powiedziano, w przypadkowej kolejności:
- „Indeks klastrowy jest zawsze lepszy niż indeks nieklastrowany”
- „Dynamiczny SQL spowolnił moje zapytanie”
- „PIVOT jest szybszy niż SUM(CASE)”
- „NULL zawsze powoduje straszne problemy z wydajnością”
- "Plany wykonania są bezużyteczne z wyjątkiem brakujących indeksów"
- „NOLOCK jest w porządku, ponieważ wiele osób go używa”
- „Przewymiarowanie kolumn varchar/nvarchar jest w porządku”
Gdy piszę każdy post, będę aktualizować tę stronę, podłączając odpowiedni element na powyższej liście.
Czy masz jakieś mity dotyczące wydajności, które są przekazywane jako absolutny fakt, ale podejrzewasz (a może nawet wiesz), że nie zawsze są one prawdziwe? Daj mi znać w komentarzach poniżej, na Twitterze lub pod adresem [email protected].
