Каковы различные варианты и их компромиссы для хранения UUID в таблице MYSQL? - PullRequest
Новая
       17

Каковы различные варианты и их компромиссы для хранения UUID в таблице MYSQL?

3 голосов
/ 01 сентября 2009

Я планирую использовать предоставляемые клиентом UUID в качестве первичного ключа в нескольких таблицах в базе данных MySQL.

Я сталкивался с различными механизмами хранения UUID в базе данных MySQL, но не с чем сравнивал их. Они включают в себя хранение как:

  • БИНАРНЫЙ (16)
  • СИМ (16)
  • СИМ (36)
  • УАКСНАК (36)
  • 2 х BIGINT

Есть ли лучшие варианты, как они сравниваются друг с другом с точки зрения:

  • Размер хранилища?
  • накладные расходы на запрос? (вопросы индекса, присоединения и т. д.)
  • простота вставки и обновления значений из кода клиента? (обычно Java через JPA)

Существуют ли различия в зависимости от того, какую версию MySQL вы используете, или механизм хранения? В настоящее время мы работаем с 5.1 и планировали использовать InnoDB. Я приветствую любые комментарии, основанные на практическом опыте использования UUID. Спасибо.

Ответы [ 2 ]

3 голосов
/ 01 сентября 2009

Я хотел бы сохранить его в столбце Binary (16), если вы действительно настроены на использование UUID. что-то вроде 2x bigint было бы довольно громоздким в управлении. Кроме того, я слышал о людях, обращающих их вспять, потому что начало идентификаторов UUID на одной и той же машине, как правило, одинаково в начале, а разные части - в конце, поэтому, если вы поменяете их местами, ваши индексы будут более эффективными. ,

Конечно, мой инстинкт говорит, что вы должны использовать целые числа с автоинкрементом, если у вас нет действительно веской причины для использования UUID. Одна из веских причин - создание уникальных ключей в разных базах данных. Другой вариант заключается в том, что вы планируете иметь больше записей, чем INT может хранить. Хотя не так много приложений действительно нуждаются в таких вещах. При использовании целых чисел для ваших ключей теряется не только эффективность, но и с ними сложнее работать. они слишком длинные для ввода, и передача их по вашим URL делает URL очень длинными. Поэтому, если вам это нужно, используйте UUID, но старайтесь держаться подальше.

1 голос
/ 01 сентября 2009

Я использовал UUID для интеллектуального клиента онлайн / офлайн-хранения и синхронизации данных, а также для баз данных, которые, как я знал, должны были быть объединены в какой-то момент. Я всегда использовал char (36) или char (32) (без тире). Вы получаете небольшой прирост производительности по сравнению с varchar, и почти все базы данных поддерживают char. Я никогда не пробовал бинарный или бигтинт. Следует помнить, что char будет заполняться пробелами, если вы не используете 36 или 32 символа. Дело в том, что не пишите модульный тест, который устанавливает идентификатор объекта для «тестирования», а затем попытайтесь найти его в базе данных. ;)

...