Ответ 1
При работе с индексами вы должны определить, для чего будет использоваться ваша таблица. Если вы в первую очередь вставляете 1000 строк в секунду и не выполняете никаких запросов, то кластеризованный индекс является хитом производительности. Если вы делаете 1000 запросов в секунду, то отсутствие индекса приведет к очень плохой производительности. Лучшее, что нужно делать при настройке запросов/индексов, - это использовать анализатор запросов и SQL Profiler в SQL Server. Это покажет вам, где вы столкнулись с дорогостоящими сканированием таблиц или другими блокаторами производительности.
Что касается аргумента GUID vs ID, вы можете найти людей в Интернете, которые клянутся обоими. Меня всегда учили использовать GUID, если у меня нет повода для этого. У Джеффа хорошая статья, в которой рассказывается о причинах использования GUID: http://www.codinghorror.com/blog/archives/000817.html.
Как и в случае с большинством всего связанного с развитием развития, если вы хотите улучшить производительность, нет ни одного правильного ответа. Это действительно зависит от того, что вы пытаетесь выполнить и как вы реализуете решение. Единственный верный ответ - снова протестировать, протестировать и протестировать против показателей производительности, чтобы убедиться, что вы достигли своих целей.
[Изменить] @Matt, после того, как я провел еще несколько исследований по обсуждению GUID/ID, я столкнулся с этим сообщением. Как я уже упоминал ранее, нет истинного правильного или неправильного ответа. Это зависит от ваших конкретных потребностей в реализации. Но это довольно веские причины использовать GUID в качестве первичного ключа:
Например, существует проблема, известная как "горячая точка", где определенные страницы данных в таблице находятся в относительно высоком разрешении валюты. В основном, то, что происходит, это большая часть трафика на столе (и, следовательно, блокировки на уровне страницы) происходит на небольшой площади таблицы, к концу. Новые записи всегда будут идти в эту точку доступа, потому что IDENTITY - это генератор последовательных чисел. Эти вставки неприятны, потому что им нужна эксклюзивная блокировка страницы на странице, к которой они добавлены (точка доступа). Это эффективно сериализует все вставки в таблицу благодаря механизму блокировки страницы. NewID(), с другой стороны, не страдает от горячих точек. Значения, сгенерированные с использованием функции NewID(), являются только последовательными для коротких всплесков вставок (где функция вызывается очень быстро, например, во время многорядной вставки), что приводит к тому, что вставленные строки распространяются случайным образом на страницах данных таблицы из всех в конце - таким образом, исключая горячую точку из вставок.
Кроме того, поскольку вставки распределены случайным образом, вероятность разделения страниц значительно снижается. В то время как разрыв страницы здесь и там не слишком плох, эффекты быстро складываются. С IDENTITY, страница Fill Factor довольно бесполезна в качестве механизма настройки и может также быть установлена на 100% - строки никогда не будут вставлены ни на одну страницу, кроме последней. С помощью NewID() вы действительно можете использовать Fill Factor в качестве инструмента для обеспечения эффективности. Вы можете установить Fill Factor на уровень, который приблизительно соответствует расчетному росту объема между индексами перестроек, а затем планировать перестройки в непиковые часы с использованием dindex. Это эффективно задерживает показы производительности разделов страниц до тех пор, пока не будет достигнуто пиковое время.
Если вы даже думаете, что вам нужно включить репликацию для рассматриваемой таблицы, то вы также можете сделать PK уникальным идентификатором и пометить поле guid как ROWGUIDCOL. Репликация потребует уникально оцененного поля guid с этим атрибутом, и он добавит один, если он не существует. Если подходящее поле существует, тогда оно просто будет использовать ту, что там.
Еще одним огромным преимуществом использования GUID для ПК является тот факт, что ценность действительно гарантирована уникальной - не только среди всех значений, сгенерированных этим сервером, но и всех значений, генерируемых всеми компьютерами - будь то ваш сервер db, веб-сервер, сервер приложений или клиентский компьютер. Практически каждый современный язык имеет возможность генерировать действительный guid now - в .NET вы можете использовать System.Guid.NewGuid. Это ОЧЕНЬ удобно при работе с кэшированными наборами данных master-detail в частности. Вам не нужно использовать сумасшедшие временные схемы манипуляции только для того, чтобы связать ваши записи вместе, прежде чем они будут совершены. Вы просто получаете совершенно новый новый Guid от операционной системы для каждого нового значения постоянной записи в момент создания записи.