Структура таблицы SQL Server 2008 с учетом требований производительности - PullRequest
Новая
       45

Структура таблицы SQL Server 2008 с учетом требований производительности

0 голосов
/ 17 ноября 2011

Я сейчас нахожусь перед дилеммой относительно того, стоит ли использовать Guid.

У меня есть нетранзакционная таблица, которая называется Posts с bigint как PK.

Насколько я понимаю, использование Guid в качестве PK может снизить производительность запросов. Однако, чтобы сделать строку запроса действительно уникальной, я решил добавить столбец с именем specialID с Guid default value newid(). Это сделало бы все мои строки запросов по-настоящему уникальными, так как все, что мне нужно, это выполнить следующий запрос: 

SELECT * 
  FROM Posts p 
 WHERE p.specialID = '[query-string]'; // For single record retrieval

Что касается Joins, bigint PK вступит в игру следующим образом: 

SELECT p.id, p.specialID, ul.name as Writer 
  FROM Posts p 
  JOIN Users ul ON ul.id = p.writer;

Однако мой коллега с этим не согласился и сказал, что это по-прежнему будет препятствовать выполнению запросов. Зачем? И я должен продолжать этот путь? Действительно уникальная строка запроса не обязательна, но будет предпочтительнее. Если это действительно ухудшит производительность, как мы можем получить действительно уникальную строку запроса?

1 Ответ

0 голосов
/ 17 ноября 2011

Это не должно существенно затруднять запросы SELECT, особенно если вы правильно проиндексировали столбец. Это может потенциально повлиять на вставки, но это не проблема, если GUID не является частью кластерного индекса. Это также может повлиять на требования к хранилищу, в зависимости от того, сколько данных вы собираетесь хранить, поскольку оно (очевидно) намного больше.

Подробное обсуждение здесь: http://www.sql -server-performance.com / 2005 / guid-performance / хотя это касается 2005 года, я считаю, что все пункты по-прежнему актуальны.

** РЕДАКТИРОВАТЬ: простой пример индекса ** «Покрывающий индекс» означает, что у вас есть индекс, включающий рассматриваемый столбец. Кластерный индекс означает, что записи на самом деле хранятся в порядке, указанном в индексе, некластеризованный индекс означает, что индекс содержит указатель на сохраненное местоположение. Рассмотрим разницу как словарь по сравнению с индексом книги. Словарь сортируется в порядке слов и сохраняет все свои данные в этом порядке (кластеризованные), в то время как индекс сортируется в порядке слов, но имеет указатель на номера страниц, которые не в том же порядке (некластеризованы).

Итак, чтобы создать индекс для вашего столбца, вы должны сделать: 

CREATE INDEX idx_posts_specialId
    ON Posts (specialID); 
GO

Значение по умолчанию некластеризовано, но вы можете добавить ключевое слово «некластеризовано», если хотите быть явным.

...