Универсальные уникальные идентификаторы (UUID), определенные RFC 4122, ISO/IEC 9834–8:2005, выглядят следующим образом:

a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11

«UUID записывается как последовательность шестнадцатеричных цифр нижнего регистра, разделенная на несколько групп, разделенных дефисами, в частности, группа из 8 цифр, за которой следуют три группы из 4 цифр, за которыми следует группа из 12 цифр, всего 32 цифры, соответствующие 128 битам».

UUID/GUID следует рассматривать как число/необработанное/двоичное, а не как текст/символ/varchar!

Обычно мы видим, как люди хранят UUID в char(36) или varchar(255), что тратит впустую память и, что более важно, снижает производительность.

1. Пустая трата памяти при использовании char:

В postgresql есть тип с именем uuid (https://www.postgresql.org/docs/current/datatype-uuid.html), он будет хранить uuid используя только 128 бит/16 байт.

select
    pg_column_size('a0eebc999c0b4ef8bb6d6bb9bd380a11'::text) as text_size,
    pg_column_size('a0eebc999c0b4ef8bb6d6bb9bd380a11'::uuid) as uuid_size;
 text_size | uuid_size 
-----------+-----------
        36 |        16

В mysql обратитесь к этой статье, чтобы лучше справиться с этим:

https://mysqlserverteam.com/storing-uuid-values-in-mysql-tables/

2. Плохая производительность при использовании char

Индексация varchar медленнее, чем char, а char медленнее, чем число. (https://dba.stackexchange.com/questions/137945/indexes-integer-vs-string-performance-if-the-number-of-nodes-is-the-same)

Пример, демонстрирующий сохранение uuid с использованием встроенного типа, повышает производительность в 100 раз по сравнению с хранением как char (https://stackoverflow.com/questions/29880083/postgresql-uuid-type-performance):

-- With text index
    QUERY PLAN
    Index Scan using tmptable_pkey on tmptable (cost=0.41..1024.34 rows=1 width=1797) (actual time=0.183..2.632 rows=1 loops=1)
      Index Cond: (primarykey = '755ad490-9a34-4c9f-8027-45fa37632b04'::text)
    Planning time: 0.121 ms
    Execution time: 2.652 ms

    -- With a uuid index 
    QUERY PLAN
    Index Scan using idx_tmptable on tmptable (cost=0.29..2.51 rows=1 width=1797) (actual time=0.012..0.013 rows=1 loops=1)
      Index Cond: (uuidkey = '755ad490-9a34-4c9f-8027-45fa37632b04'::uuid)
    Planning time: 0.109 ms
    Execution time: 0.029 ms