MySQL et UUID : comprendre cet identifiant unique UUID

Lorsque l’on débute avec MySQL, il y a toujours un moment où l’on tombe sur un mot étrange qui semble sorti d’un roman de science-fiction : UUID. Beaucoup se demandent ce que c’est, si cela remplace les identifiants auto-incrémentés, ou si cela sert uniquement aux développeurs qui construisent des applications gigantesques. Vous le verrez, derrière ce terme un peu intimidant se cache un concept très simple, très utile, et qui peut changer votre manière de structurer une base de données MySQL.

• Comprendre enfin ce que sont les UUID et savoir choisir le type d’identifiant réellement adapté à la croissance d’un projet.
• Découvrir comment les UUID renforcent la flexibilité, la sécurité et la robustesse des bases MySQL, même dans des architectures distribuées.
• Savoir quand et pourquoi adopter les UUID pour éviter les conflits d’identifiants et préparer sereinement l’évolution future d’une application.

Avant de plonger dans les détails techniques, prenons un peu de recul. Imaginez que MySQL soit une grande bibliothèque et que chaque livre représente une ligne dans une table. Comme dans toute bibliothèque, il faut un moyen sûr d’identifier chaque livre, même si deux ouvrages portent exactement le même titre. L’UUID joue ce rôle, mais d’une manière bien plus robuste que les systèmes d’identifiants classiques. Et c’est justement ce qui le rend si précieux.

Dans ce tutoriel, nous allons comprendre ce qu’est un UUID, pourquoi il existe, et comment MySQL le manipule. Nous irons pas à pas, comme si vous découvriez MySQL pour la première fois, afin que chaque notion devienne totalement claire.

Comprendre ce qu’est réellement un UUID

Le terme UUID signifie Universally Unique Identifier. Traduit littéralement, cela donne identifiant unique universel. L’idée est d’avoir un identifiant si improbable à dupliquer que l’on peut le considérer comme absolument unique à l’échelle du monde.

Un UUID ressemble souvent à une longue chaîne de caractères découpée en plusieurs blocs. Par exemple, voici un UUID tout à fait valide :

550e8400-e29b-41d4-a716-446655440000

En voyant ce genre d’identifiant, certains débutants pensent immédiatement qu’ils devront saisir cela à la main. Heureusement, ce n’est jamais le cas. MySQL, PHP, Python, JavaScript et pratiquement tous les langages actuels savent générer automatiquement des UUID.

La particularité d’un UUID est qu’il ne dépend pas d’une table, ni d’un serveur, ni même d’une base de données précise. Il peut être créé sur deux machines différentes, au même moment, et avoir malgré tout une garantie quasi absolue d’unicité. Cela permet de créer des systèmes distribués, d’importer ou d’exporter des données entre plusieurs bases sans se soucier de conflits d’identifiants.

Pourquoi existe-t-il plusieurs versions d’UUID ?

Si vous fouillez un peu le sujet, vous verrez qu’il existe plusieurs versions d’UUID, comme UUIDv1, UUIDv4, UUIDv7… Cela peut sembler déroutant, mais rassurez-vous, les utiliser reste simple.

Chaque version définit une manière différente de générer l’identifiant. Pour vous donner une idée pratique, sans entrer dans des détails trop académiques, voici comment les comprendre mentalement.

UUIDv1 utilise un mélange de timestamp précis et d’informations matérielles (comme l’adresse MAC). C’est une version ancienne et parfois critiquée car elle peut révéler des éléments sur la machine qui l’a générée.

UUIDv4 est basé en grande partie sur l’aléatoire. C’est aujourd’hui la version la plus utilisée, notamment car elle ne divulgue aucune information technique et reste extrêmement simple à produire.

UUIDv7, plus récente, est une version hybride conçue pour être triable par date, ce qui facilite les recherches dans MySQL et améliore parfois les performances.

Pour un débutant, comprendre ces différences suffira largement. Dans la plupart des projets web, on utilise naturellement des UUIDv4, sauf exigence particulière.

Comment MySQL stocke un UUID ?

MySQL permet de stocker un UUID sous plusieurs formes. Beaucoup de développeurs débutants choisissent de le stocker en VARCHAR(36) car c’est lisible et correspond à la forme standard avec les tirets.

Mais MySQL ne s’arrête pas là. Il est également possible de stocker un UUID en binaire, en utilisant un champ BINARY(16). Ce format est plus compact, plus performant, et économise de la place sur le disque. Cela peut sembler anecdotique pour un petit projet, mais devient précieux lorsque la base dépasse quelques millions de lignes.

Pour que cela fonctionne, MySQL propose deux fonctions essentielles :

• UUID_TO_BIN() convertit un UUID texte vers une version binaire ;
• BIN_TO_UUID() fait l’opération inverse et permet de retrouver l’identifiant lisible.

Un exemple simple pour sauvegarder un UUID dans un champ binaire pourrait ressembler à ceci :

INSERT INTO users (id, name)
VALUES (UUID_TO_BIN(UUID()), 'Alice');

On voit ici que MySQL génère lui-même l’UUID, le convertit en binaire, puis l’insère. La table ne contient donc pas de numéro croissant, mais un identifiant réellement unique, prêt à être utilisé partout.

Utiliser un UUID dans une table MySQL : comment cela change votre manière de penser les identifiants

Lorsque l’on débute avec MySQL, on crée presque toujours une table avec un champ id en INT AUTO_INCREMENT. C’est simple, c’est lisible, et cela fonctionne très bien. Alors pourquoi changer une formule gagnante et se tourner vers les UUID ?

Pour répondre honnêtement, il faut comprendre une chose essentielle : un identifiant auto-incrémenté n’est unique que dans le cadre d’une table donnée. Si vous fusionnez deux bases de données, vous risquez des collisions. Si vous supprimez une ligne, les prochains identifiants ne s’adaptent pas, ce qui peut créer des trous dans la séquence. Et surtout, si vous avez plusieurs serveurs qui échangent des données, il devient très difficile de garantir que deux lignes distinctes auront des identifiants différents.

Le rôle de l’UUID est d’éliminer tous ces problèmes structurels. Grâce à lui, vous pouvez créer une ligne dans MySQL sans vous demander si un autre serveur génère au même moment le même identifiant. Cela donne une liberté impressionnante lorsqu’on commence à travailler sur des applications modernes, où les données circulent entre plusieurs services.

Un petit exemple concret pour visualiser cela. Imaginez que vous développiez une application mobile et une interface web liées à votre projet. L’application génère des données hors connexion, puis les envoie au serveur lorsqu’une connexion est disponible. Sans UUID, vous seriez obligé d’attendre la réponse du serveur pour assigner un identifiant. Avec un UUID, votre application peut créer les données immédiatement et les synchroniser plus tard, sans risque de doublons. Ce simple détail change totalement votre architecture, et en pratique, simplifie énormément votre code client.

Les limites des UUID : parce qu’aucune technologie n’est parfaite

Même si les UUID brillent par leur puissance et leur flexibilité, ils ne sont pas magiques. Il est important d’en connaître les limites pour éviter les mauvaises surprises.

La première contrainte concerne la lisibilité. Un identifiant numérique tel que 42 est extrêmement simple à retenir, à transmettre ou à écrire dans une URL. À l’inverse, un UUID ressemble à une incantation dans une langue oubliée. Il est très rare qu’un humain manipule cela sans faire d’erreur. Cela pousse certains développeurs à conserver des identifiants auto-incrémentés pour l’affichage public et à utiliser les UUID uniquement en interne.

La seconde limite touche les performances. Un INT occupe beaucoup moins de place en mémoire qu’un VARCHAR(36). Et lorsqu’une table dépasse plusieurs millions de lignes, cette différence finit par devenir sensible. Toutefois, comme nous l’avons vu, stocker un UUID dans un champ BINARY(16) permet de contourner ce problème, ce qui réduit nettement l’écart de performance.

Enfin, il existe un dernier point, plus subtil : les UUID ne sont pas triés naturellement. Si vous insérez dix lignes dans une table, leurs identifiants ne se suivront pas dans l’ordre chronologique. Cela complique parfois la lecture ou le débogage. C’est l’une des raisons pour lesquelles les nouvelles versions d’UUID, comme l’UUIDv7, ont été imaginées, car elles réintroduisent une notion d’ordre temporel.

MySQL, UUID et indexing : un trio qui demande quelques précautions

Comme dans toute base de données relationnelle, les index sont essentiels pour accélérer les recherches. Lorsque vous passez d’un identifiant entier à un identifiant UUID, MySQL doit gérer des valeurs beaucoup plus grandes et moins prévisibles. Cela influence naturellement la manière dont MySQL construit ses index.

Avec un AUTO_INCREMENT, les valeurs montent progressivement. MySQL ajoute donc toujours les nouvelles lignes à la fin de l’index, ce qui est très performant. En revanche, un UUIDv4 étant entièrement aléatoire, MySQL doit insérer les données à des positions plus randomisées. Cela entraîne une fragmentation de l’index, c’est-à-dire que les pages internes se retrouvent dispersées, ce qui peut légèrement ralentir les insertions.

Ce n’est pas dramatique, notamment pour les petites et moyennes bases, mais il est utile d’en avoir conscience. Si votre projet vise des centaines de millions de lignes, il faudra probablement optimiser les index ou envisager des UUID ordonnés, comme les UUIDv7, qui s’insèrent plus proprement.

Pour illustrer ce phénomène, voici une anecdote assez révélatrice. Un groupe avait choisi d’utiliser uniquement des UUID pour toutes leurs tables, persuadé que c’était plus “professionnel”. Lors de la démonstration finale, l’application fonctionnait bien… sauf qu’un simple tri par date mettait plus de trois secondes à s’afficher. Après investigation, ils ont découvert qu’ils utilisaient des UUIDv4 sans index adaptés. Rien de catastrophique, mais l’occasion parfaite d’expliquer que chaque outil doit être choisi pour de bonnes raisons.

Comment générer un UUID directement dans MySQL ?

MySQL propose une fonction intégrée très simple pour créer un UUID : la fonction UUID().

Si vous souhaitez tester rapidement son fonctionnement, vous pouvez exécuter :

SELECT UUID();

Vous obtiendrez une chaîne de 36 caractères ressemblant à un code secret de coffre-fort. Cette fonction est extrêmement pratique, car elle permet de laisser MySQL gérer lui-même l’unicité des identifiants, sans dépendre du langage utilisé côté serveur.

Des formations informatique pour tous !

Débutant ou curieux ? Apprenez le développement web, le référencement, le webmarketing, la bureautique, à maîtriser vos appareils Apple et bien plus encore…

Formateur indépendant, professionnel du web depuis 2006, je vous accompagne pas à pas et en cours particulier, que vous soyez débutant ou que vous souhaitiez progresser. En visio, à votre rythme, et toujours avec pédagogie.

Découvrez mes formations Qui suis-je ?

Pour aller un peu plus loin, vous pouvez générer un UUID et le stocker directement dans une table sous sa forme lisible :

INSERT INTO produits (id, nom)
VALUES (UUID(), 'Chaise en bois');

Ou en version optimisée, si votre table utilise BINARY(16) :

INSERT INTO produits (id, nom)
VALUES (UUID_TO_BIN(UUID()), 'Chaise en bois');

Avec ces deux lignes, vous disposez déjà de l’essentiel pour travailler proprement avec les UUID.

Quand faut-il choisir un UUID plutôt qu’un identifiant auto-incrémenté ?

Il arrive un moment, en travaillant avec MySQL, où l’on se demande quel est le meilleur choix entre un identifiant classique et un UUID. La réponse dépend énormément de votre projet, de votre manière de structurer vos données et de vos besoins futurs.

Un identifiant numérique fonctionne très bien lorsque l’application est simple, installée sur un seul serveur, et que les données ne voyageront pas entre plusieurs systèmes. C’est le cas de nombreux sites vitrines, petites applications internes d’entreprise ou projets scolaires. Dans ces contextes, un AUTO_INCREMENT permet de garder des identifiants lisibles, pratiques, rapides à trier et extrêmement faciles à manipuler.

À l’inverse, un UUID devient pertinent dès que vos données risquent d’être partagées, synchronisées ou dupliquées. Prenons un exemple concret. Supposons que vous développiez un service de création de devis pour votre micro-entreprise. Si vous décidez plus tard de créer une application mobile, puis un outil hors-ligne utilisé sur plusieurs appareils, vous aurez soudain besoin d’un identifiant universel pour éviter les conflits quand toutes ces données reviendront sur le serveur. Dans cette situation, un UUID apporte une tranquillité d’esprit inégalable.

Il existe aussi un cas plus subtil où l’UUID trouve sa place : la sécurité. Un identifiant auto-incrémenté révèle toujours une information sur votre base. Si le dernier identifiant public affiché dans une URL est 528, on comprend vite que l’application contient environ 528 lignes. Avec un UUID, cette information disparaît totalement. Cela ne transforme pas votre application en forteresse, bien sûr, mais évite de divulguer des données structurantes à un utilisateur mal intentionné.

Manipuler les UUID dans MySQL : lecture, mise à jour et suppression

Une fois que vous avez choisi d’utiliser un UUID, vous devez aussi comprendre comment le manipuler au quotidien. En apparence, rien ne change : les requêtes fonctionnent exactement comme avec un identifiant numérique. Mais en pratique, certaines petites habitudes évoluent.

Pour sélectionner une ligne en utilisant un UUID lisible, vous pourriez écrire :

SELECT * FROM utilisateurs
WHERE id = '550e8400-e29b-41d4-a716-446655440000';

C’est simple, mais il faut être vigilant : un seul caractère manquant et la ligne ne sera pas trouvée. C’est pourquoi beaucoup de développeurs préfèrent copier-coller les UUID plutôt que de les taper à la main.

Lorsque l’identifiant est stocké au format binaire, la syntaxe change légèrement, car il faut convertir l’UUID lisible avant la comparaison :

SELECT * FROM utilisateurs
WHERE id = UUID_TO_BIN('550e8400-e29b-41d4-a716-446655440000');

Le même principe s’applique pour les mises à jour :

UPDATE utilisateurs
SET nom = 'Nouveau nom'
WHERE id = UUID_TO_BIN('550e8400-e29b-41d4-a716-446655440000');

Et pour les suppressions :

DELETE FROM utilisateurs
WHERE id = UUID_TO_BIN('550e8400-e29b-41d4-a716-446655440000');

Ces exemples montrent qu’un UUID ne complique pas réellement la syntaxe SQL, mais demande simplement plus de rigueur. Finalement, c’est un peu comme passer d’une adresse postale simple à une adresse GPS très précise. On gagne en puissance, mais il faut être attentif.

UUID et migrations de bases de données : un allié précieux lors des évolutions d’un projet

Beaucoup de développeurs rencontrent un jour un problème délicat : comment fusionner deux bases de données qui ont vécu séparément pendant des mois, voire des années ? Lorsqu’on utilise des identifiants auto-incrémentés, cela peut tourner au casse-tête.

Imaginez deux tables clients, chacune avec ses propres identifiants numériques. Dans la première base, un client Martin Dupont a l’identifiant 12. Dans l’autre base, l’identifiant 12 correspond à Sophie Martin. Si vous tentez de fusionner, vous créez un conflit. Vous devrez renuméroter, vérifier les relations, reconstruire les liens, bref… c’est une opération parfois longue et anxiogène.

Avec des UUID, ces difficultés disparaissent presque entièrement. Chaque ligne garde son identifiant universel, et vous pouvez fusionner les données comme on rassemble deux puzzles complètement différents. Aucun numéro ne se marche dessus, aucune référence ne s’effondre, et vous gardez une cohérence absolue.

Dans le cadre d’applications modernes, où les micro-services, les sauvegardes décentralisées ou les exports multiples deviennent courants, cette propriété transforme radicalement la manière de gérer les migrations de données. Et cela explique pourquoi tant de frameworks récents adoptent les UUID par défaut.

Bonnes pratiques pour utiliser les UUID efficacement dans MySQL

Lorsque l’on adopte les UUID dans MySQL, quelques habitudes simples permettent d’obtenir un système propre, performant et durable. Ce ne sont pas des règles strictes, mais plutôt des repères qui aident à éviter les pièges les plus courants.

La première bonne pratique consiste à choisir le bon format de stockage. Pour un usage professionnel ou pour un projet amené à évoluer, préférer un champ BINARY(16) plutôt que VARCHAR(36) est souvent un excellent choix. Cela réduit la taille des index, accélère les recherches et diminue le poids global de la base. Si vous débutez, cela peut sembler secondaire, mais vous serez heureux d’avoir anticipé ces détails lorsque votre application gagnera en utilisateurs.

Ensuite, il est essentiel d’uniformiser la génération des UUID. Autrement dit, choisissez une version (UUIDv4 ou UUIDv7 par exemple) et tenez-vous-en. Mélanger plusieurs versions peut compliquer l’ordre des résultats ou perturber certaines optimisations. En général, l’UUIDv4 reste le meilleur compromis entre simplicité et sécurité, tandis que l’UUIDv7 devient intéressant pour les systèmes qui ont besoin de trier facilement les données par date.

Enfin, gardez en tête que les UUID ne remplacent pas toutes les formes d’identification. Il est courant d’utiliser un UUID comme clé primaire tout en conservant des champs plus lisibles pour l’utilisateur, comme un numéro de dossier, une référence interne ou un slug simplifié. Ce sont deux rôles différents : l’UUID assure l’unicité technique, tandis que l’identifiant lisible facilite l’expérience utilisateur.

Intégrer les UUID dans un projet existant : est-ce réaliste ?

Beaucoup se demandent s’il est possible d’introduire les UUID dans une base de données MySQL déjà en production. La réponse est oui, mais l’opération demande un peu de méthode. Il faut créer un nouveau champ, générer un UUID pour chaque ligne existante, mettre à jour les relations, puis basculer progressivement les requêtes vers ce nouvel identifiant.

Ce type de migration peut sembler impressionnant, mais il se déroule souvent sans douleur lorsque l’on procède étape par étape. L’avantage, c’est qu’une fois la transition terminée, la base devient beaucoup plus flexible et résiliente. Pour reprendre une image familière, c’est un peu comme réorganiser un atelier de bricolage : le jour-même, tout paraît sens dessus dessous, mais une fois rangé, on ne voudrait plus jamais revenir à l’ancien système.

Certains frameworks modernes, comme Laravel ou Symfony, proposent même des outils intégrés pour gérer automatiquement les UUID dans MySQL. Cela vous enlève une bonne partie du travail, tout en garantissant une cohérence irréprochable.

Pourquoi les UUID sont devenus incontournables dans les applications modernes

Si les UUID se sont autant imposés ces dernières années, c’est parce que les applications ne ressemblent plus à celles que l’on développait il y a dix ou quinze ans. Les systèmes sont désormais distribués, parfois même éclatés en dizaines de micro-services. Les données voyagent entre plusieurs environnements, sont synchronisées en ligne et hors ligne, et doivent pouvoir être fusionnées sans conflit.

Dans ce contexte, un identifiant auto-incrémenté, aussi pratique soit-il, manque de flexibilité. L’UUID, en revanche, n’a pas besoin d’un serveur central pour garantir son unicité. Il offre une liberté totale sur la manière de créer, stocker, déplacer et synchroniser les informations. Cette évolution naturelle reflète simplement la manière dont les applications modernes fonctionnent aujourd’hui.

De plus, la montée en puissance du cloud et des architectures distribuées a rendu l’identifiant universel quasiment indispensable. Le fait de pouvoir générer un identifiant depuis n’importe quel appareil, même hors connexion, sans risque de duplication, correspond parfaitement aux besoins de notre époque.

Un petit identifiant pour un grand changement de perspective

Si l’on résume l’aventure que nous venons de parcourir, l’UUID est bien plus qu’une longue série de caractères étranges. C’est un outil pensé pour résoudre des problèmes que l’on ne voit apparaître qu’au moment où un projet commence à grandir. Là où un identifiant auto-incrémenté convient pour une petite application, l’UUID ouvre la porte à des architectures plus robustes, plus flexibles et bien mieux adaptées aux usages modernes.

Adopter les UUID dans MySQL, ce n’est pas seulement changer de manière d’identifier une ligne. C’est aussi accepter une nouvelle façon de structurer les données, une vision plus universelle et moins dépendante d’un seul serveur. Ce changement peut sembler anodin, mais il transforme parfois profondément l’organisation d’un projet.

Et peut-être est-ce là l’essentiel : apprendre à choisir les bons outils au bon moment. L’UUID ne remplacera jamais la simplicité d’un identifiant numérique dans un petit projet, mais il devient un allié incontournable dès que les données doivent voyager, se synchroniser ou grandir avec vous. En comprenant ses forces, ses limites et ses usages, vous possédez maintenant tout le nécessaire pour décider, en toute autonomie, si l’UUID est le bon choix pour votre prochaine base de données MySQL.

Alban

Fondateur de l’agence Créa-troyes, affiliée France Num
Intervenant en Freelance.
Contactez-moi

crea-troyes.fr