Первичный ключ GUID, отдельный кластерный индексный столбец

У меня есть приложение базы данных в производстве, и все таблицы используют первичные ключи GUID, которые в настоящее время устанавливаются как кластеризованные индексы. Я понимаю, что это плохой дизайн из-за соображений производительности. Я много читал по этой теме, в том числе this great article от Kimberly Tripp.Первичный ключ GUID, отдельный кластерный индексный столбец

Могу ли я улучшить производительность, просто создав автоинкрементный индексный столбец типа INT и установив его как кластеризованный индекс? Я понимаю из статьи Кимберли, что все некластеризованные индексы (например, мои первичные ключи GUID, если я это сделаю) будут ссылаться на кластеризованный индекс. Но действительно ли это улучшит производительность, если я ищу запись с использованием первичного ключа GUID в предложении WHERE?

Кроме того, нужно ли заполнять новый столбец для существующих записей в естественном порядке, когда записи были созданы для достижения выигрыша в производительности?

EDIT: Чтобы решить, является ли этот вопрос дубликат this other question: другой вопрос, спрашивает о наилучшей практике в целом относительно соображений эффективности использования первичного ключа GUID. Конкретные подходы не обсуждаются. Мой вопрос, с другой стороны, задает конкретно, добавляет ли индексный индексный индексный индекс типа INT, чтобы облегчить проблемы с помощью первичного ключа GUID. Кроме того, мой вопрос затем спрашивает, нужно ли мне заполнять новый столбец в их «естественном порядке», чтобы реализовать преимущества, которые, опять же, не рассматриваются в другом вопросе из-за его более высокого уровня общности.

источник

2015-01-14 rory.ap

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

Возможный дубликат [Каковы наилучшие методы использования GUID как первичный ключ, особенно в отношении производительности?] (http: // stackoverflow.com/questions/11938044/what-are-the-best-practices-for-use-a-guid-as-a-primary-key-specific-rega) – AHiggins

@AHiggins - см. мое редактирование. –

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

Да вы правильно кластерные ключи индекса будут присутствовать во всех некластеризованных индексов. Наличие меньшего ключа поможет сэкономить пространство на диске и в пуле буферов.
Наличие кластеризованного ключа идентификатора даст вам конец вставок таблицы и потенциально (в зависимости от нагрузки) сделает это точкой доступа для вставки. Там, где GUIDS сейчас представляют собой случайную вставку и не будут давать столько горячей точки, но будут вызывать больше разбиений на страницы, что также может негативно повлиять на производительность.
Чтобы ответить на вопрос об улучшении производительности, какова ваша текущая проблемная область? Есть ли какие-то данные, которые мы можем удалить? Если у вас сейчас нет проблем, это может не стоить изменений.
Когда вы добавляете столбец в качестве Идентичности, он должен сажать себя, и порядок действительно не имеет значения.
Если вы используете столбец INT для ключа, создайте уникальный столбельный индекс в столбце GUID, чтобы оптимизатор знал, что будет только одно значение (оптимизация) и обеспечить быстрый поиск. Сделайте покрытие, если оно не слишком дорого.

источник

2015-01-14 17:52:05

Я бы сказал, что «горячая точка вставки» намного меньше ** убийцы производительности, чем частые разрывы страниц! Горячие точки раньше были проблемой в версиях 6.5/7.0 - на самом деле это не так, как я узнал. Но Сплиты Страницы - чрезвычайно дорогие и грязные дела, которых можно избежать, если это возможно! –

Я обнаружил, что, отбрасывая фактор заполнения по индексам GUID, можно в некоторой степени облегчить проблему разбиения страниц, особенно на больших таблицах. Снижение коэффициента заполнения зарезервирует больше места на страницах, однако индексы начинают увеличиваться. В этих случаях я бы предположил, что вы можете создать составной естественный ключ в качестве кластеризованного индекса. Это сортирует таблицу в естественном порядке. – Namphibian

Включение горячих точек @marc_s приводит к конкуренции защелки, которая может определенно снизить производительность. Разделы страниц хуже, конечно, но об этом думать. SQLCAT имеет секционированную хеш-таблицу для разделения горячих точек, но имеет свои проблемы. –

Первичный ключ GUID, отдельный кластерный индексный столбец

ответ

Смежные вопросы