Это самый лучший способ, которым я мог придумать, чтобы преобразовать MySQL GUID/UUID, порожденную UUID() в двоичном (16):Хранение MySQL GUID/UUID,
UNHEX(REPLACE(UUID(),'-',''))
А затем хранить его в BINARY (16)
Есть ли какие-либо последствия для этого так, как я должен знать?
Не так много последствий. Это немного замедлит запросы, но вы вряд ли заметите это.
UNIQUEIDENTIFIER хранится как 16-byte binary внутренний так или иначе.
Если вы собираетесь загрузить двоичный код в клиент и проанализируйте его там, отметьте bit order, он может иметь другое строковое представление, чем начальное NEWID().
функция подвержена этой проблеме, преобразование ее в строку дает разные результаты на клиенте и на сервере.
Я бы добавил к комментарию некоторый материал, который я выкопал. Соображения вокруг UUID в MySQL должны думать о производительности, а также о уникальности. В то время как несколько старше интересный тест производительности был здесь: http://kccoder.com/mysql/uuid-vs-int-insert-performance/ - Это показывает точку чувствительности вокруг MySQL и обеспечивает «УНИКАЛЬНЫЕ» значения в MySQL. Я уверен, что были улучшения, но размер поля, структура содержащегося индекса и т. Д. Следует рассматривать, если у вас есть такая возможность. Кажется, что BINARY (16)/CHAR (16) - это путь. –
Сделав еще несколько углубленных исследований, я также получил хорошую ссылку на «обработку индексов BINARY». Вот ссылка: http://mysqlserverteam.com/storing-uuid-values-in-mysql-tables/ - Я бы рекомендовал любому, кто смотрит на преобразование в MySQL, также ознакомиться с этим блогом. Высказываются некоторые замечательные моменты, чтобы подумать о том, как «оптимально» хранить идентификатор BINARY. Ваш вариант использования может различаться в зависимости от того, как вы реализуете UUID, но отличные точки для упорядочивания битов и использования вычисленных столбцов для любых «удобочитаемых» потребностей. –
Я смущен, почему это принято, когда терминология и предположения ответа кажутся исключительными для MS SQL, а не MySQL. –
Я бы сделал его в 8-байтовое целое и сохранил целое число с использованием высокоэффективного одностороннего хэш-алгоритма с низким столкновением, такого как MurmurHash64A. Это использует намного меньше места и может быть проиндексировано и/или разделено на. Существует проект SourceForge, который включает функции MemCached для mySQL (http://forge.mysql.com/projects/project.php?id=250), которые могут включать MurmurHash64A, поскольку Memchached использует его, но я не знаю. Или посмотрите на эту реализацию FNV для mySQL: http://www.xaprb.com/blog/2008/03/09/a-very-fast-fnv-hash-function-for-mysql/
№ UUID имеет 128 бит. Если вы управляете 128-битным UUID и теряете половину своих битов (8 байтов = 64 бит), тогда нет смысла использовать UUID. Точка использования UUID должна иметь ЧРЕЗВЫЧАЙНУЮ вероятность получения дубликатов. Если вы делаете 8-битное число, переворачивая монету для каждого бита, существует 256 возможных значений. 4-битное число имеет только 16. У вас действительно есть дубликаты в 64 бит - используйте google, чтобы узнать, насколько это возможно. –
Да, но это может привести к незначительным улучшениям производительности, когда я полагался на собственное генерирование инициатора приложения и его исключение и замену (в моем случае .NET) – nawfal
@nawfal, может быть наклонным ответом на OP, но очень хотелось бы, чтобы ваш комментарий был приведен в пример с примерами. –