Как я могу улучшить производительность, если я использовал первичный ключ в столбце guid? - PullRequest
2 голосов
/ 18 апреля 2011

я получил таблицу с полмиллиона строк.

первичный ключ - столбец guid.

Я обнаружил, что запрос select * from T where id ='xxxx' очень медленный.

что я должен сделать, чтобы улучшить производительность?

1 Ответ

5 голосов
/ 18 апреля 2011

Если вы можете, я бы порекомендовал следующее:

  • удалить существующий первичный ключ - особенно если это тоже ключ кластеризации (по умолчанию)

  • добавить новый INT IDENTITY столбец

    ALTER TABLE dbo.YourTable ADD NewID INT IDENTITY(1,1)
    
  • сделать это поле INT первичным / кластерным ключом:

    ALTER TABLE dbo.YourTable
      ADD CONSTRAINT PK_YourTable PRIMARY KEY(NewID)
    

Первичный ключ (или точнее: ключ кластеризации ) в столбце GUID - ужасная идея, приводящая к массовой фрагментации индекса и, таким образом, убивающая производительность SELECT.

Как и Кимберли Трипп - королева индексации - и другие много раз заявляли - GUID, так как ключ кластеризации не является оптимальным, поскольку из-за его случайности он приведет к большому количеству страниц и фрагментация индекса и вообще плохая производительность.

Да, я знаю - в SQL Server 2005 и более поздних версиях newsequentialid() - но даже это не является действительно и полностью последовательным и, следовательно, также страдает от тех же проблем, что и GUID - только чуть менее заметно.

Затем следует рассмотреть еще одну проблему: ключ кластеризации в таблице будет добавлен к каждой записи в каждом и каждом некластеризованном индексе в вашей таблице - таким образом, вы действительно хотите убедиться, что он как можно меньше. , Как правило, INT с 2+ миллиардами строк должно быть достаточно для подавляющего большинства таблиц - и по сравнению с GUID в качестве ключа кластеризации вы можете сэкономить сотни мегабайт хранилища на диске и в памяти сервера.

Быстрый расчет - использование INT и GUID в качестве первичного ключа и ключа кластеризации:

  • Базовая таблица с 1 000 000 строк (3,8 МБ против 15,26 МБ)
  • 6 некластеризованных индексов (22,89 МБ против 91,55 МБ)

ИТОГО: 25 МБ против 106 МБ - и это только на одном столе!

Еще немного пищи для размышлений - отличные вещи Кимберли Триппа - прочитайте это, прочитайте это снова, переварите это! Это на самом деле индексное Евангелие SQL Server.

...