Существует ли РЕАЛЬНОЕ различие в производительности между INT и первичными ключами VARCHAR?

Измените последнее утверждение следующим образом:

EXEC('SELECT * FROM ' + @tablename)

Вот как я делаю свое действие в хранимой процедуре. Первый блок объявит переменную и задает имя таблицы на основе имени текущего года и месяца, в этом случае TEST_2012OCTOBER. Затем я проверяю, существует ли он в БД, и удалите, если это произойдет. Затем следующий блок будет использовать инструкцию SELECT INTO для создания таблицы и заполнить ее записями из другой таблицы параметрами.

--DECLARE TABLE NAME VARIABLE DYNAMICALLY
DECLARE @table_name varchar(max)
SET @table_name = 
    (SELECT 'TEST_'
            + DATENAME(YEAR,GETDATE())
            + UPPER(DATENAME(MONTH,GETDATE())) )

--DROP THE TABLE IF IT ALREADY EXISTS
IF EXISTS(SELECT name 
          FROM sysobjects 
          WHERE name = @table_name AND xtype = 'U')

BEGIN
    EXEC('drop table ' +  @table_name)
END

--CREATES TABLE FROM DYNAMIC VARIABLE AND INSERTS ROWS FROM ANOTHER TABLE
EXEC('SELECT * INTO ' + @table_name + ' FROM dbo.MASTER WHERE STATUS_CD = ''A''')
159
задан Jake McGraw 4 December 2008 в 20:49
поделиться

7 ответов

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

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

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

Другие люди делают правильное замечание, что редко на практике для естественного ключа никогда не изменить или иметь дубликаты, таким образом, суррогатные ключи обычно стоят.

73
ответ дан Tamlyn 4 November 2019 в 17:21
поделиться

Не уверенный в последствиях производительности, но кажется, что возможный компромисс, по крайней мере, во время разработки, должен был бы включать обоих автоувеличенный, целочисленный "суррогатный" ключ, а также Ваш намеченный, уникальный, "естественный" ключ. Это дало бы Вам возможность оценить производительность, а также другие возможные проблемы, включая изменяемость естественных ключей.

0
ответ дан George Jempty 4 November 2019 в 17:21
поделиться

Абсолютно нет.

я сделал несколько... несколько... проверки производительности между INT, VARCHAR и CHAR.

10 миллионов рекордных таблиц с PRIMARY KEY (уникальный и кластеризируемый) имели ту же самую скорость и производительность (и стоимость поддерева), неважно, какой из трех я использовал.

, Что быть сказанным... использует то, что является лучшим для Вашего приложения. Не волнуйтесь о производительности.

34
ответ дан Timothy Khouri 4 November 2019 в 17:21
поделиться

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

INT AUTO_INCREMENT встречается "уникальный и неизменный со временем" условие. Следовательно предпочтение.

78
ответ дан Steve McLeod 4 November 2019 в 17:21
поделиться

Что касается Первичного ключа, независимо от того, что физически делает строку уникальной, должен быть определен как первичный ключ.

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

drawaback к использованию суррогата - то, что Вы могли возможно позволить изменяться значения суррогата:

ex.
id value
1 A
2 B
3 C

Update 3 to D
id value
1 A
2 B
3 D

Update 2 to C
id value
1 A
2 C
3 D

Update 3 to B
id value
1 A
2 C
3 B

Все это зависит от того, о чем действительно необходимо волноваться в структуре и что означает больше всего.

6
ответ дан LeppyR64 4 November 2019 в 17:21
поделиться

Зависит от длины.. Если varchar будет 20 символами, и интервал равняется 4, то, если Вы используете интервал, Ваш индекс будет иметь в пять раз больше узлов на страницу индексного пространства на диске... Это означает, что пересечение индекса потребует одной пятой как многих физических и/или логических чтений..

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

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

Для определенного использования Вы говорите о (как поиски состояния), оно действительно не имеет значения, потому что размер таблицы является настолько небольшим.. В целом нет никакого влияния на производительность от индексов на таблицах меньше чем с несколькими тысячами строк...

35
ответ дан Charles Bretana 4 November 2019 в 17:21
поделиться

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

Для больших таблиц с более широким изменением среди ключа, это может быть опасно. Думайте об использовании почтового адреса/имени пользователя от таблицы User, например. Что происходит, когда у Вас есть несколько миллионов пользователей, и у некоторых из тех пользователей есть длинные имена или адреса электронной почты. Теперь любое время, необходимо присоединиться к этой таблице с помощью того ключа, это становится намного более дорогим.

9
ответ дан Joel Coehoorn 4 November 2019 в 17:21
поделиться
Другие вопросы по тегам:

Похожие вопросы: