потеря производительности строк как первичные ключи?
Какова была бы потеря производительности использования строк как первичные ключи вместо bigints и т.д.? Сравнение строк является намного более дорогим, чем целочисленное сравнение, но с другой стороны я могу предположить, что внутренне DBMS вычислит ключи хеша для сокращения штрафа.
Приложение, что я работаю над строками использования как первичные ключи в нескольких таблицах (MySQL). Это не тривиально для изменения этого, и я хотел бы знать то, что может быть полученной производительностью, мудрой для выравнивания по ширине работы.
4 ответа
с другой стороны, я могу представить, что внутри СУБД будет вычислять хэш {{1} } ключи для уменьшения штрафа.
База данных должна поддерживать B-дерево (или аналогичную структуру) с ключом, чтобы упорядочить их.
Если ключ хеширован и сохранен в B-дереве, можно быстро проверить уникальность ключа - ключ все еще можно найти эффективно. Но вы не сможете эффективно выполнять поиск для диапазона данных (например, с LIKE ), потому что B-дерево больше не упорядочивается в соответствии со значением String.
Поэтому я думаю, что большинство БД действительно хранят строку в B-дереве, которое может (1) занимать больше места , чем числовые значения, и (2) требовать, чтобы B-дерево было повторным. -balanced , если ключи вставляются в произвольном порядке (нет понятия увеличения значения, как в случае с числовым pk).
Штраф на практике может варьироваться от незначительного до огромного. Все зависит от использования, количества строк, среднего размера строкового ключа, запросов, которые присоединяются к таблице, и т. Д.
В нашем продукте мы используем varchar (32) для первичных ключей (GUID), и мы не столкнулись с проблемами производительности, связанными с этим. Наш продукт представляет собой веб-сайт с крайней перегрузкой и критически важным для его стабильности. Мы используем SQL Server 2005.
Изменить: в наших самых больших таблицах у нас есть более 3 000 000 записей с множеством вставок и выборок. от них. Я думаю, что в целом выгода от перехода на ключ int будет очень низкой, но проблемы при переходе очень высоки.
Это зависит от нескольких факторов: СУБД, количества индексов, включающих эти столбцы, но в целом будет более эффективно использовать целые числа, за которыми следуют большие числа.
Любой прирост производительности зависит от использования, поэтому без конкретных примеров схемы таблицы и рабочей нагрузки запросов трудно сказать.
Если это не имеет смысла в предметной области (я думаю, уникальное что-то вроде номера социального страхования), суррогатный целочисленный ключ - хороший выбор; ссылающиеся объекты не нуждаются в обновлении их FK-ссылки при изменении ссылочного объекта.
Одна вещь, которой следует остерегаться, это разделение страниц (я знаю, что это может произойти в SQL Server - вероятно, то же самое и в MySQL).
Первичные ключи физически упорядочены. Используя автоинкрементное целое число, вы гарантируете, что при каждой вставке вы вставляете следующий номер, поэтому у БД нет необходимости переупорядочивать ключи. Однако если вы используете строки, то вставляемый вами pk может потребоваться поместить в середину других ключей, чтобы сохранить порядок pk. Этот процесс переупорядочивания пк при вставке может оказаться дорогостоящим.