Для хранения 128-битного UUID есть несколько вариантов хранения:
- байт [16] столбец
- два столбца bigint / long (64 бит)
- столбец CHAR (36) - 32 шестнадцатеричных числа + 4 тире.
- специфичный для базы данных столбец UUID, если db поддерживает его
С точки зрения индексации, какие из них наиболее эффективны? Если БД не поддерживает выделенный тип uuid, какие из 1, 2, 3 являются лучшими кандидатами?
sql-server
mysql
oracle
postgresql
index
Влад Михалча
источник
источник
raw(16)в Oracle иuuidв PostgreSQL.uuid>>bytea>>textсCHECKограничением>varchar(36)>>char(36). См. Dba.stackexchange.com/a/89433/3684 и dba.stackexchange.com/a/115316/3684 .Ответы:
Выделенный
uuidтип - ваш лучший выбор для PostgreSQL. Трудно сказать с другими БД - для кого-то не исключено, что кто-то может реализоватьuuidтип, который хранится менее эффективно, чем простой тип байта.Опять же, в PostgreSQL,
byteaбудет разумным способом хранить UUID, если у вас нет этогоuuidтипа. Для других БД это зависит от того, как они хранят двоичные данные.Там, где это возможно, я бы сильно избегал использования шестнадцатеричных черточек. Это гораздо менее эффективно сравнивать, сортировать и хранить.
Так что на самом деле, «не (2) или (3)». Когда-либо. Используйте (4), где поддерживается, (1) в противном случае.
источник
SELECT ARRAY['ef1e0638-072e-4caa-88b3-97bfa5b2e8c3']::uuid[]В порядке предпочтения: 4,1,2,3 Не используйте UUID в качестве ключа кластеризации, если используется сервер SQL, поскольку он не только плохо фрагментируется, ключ кластеризации используется во всех некластеризованных индексах, и вы добавляете эти байты в каждая строка индекса. Фрагментация может быть уменьшена с помощью NEWSEQUENTIALID, но обычно предпочитает идентификацию bingint для вашего ключа кластеризации над GUID для предотвращения раздувания в других индексах.
Разница между выбором 1 вместо 2 будет зависеть от того, насколько более эффективно база данных обрабатывает два столбца базовых типов в одном столбце фиксированного массива. Это должно быть достаточно легко проверить с помощью фиктивных данных. Посмотрите на скорость ваших запросов, а также размер индексов и данных. Маленький + быстрый лучший!
источник
Можно было бы предположить, что любой тип данных с внутренней поддержкой будет лучше оптимизирован в продукте, чем что-либо, что может быть объединено в качестве клиента этого продукта. После этого все, что имеет наименьшее количество байтов, позволяет получить максимальное количество строк на странице.
источник