Mysql est une base de données relationnelle open source grand public qui fournit des services de stockage de données hautes performances. Lors du développement back-end,
vous rencontrerez parfois des goulots d'étranglement en termes de performances. Parfois, ces goulots d'étranglement ne proviennent pas de l'application elle-même, mais du niveau de la base de données.
Ainsi, maîtriser certains des principes sous-jacents de Mysql nous aidera à mieux comprendre Mysql, à effectuer des réglages de performances sur Mysql et à
développer des services back-end hautes performances.
1. Le cadre logique de mysql
Le schéma du cadre logique de mysql est le suivant :
La couche supérieure est de gérer le client Connecté .
Effectue principalement le traitement des connexions, l'authentification des autorisations, la sécurité, etc. Mysql maintient un pool de threads au niveau de cette couche pour gérer les connexions des clients. Mysql peut utiliser l'authentification par nom d'utilisateur et mot de passe,
peut également utiliser l'authentification par certificat X.509 basée sur SSL.
La deuxième couche se compose de trois parties : le cache de requêtes, l'analyseur et l'optimiseur. L'analyseur est utilisé pour analyser les instructions SQL et l'optimiseur optimisera les instructions analysées.
Avant d'analyser la requête, le serveur vérifiera d'abord le cache de requête. Si le résultat de la requête correspondant peut y être trouvé, il n'est pas nécessaire d'effectuer une analyse, une optimisation, etc. retourné directement. Les procédures stockées, les déclencheurs, les vues, etc. sont tous implémentés dans cette couche.
La troisième couche est le moteur de stockage Le moteur de stockage est responsable du stockage des données dans MySQL, de l'extraction des données, du démarrage d'une transaction, etc. Le moteur de stockage communique avec la couche supérieure via des API. Ces API masquent les différences entre les différents moteurs de stockage, rendant ces différences transparentes pour le processus de requête de la couche supérieure. Le moteur de stockage n'analysera pas SQL. Le moteur de stockage le plus couramment utilisé pour MySQL est InnoDB.
2. Contrôle de concurrence de MySQL
Si plusieurs threads exploitent des données en même temps, cela peut entraîner des problèmes de contrôle de concurrence.
2-1. Verrouillage en lecture-écriture
Si plusieurs threads ne lisent que des données, ils peuvent réellement les lire ensemble sans s'affecter les uns les autres. utilisez "read Lock", également connu sous le nom de verrou partagé.
Les threads qui acquièrent des verrous en lecture ne se bloqueront pas et pourront lire une ressource en même temps.
Si un thread a besoin d'écrire des données, il doit utiliser un "verrou en écriture", également appelé verrou exclusif.
Les verrous en écriture bloqueront les autres verrous en écriture et en lecture jusqu'à ce que l'opération d'écriture soit terminée.
2-2. Granularité du verrouillage
Tout d'abord, clarifiez un concept : sur une ressource donnée, moins il y a de données à verrouiller, plus il y a de concurrence. le système peut gérer. Plus il est élevé.
Mais le verrouillage consomme également des ressources. Si le système passe beaucoup de temps à gérer les verrous au lieu d'accéder aux données,
alors les performances du système peuvent être affectées.
Une bonne "stratégie de verrouillage" consiste donc à trouver un équilibre entre la surcharge de verrouillage et la sécurité des données. Mysql prend en charge plusieurs architectures de moteur de stockage,
Chaque moteur de stockage a Vous pouvez implémenter votre propre stratégie de verrouillage et. verrouiller la granularité.
2-3. Les verrous de table et les verrous de rangées
Les verrous de table, comme leur nom l'indique, verrouillent la table entière. Les frais généraux de verrouillage de table sont relativement faibles. Après avoir ajouté un verrou en écriture à la table, toutes les opérations de lecture et d'écriture sur la table par d'autres utilisateurs seront bloquées.
Dans Mysql, bien que le moteur de stockage puisse fournir ses propres verrous, Mysql utilise parfois des verrous de table, tels que des instructions telles que ALTER TABLE.
Les verrous en écriture ont une priorité plus élevée que les verrous en lecture, donc une demande de verrouillage en écriture peut être insérée au début de la file d'attente des verrous en lecture.
Le verrouillage au niveau de la ligne verrouille la ligne entière, ce qui peut prendre en charge le traitement simultané dans la plus grande mesure, mais la surcharge de déverrouillage sera également relativement élevée. Les verrous au niveau des lignes ne sont implémentés qu'au niveau de la couche du moteur de stockage
Tous les moteurs de stockage implémentent les verrous au niveau des lignes à leur manière.
3. MVCC
MVCC est un "contrôle de concurrence multi-versions". On peut considérer que MVCC est une variante du verrouillage au niveau des lignes, mais cela évite d'en ajouter. des serrures supplémentaires dans de nombreux cas, les opérations de serrure,
sont donc moins coûteuses.
Les bases de données relationnelles grand public implémentent toutes MVCC, mais les mécanismes d'implémentation sont différents. En fait, MVCC n'a pas de norme unifiée.
Mais la plupart d'entre eux implémentent des opérations de lecture non bloquantes et les opérations d'écriture ne verrouillent que les lignes nécessaires.
MVCC garantit que les données vues dans chaque transaction lors de l'exécution sont cohérentes.
Cependant, comme différentes transactions démarrent à des moments différents, les données vues en même temps peuvent être différentes pour la même table.
Le moteur InnoDB de Mysql est implémenté en enregistrant deux colonnes cachées derrière chaque ligne d'enregistrements.
L'un enregistre l'heure de création de la ligne, et l'autre enregistre l'heure d'expiration (ou heure de suppression) de la ligne.
En fait, ce qui est stocké n'est pas un horodatage réel, mais le « numéro de version du système ».
Chaque fois qu'une transaction est démarrée, le numéro de version du système sera incrémenté. Lorsqu'une transaction démarre, le numéro de version du système sera utilisé comme numéro de version de la transaction, qui est utilisé pour comparer avec le numéro de version de la ligne interrogée.
Ce qui suit présente le fonctionnement des numéros de version dans les opérations CRUD courantes :
INSERT
Enregistrez la version actuelle du système en tant que numéro de version de la ligne
DELETE
Enregistrez le numéro de version actuel du système dans la « version supprimée » de cette ligne de données.
MISE À JOUR
Insérez une nouvelle ligne d'enregistrements, enregistrez le numéro de version actuel du système comme numéro de version de navigation et enregistrez le numéro de version actuel du système dans la « version supprimée » de la ligne d'origine.
SELECT
Trouver uniquement les lignes dont la version est antérieure à la version actuelle de la transaction. Cela garantit que les lignes lues par la transaction existent avant,
ou ont été insérées ou modifiées par la transaction elle-même. La "version de suppression" de la ligne
est soit indéfinie, soit supérieure au numéro de version actuel de la transaction. Cela garantit que les lignes lues par la transaction,
, n'ont pas été supprimées avant la transaction.
MVCC ne fonctionne que sous les deux niveaux d'isolement REPEATABLE READ
et READ COMMITTED
, et les deux autres niveaux d'isolement ne peuvent pas fonctionner.
Parce que READ UNCOMMITTED
lit toujours les dernières données, plutôt que les lignes de données qui correspondent à la version actuelle de la transaction. Et SERIALIZABLE
verrouillera toutes les lignes lues.
Ci-dessus sont quelques questions sur le contrôle de concurrence compilées pour vous. Pour plus de questions connexes, veuillez visiter les didacticiels pertinents sur le site Web PHP chinois.
Tutoriel vidéo recommandé : https://www.php.cn/course/list/51/type/2.html
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!