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

Question

Для большой таблицы транзакций (100 миллионов строк, 20 ГБ), у которой уже есть первичный ключ (естественный составной ключ из 4 столбцов), поможет ли производительность добавить столбец идентификаторов и сделать его первичным ключом?

Текущий первичный ключ (естественный составной первичный ключ из 4 столбцов) выполняет свою работу, но мне сказали, что у вас всегда должен быть суррогатный ключ. Итак, можно ли повысить производительность, создав столбец идентификаторов и указав в качестве первичного ключа?

Я использую базу данных SQL Server 2008 R2.

РЕДАКТИРОВАТЬ: Эта таблица транзакцийв основном присоединяется к таблицам определений и используется для заполнения отчетов.

РЕДАКТИРОВАТЬ: Если бы я добавил суррогатный ключ, он не будет использоваться ни в каких соединениях.Будут использованы существующие ключевые поля.

РЕДАКТИРОВАТЬ: В этой таблице не будет дочерних таблиц

Answer 1

Просто добавление столбца IDENTITY и добавление нового ограничения и индекса для него вряд ли улучшит производительность. Стол будет больше, поэтому сканирование и поиск может занять больше времени. Также будет больше индексов для обновления. Конечно, все зависит от того, что вы измеряете производительность ... и намерены ли вы вносить другие изменения в код или базу данных при добавлении нового столбца. Добавление столбца IDENTITY и больше ничего не делать, вероятно, было бы неразумно.

Answer 2

Учитывая ваши правки и все разговоры, которые возникли, несмотря на вопрос, я бы предположил, что добавление столбца IDENTITY в эту таблицу принесет гораздо больше вреда, чем пользы.

Answer 3

Только если:

• у вас есть дочерние таблицы, которые больше
• , у вас есть некластеризованные индексы

В каждом из этих случаев PK (Предполагается кластеризованный) вашей таблицы будет в каждой дочерней записи / записи NC.Так что сужение кластеризованного ключа принесет пользу.

Если у вас есть только не-NC-индексы (возможно, один) и нет дочерних таблиц, все, что вы получите, это

• более широкая строка (большеиспользуемые страницы данных)
• немного меньшее B-дерево (которое является частью общего пространства)

... но вам все равно понадобится индекс / ограничение для текущегоВ любом случае 4 столбца = увеличение пробела.

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

Так что нет, вы, вероятно, не хотите этого делать.

Мы выбросили суррогатный ключ (bigint) в таблицу с миллиардом строк и перешли к фактическому ключу с 11 путями и уменьшили его.место на диске более чем на 65% из-за более простой структуры (на один индекс меньше, чуть больше строк на страницу и т. д.)

Answer 4

Единственное место, где снижается производительность, - это изменение данных в натуральном ключе. Затем изменения должны быть опубликованы во всех дочерних записях. Например, предположим, что одним из этих полей было название компании, и компания изменила свое имя, тогда все связанные записи, а их может быть миллионы, должны были бы измениться, но если вы используете суррогатный ключ, только одна запись должна будет менять. Целочисленные объединения имеют тенденцию быть быстрее (как правило, намного быстрее, чем 4-столбцовые объединения), и написание кода для объединения, как правило, также происходит быстрее. Однако, с другой стороны, наличие четырех основных полей может означать, что объединение не требуется так часто. Вставьте перформанс, чтобы получить небольшой удар, а также должен быть создан и проиндексирован суррогатный ключ. Обычно это настолько малое попадание, что оно может быть незаметным, но такая возможность есть.

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

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

Answer 5

--- РЕДАКТИРОВАТЬ: Исходя из изменений в вопросе, добавление идентификационного / суррогатного ключа не может быть решением этой проблемы.

- Оригинальный ответ.

Один из случаев повышения производительности - это когда вы используете объединения и когда у вас есть дочерние таблицы.

В отсутствие суррогатных ключей вам придется дублировать все 4 ключа th4к дочерней таблице и присоединиться к 4 столбцам.

t_parent
-------------
col1,
col2,
col3,
col4,
col5,
constraint pk_t_parent primary key (col1,col2,col3,col4)

t_child
----------
col1,
col2,
col3,
col4,
col7,
col8,
constraint pk_t_child primary key (col1,col2,col3,col4, col5),
constraint fk_parent_child foreign key (col1, col2, col3, col4) references
                                 t_parent ((col1, col2, col3, col4))

Объединения будут включать все 4 столбца ..

select t2.*
  from t_parent t1, t_child t2
  where (t1.col1 = t2.col1 and 
         t1.col2 = t2.col2 and 
         t1.col3 = t2.col3 and 
         t1.col4 = t2.col4
        )

Если вы используете суррогатный ключ и создаете уникальное ограничение для 4 столбцов (которые теперь являются частьюпервичный ключ), он будет эффективен, и данные будут по-прежнему проверяться, как и раньше.