Quelles sont les différentes options et leurs compromis pour stocker un UUID dans une table MYSQL?

Question

Je prévois d'utiliser les UUID fournis par le client comme clé primaire dans plusieurs tables d'une base de données MySQL.

J'ai rencontré divers mécanismes pour stocker des UUID dans une base de données MySQL mais rien qui les compare les uns aux autres. Ceux-ci comprennent le stockage en tant que:

• BINARY (16)
• CHAR (16)
• CHAR (36)
• VARCHAR (36)
• 2 x BIGINT

Y at-il de meilleures options, comment les options se comparent-elles en termes de:

• taille de stockage?
• requête overhead? (problèmes d'index, jointures, etc.)
• facilité d'insertion et de mise à jour des valeurs du code client? (typiquement Java via JPA)

Y a-t-il des différences selon la version de MySQL utilisée ou le moteur de stockage? Nous fonctionnons actuellement en version 5.1 et prévoyions utiliser InnoDB. Je me réjouis de tout commentaire basé sur l'expérience pratique d'essayer d'utiliser les UUID. Merci.

Answer 1

J'ai utilisé des UUID pour le stockage en ligne/hors ligne des clients intelligents et la synchronisation des données, ainsi que pour les bases de données dont je savais qu'elles devaient être fusionnées à un moment donné. J'ai toujours utilisé char (36) ou char (32) (pas de tirets). Vous obtenez un léger gain de performance par rapport à varchar et presque toutes les bases de données supportent char. Je n'ai jamais essayé binaire ou bigint. Une chose à savoir, c'est que char va remplir avec des espaces si vous n'utilisez pas 36 ou 32 caractères. Point étant, ne pas écrire un test unitaire qui définit l'ID d'un objet à "test", puis essayez de le trouver dans la base de données. ;)

Answer 2

Je voudrais aller avec le stocker dans une colonne binaire (16), si vous êtes en effet mis à utiliser les UUID du tout. quelque chose comme 2x bigint serait assez lourd à gérer. De plus, j'ai entendu parler de gens qui les renversent parce que le début des UUID sur la même machine tend à être le même au début, et les différentes parties sont à la fin, donc si vous les inversez, vos index seront plus efficaces . Mon instinct dit que vous devriez utiliser des entiers d'incrémentation automatique à moins que vous ayez une très bonne raison d'utiliser l'UUID. Une bonne raison est la génération de clés uniques à travers différentes bases de données. L'autre option est que vous prévoyez d'avoir plus d'enregistrements qu'un INT peut stocker. Bien que pas beaucoup d'applications ont vraiment besoin de choses comme ça. Il n'y a pas que beaucoup d'efficacité à perdre lorsque vous n'utilisez pas d'entiers pour vos clés, et c'est aussi plus difficile de travailler avec eux. ils sont trop longs à taper, et les transmettre dans vos URLs rendent les URL vraiment longues. Alors, allez avec l'UUID si vous en avez besoin, mais essayez de rester à l'écart.