编程知识 cdmana.com

Base de données MySQL - transactions et index

Table des matières

Un.、Services:

Quatre caractéristiques de la transaction:

Quels sont les problèmes causés par les transactions simultanées?(Quelques problèmes causés par l'isolement)

Quels sont les niveaux d'isolement des transactions?

MySQLNiveau d'isolement par défaut pour:

2.、Index:

Rôle de l'index:

Classification des indices:

Critères d'indexation :

Structure des données de l'index:


Un.、Services:

Une transaction est un ensemble logique d'opérations,Ou ils ont tous réussi.,Ou ils échouent tous.!

——————————————————————————————————

1、SQLMise en œuvre        A:1000Yuan     ——>Transfert200Yuan        B:200Yuan

2、SQLMise en œuvre        A:800Yuan       ——>                        B:400Yuan

——————————————————————————————————

Un groupeSQL Exécuter en un seul lot

Quatre caractéristiques de la transaction:

ACIDPrincipes

1.Atomicité(AtomIclty)︰La transaction est la plus petite Unit é d'exécution,Division non autorisée.L'atomicité de la transaction garantit que l'action est soit complète,Ou ça ne marche pas du tout.;


2.Cohérence(Conslstency):Avant et après les opérations d & apos; exécution,Cohérence des données, Un noeud dans lequel plusieurs transactions lisent les mêmes données
C'est la même chose. ;


3.Isolement(Isolatlon)︰Lors de l'accès simultané à la base de données,Les transactions d'un utilisateur ne sont pas perturbées par d'autres transactions, Chaque concurrent
La base de données transactionnelle est indépendante ;


4.Persistance(Durabllty) :Après qu'une transaction a été engagée.Ses modifications aux données de la base de données sont durables, Même si le nombre
La défaillance de la base de données ne devrait pas non plus avoir d'incidence sur elle. . --------Présentation des transactions

Quels sont les problèmes causés par les transactions simultanées?(Quelques problèmes causés par l'isolement)

Dans une application typique,Exécution simultanée de plusieurs transactions,Souvent, les mêmes données sont utilisées pour accomplir leurs tâches respectives( Plusieurs utilisateurs travaillant sur les mêmes données ).La concurrence, bien que nécessaire, Mais cela peut causer les problèmes suivants: .

 Sale lecture.(DIrty read) :Lorsqu'une transaction accède aux données et les modifie,Et cette modification n'a pas encore été soumise à la base de données,Puis une autre transaction a accédé à ces données,Et en utilisant ces données.Parce que ces données ne sont pas encore soumises,Donc l'autre transaction lit ces données comme"Données sales",Base"Données sales"L'opération peut être incorrecte.


Modification manquante(Lost to modlify):Quand une transaction lit une donnée,Une autre transaction a également accédé aux données,Après avoir modifié ces données dans la première transaction,,La deuxième transaction a également modifié ces données.Ainsi, le résultat de la modification dans la première transaction est perdu,Il s'agit donc d'une modification manquante.Par exemple:Services1Lire les données d'un tableauA=20,Services2Lisez aussiA=20,Services1ModifierA=A-1,Services2Modifié aussiA=A-1,Résultat finalA=19,Services1Les modifications ont été perdues

Non répétable(Unrepeatableread):Lire les mêmes données plus d'une fois dans une transaction.Avant la fin de cette affaire,Une autre transaction accède également aux données.Alors,Entre deux lectures de données dans la première transaction,En raison de la modification de la deuxième transaction, les données lues deux fois par la première transaction peuvent être différentes.Cela se produit lorsque les données lues deux fois dans une transaction sont différentes,Il s'agit donc d'une lecture non reproductible.


Lecture fictive(Phantom read):La lecture fictive est similaire à la lecture non reproductible.C'est arrivé dans une transaction(T1)Quelques lignes de données ont été lues,Puis une autre transaction simultanée(T2)Quand des données ont été insérées.Dans une requête ultérieure,Première transaction(T1)Il y aurait plus d'enregistrements qui n'existaient pas à l'origine,C'est comme si une hallucination s'était produite,C'est ce qu'on appelle la lecture fantôme..

Différence entre la lecture non répétitive et la lecture fictive ;
L'accent non répétitif est mis sur la modification, comme la lecture d'un enregistrement plusieurs fois et la découverte que certaines valeurs de colonne ont été modifiées. , L'accent est mis sur l'ajout ou la suppression, comme la lecture d'un enregistrement plusieurs fois et la découverte d'une augmentation ou d'une diminution de l'enregistrement. .

Quels sont les niveaux d'isolement des transactions?

READ-UNCOMMITTED(Lire non engagé):Niveau d'isolement le plus bas,Autoriser la lecture des modifications de données qui n'ont pas encore été soumises,Peut causer une lecture sale、Psychédélique ou non répétable.
READ-COMMITTED(Lire engagé)︰Autoriser la lecture des données déjà engagées pour les transactions simultanées,Peut empêcher la lecture sale,Mais des lectures fantaisistes ou non répétitives peuvent encore se produire.
REPEATABLE-READ(Répétable):Plusieurs lectures du même champ ont donné des résultats cohérents,À moins que les données ne soient modifiées par la transaction elle - même,Peut empêcher les lectures sales et non reproductibles,Mais des lectures fantaisistes peuvent encore se produire.
SERIALIZABLE(Sérialisable):Niveau d'isolement le plus élevé,Obéissance totaleACIDNiveau d'isolement pour.Toutes les transactions sont effectuées une par une,De cette façon, il n'y a aucune possibilité d'interférence entre les transactions,C'est - à - dire,Ce niveau empêche la lecture sale、Lecture non répétitive et fictive.

MySQLNiveau d'isolement par défaut pour:

MySQL InnoDBLe niveau d'isolement supporté par défaut pour le moteur de stockage estREPEATABLE-READ(Reliable).On peut passer par SELECT @@tx_isolation;Commandes pour voir

2.、Index:

MySQLLa définition officielle de l'index est la suivante::Index (Index)C'est de l'aide.MySQLStructure des données pour un accès efficace aux données. Extraire le tronc de la phrase , Vous pouvez obtenir la nature de l'index :L'index est une structure de données.

MySQL Les structures de données utilisées par l'index sont principalement les suivantes: BTree Index et hachage . Pour les index de hachage , La structure de données sous - jacente est la table de hachage , Par conséquent, dans la plupart des cas, il est nécessaire d'interroger un seul enregistrement , L'index de hachage peut être sélectionné , Performance de requête la plus rapide ; La plupart des autres scénarios ,Options recommandéesBTreeIndex.


MySQLDeBTree L'index utilise BDans les arbresB+Tree, Mais les deux principaux moteurs de stockage sont implémentés différemment .


MyISAM: B+TreeNoeud foliairedataLe champ contient l'adresse de l'enregistrement de données. Lors de la recherche d'index ,Commencez parB+Tree Algorithme de recherche index de recherche ,Si spécifiéKeyExiste, Alors retirez - le. data Valeur du champ ,Et puis avecdata La valeur du champ lit l'enregistrement de données correspondant à l'adresse .C'est ce qu'on appelle“Index non groupé”.
InnoDB:Son fichier de données lui - même est un fichier index.Comparé àMyISAM,Les fichiers index et les fichiers de données sont séparés, Son fichier de données de table lui - même est appuyez sur B+Tree Une structure d'index pour l'Organisation ,Noeud foliaire de l'arbredataLe domaine contient un enregistrement complet des données.Cet indexkey Est la clé primaire de la table de données ,Donc,InnoDB Le fichier de données de table lui - même est l'index principal .C'est ce qu'on appelle“Index groupé( Ou un index groupé )”. Le reste de l'index sert d'index secondaire. , Index auxiliaire data Le champ stocke la valeur de la clé primaire d'enregistrement correspondante au lieu de l'adresse ,Et ça aussi.MyISAMDifférents endroits. Lors de la recherche à partir de l'index principal ,Directement.key Les données peuvent être extraites du noeud ; Lors de la recherche à partir de l'index secondaire , Vous devez d'abord récupérer la valeur de la clé primaire , Encore une fois, index principal .Donc,, Lors de la conception de la table ,Les champs trop longs ne sont pas recommandés comme clés primaires, Les champs non monotones ne sont pas non plus recommandés comme clés primaires , Cela provoque une fragmentation fréquente de l'index primaire .

Rôle de l'index:

  • Augmenter la vitesse de requête

  • Assurer l'unicité des données

  • Peut accélérer la connexion entre le compteur et le compteur , Réaliser l'intégrité référentielle entre les tableaux

  • Lors de la recherche de données à l'aide de clauses de regroupement et de tri , Réduit considérablement le temps de regroupement et de tri

  • Optimisation de la recherche dans les champs de recherche en texte intégral .

Classification des indices:

  • Index des clés primaires (Primary Key)

Identification unique , Clé primaire non répétable , Une seule colonne peut être utilisée comme clé primaire

  • Index unique (Unique)

Évitez les colonnes en double , L'index unique peut être dupliqué , Plusieurs colonnes peuvent identifier des index uniques en bits

  • Index général (Index)

Par défaut, indexOukey Mot - clé pour définir

  • Index texte complet (FullText)

      Disponible uniquement avec un moteur de base de données spécifique ,MylSAM

      Données de localisation rapide

Critères d'indexation :

  • Plus il y a d'index, mieux c'est.

  • Ne pas indexer les données qui changent fréquemment

  • Il n'est pas recommandé d'indexer les tableaux de petites quantités de données.

  • Les index sont généralement ajoutés aux champs des critères de recherche

Structure des données de l'index:

--  Nous pouvons créer l'index ci - dessus , Spécifiez le type d'index ,Deux catégories
hashIndex des types: Requête simple rapide , Requête de plage lente 
btreeIndex des types:b+Arbre, Plus il y a de couches , Croissance exponentielle du volume des données ( On va l'utiliser. ,Parce queinnodb Il est pris en charge par défaut )

-- Les différents moteurs de stockage supportent des types d'index différents
InnoDB Services d & apos; appui,Prise en charge du verrouillage au niveau de la ligne,Soutien B-tree、Full-text Indice isométrique,Non pris en charge Hash Index;
MyISAM Transaction non prise en charge,Prise en charge du verrouillage au niveau de la table,Soutien B-tree、Full-text Indice isométrique,Non pris en charge Hash Index;
Memory Transaction non prise en charge,Prise en charge du verrouillage au niveau de la table,Soutien B-tree、Hash Indice isométrique,Non pris en charge Full-text Index;
NDB Services d & apos; appui,Prise en charge du verrouillage au niveau de la ligne,Soutien Hash Index,Non pris en charge B-tree、Full-text Indice isométrique;
Archive Transaction non prise en charge,Prise en charge du verrouillage au niveau de la table,Non pris en charge B-tree、Hash、Full-text Indice isométrique;

版权声明
本文为[LongDi - IDEA]所创,转载请带上原文链接,感谢
https://cdmana.com/2021/10/20211013211842759U.html

Scroll to Top