La base de données incrémente-t-elle automatiquement la clé primaire ?

Pas nécessairement
Les clés primaires à incrémentation automatique peuvent accélérer l'insertion de lignes, présenter des avantages en termes d'utilisation de l'espace table et rendre la fragmentation moins évidente.

Mais pour certains contenus, comme les requêtes basées sur l'uid qui sont très fréquentes et relativement concentrées, si vous n'utilisez pas l'auto-incrémentation de la clé primaire, mais utilisez uid+id comme clé primaire composite, l'efficacité de la requête augmentera, mais l'insertion et la fragmentation augmenteront. Mais si le type de stockage de la base de données est SSD, alors ce problème n'existe pas.

Donc, dans la plupart des cas, il est correct que la table ait une clé primaire à incrémentation automatique.

Pas nécessairement

Sous la structure à table unique, oui.

Dans le cas de plusieurs tables, cela n'est pas forcément nécessaire. Certaines stratégies sont requises, comme définir des suffixes différents, le même intervalle, etc.

Ceci n'est pas recommandé.

Par exemple : une table peut avoir une clé primaire à incrémentation automatique, unique au sein de la table. Lors de l'interrogation et de la mise à jour basées sur l'identifiant, l'opération peut être simplifiée. Mais d'une manière générale, lorsqu'il existe une relation avec l'entreprise et que l'unicité est requise, l'entreprise doit la maintenir de manière indépendante, par exemple en utilisant des formats ou des algorithmes, la génération de hachage, etc.

Maintenez le segment d'intervalle de clé d'incrémentation automatique, le serveur prend un segment à chaque fois et le verrou optimiste est mis à jour. Cela nécessite des tables ou des stratégies supplémentaires pour conserver ce champ.

Basé sur l'algorithme A, préfixe d'heure fixe, tel que : aaaaMMjjHHmmss + valeur mod du numéro de table + nombre aléatoire, réduisant le risque de conflit en augmentant le nombre de chiffres. Il existe une contrainte unique sur le champ de la table (mais parfois cette contrainte n'est pas fiable). Si une exception de valeur de champ en double est levée lors de l'insertion, l'insertion sera régénérée.

Basé sur l'algorithme B, préfixe d'heure fixe, tel que : aaaaMMjjHHmmss+nombre fixe de chiffres, valeur d'incrémentation automatique de collision N+nombre aléatoire. Il n'est pas nécessaire d'augmenter le nombre de bits pour réduire les risques de conflits. Lorsqu'une insertion génère une exception de valeur de champ en double, N++ se réinsère jusqu'à ce qu'il n'y ait plus de conflits. Désormais, N est utilisé comme infixe et N est mis en cache dans le serveur. Cet infixe continuera à être utilisé après le redémarrage. Si des exceptions répétées se produisent, effectuez à nouveau la même opération avec N++. Il n’est pas nécessaire de mentionner intentionnellement la valeur mod de N.

Basé sur la gestion des infixes, c'est-à-dire la communication des infixes au serveur central. On peut comprendre que la relation d'identification du serveur est mise en cache quelque part et que les infixes sont alloués dynamiquement.

Il existe de nombreuses autres méthodes, mais elles n’ont jamais été utilisées auparavant, je n’entrerai donc pas dans les détails.
L'algorithme B est simple, a moins de communication et a un nombre limité de collisions. Selon l'algorithme A, il existe un nombre infini de collisions, même si le pourcentage est très, très faible. Mais dans le cas d’une forte concurrence, l’algorithme B sera plus violent que l’algorithme A lors de l’initialisation.

La gestion des segments d'intervalle et des infixes introduisent tous deux le concept de nœud central, qui est hautement dépendant mais relativement fiable et constitue une méthode de mise en œuvre plus courante dans l'industrie.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!