La plupart des clés primaires ne doivent être que des nombres entiers (auto-incrémentés) ou des codes uniques générés par le système (tels que l'UUID) ; j'aimerais demander quels sont les avantages et les inconvénients de chacun de ces deux, et j'espère parler de l'expérience réelle.
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
L'ID à incrémentation automatique économise de l'espace de stockage et l'index de clé primaire n'a pas de problème d'insertion et de réorganisation. L'inconvénient est que la quantité de données est limitée et qu'un maximum de 2 ^ 63 enregistrements peuvent être stockés.
uuid est généralement une chaîne, qui consomme plus d'espace de stockage qu'un entier et nécessite une réorganisation de l'index lors de l'insertion. En principe, il n’y a pas de limite supérieure à la quantité.
Type entier (l'index de MySQL est enregistré sous la forme d'un fichier, le type entier doit donc être plus petit que l'UUID), et comme il s'agit d'un type entier, l'efficacité de l'indexation doit être supérieure à l'UUID, mais comme il est automatiquement incrémenté, mysql le fera Lors de l'insertion de données, la table doit être verrouillée, ce qui entraîne une surcharge importante sur le serveur MySQL sous une grande concurrence. Et l'UUID est meilleur que l'auto-incrémentation entière pour gérer la concurrence
uuid prend en charge la sous-bibliothèque
Lorsque le champ est la clé primaire, le type entier économise de l'espace par rapport au type chaîne (rappelez-vous que int ne nécessite que 4 octets et char a un octet par caractère)
Lorsque le champ n'est pas la clé primaire, en plus de économisant de l'espace, le type entier économise plus d'espace que le type chaîne. Le type est beaucoup plus rapide et il grandit géométriquement en fonction de la longueur du caractère
Pour ceux qui recherchent la perfection, les données telles que les adresses IP sont également stockées dans la base de données à l'aide d'entiers (les chaînes d'adresses IP et les entiers ont un algorithme fixe).
Par exemple : si la valeur d'un champ est 1234567890 et qu'il n'y a pas de clé primaire
Lors d'une requête SQL où l'identifiant >= '1234567890'
le type int ne doit être comparé qu'une seule fois
le type char doit être comparé 10 fois, chacun personnage Tout le monde doit participer à la comparaison. Donc plus les caractères sont longs, plus la vitesse est lente
Si la quantité de données dans la base de données est suffisamment importante, vous pouvez facilement vérifier la vitesse de traitement des types de caractères en exécutant un code SQL similaire
où l'identifiant est comme « 123 % » limite 5 ;
où l'identifiant est comme « 1234 % » limite 5 ;
où j'aime « 12345 % » limite 5 ;
où j'aime « 123456 % » limite 5 ;
La vitesse d'exécution du SQL ci-dessus est à son tour plus lente. Car plus les caractères sont longs, plus ils sont comparés de fois.
Peu importe la longueur du type int, il n'est comparé qu'une seule fois