GUID + идентификатор автоинкремента = низкая производительность?

Question

Один из недостатков Джеффа Этвуда в использовании GUID -

Cumbersome to debug (where userid='{BAE7DF4-DDF-3RG-5TY3E3RF456AS10}')

И я согласен. Я думал, теперь, когда 16-байтовые идентификаторы больше не считаются огромным мероприятием, 16-байтовый + 4-байтовый идентификатор - это практический компромисс?

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

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

Примечание: этот вопрос уже решал эту проблему ранее, но с точки зрения управления ссылочной целостностью. Мне просто любопытно, как я могу комбинировать комбинации конфигураций PK / UK на столе и их различное влияние на производительность и масштаб. По сути, лучше ли использовать GUID в качестве PK и автоинкремент в качестве неуникального индекса? Что лучше сделать их уникальным ключом в паре?

Спасибо за ваше время.

Answer 1

Индексирование int дешево и полезно.Индексирование GUID стоит дорого (и безопасно с веб-интерфейса; никто не сможет циклически проходить по GUID s для запроса отдельных строк из таблицы).SEQ GUID s обеспечивают (относительно) быстрые построения индекса после большого количества вставок, но устраняют большую часть "случайности", которая может обеспечить некоторую безопасность для публичного доступа.

Из этого обсуждения SQL Authority , возможная прогрессия от int -> bigint -> guid является редкой и не должна приниматься во внимание, пока время не потребует этого.Безусловно, самый безопасный и доступный способ для запуска нового проекта - это использование bigint PK AUTO_INCR с GUID в качестве неиндексированного непоследовательного поля, специально для разделения или объединения шехм на протяжении всей жизни базы данных.С точки зрения скорости это требует немедленного удара, но эти эффекты не будут ощущаться до тех пор, пока у вас не будет достаточно строк, чтобы на самом деле заботиться о таких вещах, как уникальность между экземплярами.

Answer 2

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

Вы можете использовать, например, случайное число из 20 цифр в качестве первичного ключа и использовать только это: нет необходимости в GUID!