При работе с индексами вы должны определить, для чего будет использоваться ваша таблица. Если вы в первую очередь вставляете 1000 строк в секунду и не выполняете никаких запросов, то кластеризованный индекс снижает производительность. Если вы выполняете 1000 запросов в секунду, отсутствие индекса приведет к очень низкой производительности. Лучше всего при настройке запросов / индексов лучше всего использовать анализатор плана запросов и SQL Profiler в SQL Server. Это покажет вам, где вы работаете с дорогостоящими сканированиями таблиц или другими блокировщиками производительности.
Что касается аргумента GUID vs ID, вы можете найти в Интернете людей, которые клянутся обоими. Меня всегда учили использовать GUID, если у меня нет действительно веской причины не делать этого. У Джеффа есть хороший пост, в котором рассказывается о причинах использования GUID: https://blog.codinghorror.com/primary-keys-ids-versus-guids/.
Как и в большинстве случаев, связанных с разработкой, если вы хотите повысить производительность, нет единственного правильного ответа. Это действительно зависит от того, чего вы пытаетесь достичь и как вы внедряете решение. Единственный верный ответ - это тестирование, тестирование и повторное тестирование по показателям производительности, чтобы убедиться, что вы достигаете своих целей.
[Изменить]
@Matt, после некоторого исследования о GUID / ID я наткнулся на этот пост. Как я уже упоминал ранее, нет правильного или неправильного ответа. Это зависит от ваших конкретных потребностей реализации. Но вот несколько довольно веских причин использовать GUID в качестве первичного ключа:
Например, существует проблема, известная как «горячая точка», когда определенные страницы данных в таблице находятся в состоянии относительно высокой конкуренции за валюту. По сути, происходит то, что большая часть трафика в таблице (и, следовательно, блокировки на уровне страниц) происходит в небольшой области таблицы, ближе к концу. Новые записи всегда будут поступать в эту точку доступа, потому что IDENTITY - это генератор последовательных чисел. Эти вставки являются проблематичными, потому что они требуют исключительной блокировки страницы на странице, к которой они добавлены (точка доступа). Это эффективно сериализует все вставки в таблицу благодаря механизму блокировки страницы. NewID (), с другой стороны, не страдает от горячих точек. Значения, созданные с помощью функции NewID (), являются последовательными только для коротких пакетов вставок (когда функция вызывается очень быстро, например, во время многострочной вставки), что приводит к тому, что вставленные строки распределяются случайным образом по страницам данных таблицы. всего в конце - таким образом устраняя горячую точку от вставок.
Кроме того, поскольку вставки распределяются случайным образом, вероятность разбиения страниц значительно снижается. В то время как страница разделена здесь и там не так уж плохо, эффекты действительно складываются быстро. С IDENTITY, коэффициент заполнения страницы довольно бесполезен в качестве механизма настройки и может также быть установлен на 100% - строки никогда не будут вставлены ни на одну страницу, кроме последней. С помощью NewID () вы можете использовать Fill Factor в качестве инструмента повышения производительности. Вы можете установить коэффициент заполнения на уровень, который приблизительно соответствует ожидаемому росту объема между перестройками индекса, а затем запланировать перестройки в непиковые часы с помощью переиндексации dbcc. Это эффективно задерживает скачки производительности при разделении страниц до непикового времени.
Если вы даже думаете , вам может потребоваться включить репликацию для рассматриваемой таблицы - тогда вы можете также сделать PK уникальным идентификатором и пометить поле guid как ROWGUIDCOL. Для репликации потребуется уникальное поле guid с этим атрибутом, и оно будет добавлено, если оно не существует. Если подходящее поле существует, оно будет использовать только то, что там есть.
Еще одним огромным преимуществом использования GUID для PK является тот факт, что значение действительно гарантированно уникально - не только среди всех значений, сгенерированных этим сервером, но и всех значений, сгенерированных all компьютеры - будь то ваш БД-сервер, веб-сервер, сервер приложений или клиентский компьютер. Практически каждый современный язык имеет возможность генерировать действительный guid - в .NET вы можете использовать System.Guid.NewGuid. Это ОЧЕНЬ удобно при работе с кэшированными наборами данных master-detail, в частности. Вам не нужно использовать сумасшедшие временные схемы ключей, чтобы связать ваши записи вместе, прежде чем они будут зафиксированы. Вы просто выбираете совершенно правильный новый Guid из операционной системы для значения постоянного ключа каждой новой записи во время ее создания.
http://forums.asp.net/t/264350.aspx