Podczas pracy z indeksami musisz określić, do czego będzie używany Twój stół. Jeśli głównie wstawiasz 1000 wierszy na sekundę i nie wykonujesz żadnych zapytań, indeks klastrowy jest trafieniem do wydajności. Jeśli robisz 1000 zapytań na sekundę, to brak indeksu spowoduje bardzo złą wydajność. Najlepszą rzeczą do zrobienia podczas próby dostrojenia zapytań/indeksów jest użycie Query Plan Analyzer i SQL Profiler w SQL Server. Spowoduje to wyświetlenie miejsca, w którym wykonywane są kosztowne skanowanie tabeli lub inne blokery wydajności.
Jeśli chodzi o argument GUID i ID, można znaleźć osoby online, które przeklinają za pomocą obu. Zawsze uczono mnie używać GUID, chyba że mam naprawdę dobry powód, aby tego nie robić. Jeff ma dobry post, który mówi o powodach używania GUID: http://www.codinghorror.com/blog/archives/000817.html.
Podobnie jak w przypadku większości produktów związanych z rozwojem, jeśli chcesz poprawić wydajność, nie ma jednej, jednej prawidłowej odpowiedzi. To naprawdę zależy od tego, co próbujesz osiągnąć i jak wdrażasz to rozwiązanie. Jedyną prawdziwą odpowiedzią jest testowanie, testowanie i testowanie ponownie w oparciu o wskaźniki wydajności, aby upewnić się, że osiągasz swoje cele.
[Edytuj] @Matt, po przeprowadzeniu kilku badań w debacie GUID/ID natknąłem się na ten post. Tak jak wspomniałem wcześniej, nie ma prawdziwej odpowiedzi słusznej lub błędnej. To zależy od konkretnych potrzeb związanych z wdrażaniem. Są to jednak pewne uzasadnione powody używania identyfikatorów GUID jako klucza podstawowego:
Na przykład występuje problem znany jako "hotspot", w którym niektóre strony danych w tabeli znajdują się pod względnie wysokim wpływem na waluty. Zasadniczo, co się dzieje, większość ruchu w tabeli (a tym samym blokady na poziomie strony) pojawia się na niewielkim obszarze stołu, pod koniec. Nowe rekordy zawsze będą przechodzić do tego hotspotu, ponieważ TOŻSAMOŚĆ jest generatorem liczb sekwencyjnych. Te wstawki są kłopotliwe, ponieważ wymagają zablokowania strony na stronie, do której są dodawane (hotspot). To skutecznie serializuje wszystkie wkładki do stołu dzięki mechanizmowi blokowania stron. Natomiast NewID() nie ma hotspotów. Wartości generowane za pomocą funkcji NewID() są tylko sekwencyjne dla krótkich serii wstawek (gdzie funkcja jest wywoływana bardzo szybko, na przykład podczas wstawiania wielu wierszy), co powoduje, że wstawione wiersze są losowo rozmieszczane na stronach danych tabeli wszystkich na końcu - eliminując w ten sposób hotspot z wkładek.
Ponadto, ponieważ wkładki są losowo rozdzielone, prawdopodobieństwo podziału strony jest znacznie zmniejszone.Podczas gdy strona podzielona tu i tam nie jest zbyt zła, efekty szybko się sumują. Z TOŻSAMOŚCIą, współczynnik wypełnienia strony jest całkiem bezużyteczny jako mechanizm strojenia i równie dobrze może być ustawiony na 100% - wiersze nigdy nie będą wstawiane na żadnej stronie oprócz ostatniej. Dzięki funkcji NewID() można faktycznie wykorzystać współczynnik wypełnienia jako narzędzie umożliwiające osiągnięcie wydajności. Współczynnik wypełnienia można ustawić na poziomie zbliżonym do szacowanego wzrostu wolumenu między odbudowaniami indeksów, a następnie zaplanować odbudowę poza godzinami szczytu za pomocą reindeksu dbcc. Skutecznie opóźnia to wydajność dzielenia stron do czasu poza szczytem.
Jeśli nawet myśli, być może trzeba włączyć replikację dla danej tabeli - wtedy równie dobrze można uczynić PK unikalnym identyfikatorem i oznaczyć pole guid jako ROWGUIDCOL. Replikacja będzie wymagać jednoznacznie wycenionego pola guid z tym atrybutem i doda jeden, jeśli nie istnieje. Jeśli istnieje odpowiednie pole, to po prostu użyje tego, które tam jest.
Kolejna ogromna korzyść dla użyciu GUID dla PK jest fakt, że wartość jest rzeczywiście gwarantuje wyjątkowy - nie tylko wśród wszystkich wartości generowanych przez tym serwerze, ale wszystkie wartości generowanych przez wszystkich komputerami - czy to będzie twój serwer db, serwer WWW, serwer aplikacji lub komputer klienta. Niemalże każdy współczesny język ma możliwość generowania prawidłowego guid teraz - w .NET można użyć System.Guid.NewGuid. Jest to BARDZO przydatne przy szczególnie zbiorze przechowywanych w pamięci podręcznej szczegółowych danych szczegółowych. Nie musisz stosować szalonych tymczasowych schematów kluczy, aby powiązać swoje rekordy, zanim zostaną zatwierdzone. Po prostu pobierasz całkowicie poprawny nowy Guid z systemu operacyjnego dla stałej wartości każdego nowego rekordu w momencie tworzenia rekordu.
http://forums.asp.net/t/264350.aspx
Od kiedy wykonujecie replikację, wasze są to poprawne tożsamości. Uczyniłbym twój GUID kluczem podstawowym, ale nieklastrowany, ponieważ nie możesz użyć newsequentialid. To utwierdza mnie w najlepszym kursie. Jeśli nie stworzysz PK, ale umieścisz na nim unikalny indeks, prędzej czy później może to spowodować, że osoby, które utrzymują system, nie będą poprawnie rozumieć relacji FK, wprowadzając błędy. – HLGEM