MYSQL: Каково влияние длины varchar на производительность при использовании первичного ключа? [Дубликат]
Хорошим примером использования обеих функций является:
>>> def foo(*arg,**kwargs):
... print arg
... print kwargs
>>>
>>> a = (1, 2, 3)
>>> b = {'aa': 11, 'bb': 22}
>>>
>>>
>>> foo(*a,**b)
(1, 2, 3)
{'aa': 11, 'bb': 22}
>>>
>>>
>>> foo(a,**b)
((1, 2, 3),)
{'aa': 11, 'bb': 22}
>>>
>>>
>>> foo(a,b)
((1, 2, 3), {'aa': 11, 'bb': 22})
{}
>>>
>>>
>>> foo(a,*b)
((1, 2, 3), 'aa', 'bb')
{}
4 ответа
, с другой стороны, я могу себе представить, что внутренне СУБД будет вычислять хэш-ключи для уменьшения штрафа.
БД необходимо поддерживать B-Tree (или аналогичное структуры) с ключом, чтобы упорядочить их.
Если ключ хэширован и сохранен в B-Tree, это будет прекрасно проверять уникальность ключа - ключ все равно может быть эффективно просмотрен. Но вы не сможете эффективно искать диапазон данных (например, с помощью
LIKE), поскольку B-Tree больше не упорядочивается в соответствии со значением String.Итак, я думаю, что большинство БД действительно хранят String в B-Tree, которое может (1) занимать больше места, чем числовые значения, и (2) требовать перебалансировки B-Tree, если ключи вставлен в произвольном порядке (нет понятия увеличения значения, как с числовым pk).
Штраф на практике может варьироваться от незначительного до огромного. Все зависит от использования, количества строк, среднего размера строкового ключа, запросов, которые соединяют таблицу и т. Д.
В нашем продукте мы используем varchar (32) для первичных ключей (GUID), и мы не сталкивались с такими проблемами производительности. Наш продукт представляет собой веб-сайт с экстремальной перегрузкой и имеет решающее значение для стабильности. Мы используем SQL Server 2005.
Редактирование: в наших самых больших таблицах у нас есть более 3 000 000 записей с большим количеством вставок и выбора из них. Я думаю, в общем, преимущество перехода на ключ int будет очень низким, но проблемы при очень высокой миграции.
-
1В SQL Server существует тип GUID. Кроме того, он идеально подходит для репликации. – Timmy 12 February 2010 в 14:14
Это зависит от нескольких факторов: RDBMS, количества индексов, связанных с этими столбцами, но в целом это будет более эффективно с использованием ints, представленным bigints.
Любой прирост производительности зависит от использования, поэтому без конкретных примеров схемы таблицы и рабочей нагрузки запроса трудно сказать.
Если это не имеет смысла в домене (я думаю, что-то уникальное, например, номер социального страхования), суррогатный целочисленный ключ является хорошим выбором; ссылающиеся объекты не нуждаются в обновлении их FK-ссылки при изменении объекта-ссылки.
Одна вещь, на которую нужно обратить внимание - это разбиение на страницы (я знаю, что это может произойти в SQL Server - возможно, то же самое в MySQL).
Первичные ключи физически упорядочены. Используя целое число с автоматическим добавлением, вы гарантируете, что каждый раз, когда вы вставляете, вы вставляете следующий номер вверх, поэтому нет необходимости переустанавливать ключи для db. Однако, если вы используете строки, вы можете вставить pk в середине других ключей для поддержания порядка pk. Этот процесс переупорядочения pks на вставке может стать дорогим.