О преимуществах и недостатках использования уникального идентификатора писалось уже много где, потому этот вопрос опустим. В отдельных случаях от него есть польза, да только вот незадача — в отличие от SQL Server, MySQL не содержит типа uniqueidentifier, следовательно надо искать альтернативу. Сразу прошу прощения за отсутствие специфических алгоритмов вроде COMB, они не совсем интересовали меня на момент тестирования.

Всего было рассмотрено 3 варианта:

Текстовый формат (CHAR(36) ASCII BINARY)
простейший результат работы функции UUID() — строка формата «

1
88db0c40-0a2e-102c-915a-e960228d5a1e

». Неоспоримые плюсы — простота эксплуатации и наглядность.
Получение: UUID()

Бинарный формат (BINARY(16))
UUID() без тире и свёрнутая функцией UNHEX().
Получение: UNHEX(REPLACE(UUID(), ‘-’, »)
Числовой формат (DECIMAL(39) UNSIGNED)
Бинарный формат, приведённый в десятичную форму. Всерьёз не рассматривался, но всё же был взят для тестирования для полноты картины.
Получение: bin2decimal(UNHEX(REPLACE(UUID(), ‘-’, »))

Небольшой тест

Создаются 3 пары таблиц формата ключ — значение, где в качестве ключа выступает поле с GUID. Значение — просто генерируемая шелуха для массы. Затем в таблицы вносится по 10000 произвольных записей и производится выборка с объединением таблиц по нашему уникальному идентификатору. Для пущей наглядности соединение производилось без индексов и ключей
Сравнивалось время ответа операции

1
SELECT BENCHMARK(100, (SELECT SQL_NO_CACHE COUNT(*) FROM testtable t JOIN testtable2 t2 on t.Id = t2.Id));

Хранение GUID в MySQL