Une brève analyse des stratégies de planification de base de MySQL

[Introduction] MySQL permet d'affecter les caractéristiques de planification des instructions, ce qui permettra aux requêtes de plusieurs clients de mieux coopérer, afin qu'un seul client ne soit pas verrouillé trop longtemps. La modification des caractéristiques de planification peut également garantir que certaines requêtes sont traitées plus rapidement. Examinons d'abord la politique de planification par défaut de MySQL, puis examinons

MySQL vous permet d'affecter les caractéristiques de planification des instructions, ce qui permettra aux requêtes de plusieurs clients de mieux coopérer, de sorte qu'un seul client ne soit pas verrouillé depuis trop longtemps. La modification des caractéristiques de planification peut également garantir que certaines requêtes sont traitées plus rapidement. Examinons d'abord la politique de planification par défaut de MySQL, puis examinons les options disponibles pour modifier cette politique. Pour les besoins de cette discussion, supposons que le programme client effectuant la récupération (SELECT) est le programme lecteur. Un autre programme client qui effectue une opération de modification de table (DELETE, INSERT, REPLACE ou UP DATE) est le rédacteur.

La stratégie de planification de base de MySQL peut être résumée comme suit :

◆Les demandes d'écriture doivent être traitées dans l'ordre dans lequel elles arrivent.

　◆L'écriture a une priorité plus élevée que la lecture.

Mettez en œuvre une stratégie de planification à l'aide de verrous de table. Chaque fois qu'un programme client souhaite accéder à une table, il doit d'abord obtenir un verrou sur la table. Cela peut être fait directement à l'aide de LOCK TABLES, mais généralement le gestionnaire de verrous du serveur acquiert automatiquement le verrou en cas de besoin. Le verrou sur la table peut être libéré lorsque le client a fini de traiter la table. Les verrous acquis directement peuvent être libérés avec UNLOCK TABLES, mais le serveur libère également automatiquement les verrous qu'il acquiert.

Le client effectuant l'opération d'écriture doit disposer d'un verrou d'accès exclusif sur la table. Pendant que l'opération d'écriture est en cours, parce que des enregistrements de données sont supprimés, ajoutés ou modifiés sur la table, la table est dans un état incohérent et les index de la table peuvent également devoir être mis à jour en conséquence. Si la table change constamment, permettre à d’autres clients d’accéder à la table à ce moment-là peut s’avérer problématique. Il n'est évidemment pas bon d'avoir deux clients écrivant sur la même table en même temps, car cela rendrait rapidement la table indisponible. Ce n'est pas non plus une bonne chose de permettre aux clients de lire une table à langer, car des modifications peuvent être apportées à la table au moment de sa lecture et les résultats seront incorrects. Le client effectuant l'opération de lecture doit disposer d'un verrou qui empêche les autres clients d'écrire dans la table afin de garantir que la table ne change pas pendant le processus de lecture de la table. Cependant, le verrou n'a pas besoin de fournir un accès exclusif pour les opérations de lecture. Ce verrou permet également à d'autres clients de lire la table en même temps. La lecture ne modifie pas le tableau, il n’est donc pas nécessaire d’empêcher les autres clients de lire le tableau.

MySQL autorise plusieurs modificateurs de limite de requête pour influencer sa stratégie de planification. L'un d'eux est le mot-clé LOW_PRIORITY pour les instructions DELETE, INSERT, LOAD DATA, REPLACE et UP DATE. L'autre est le mot-clé HIGH_PRIORITY de l'instruction SELECT. Le troisième est le mot-clé DELAYED des instructions INSERT et REPLACE.

Le mot-clé LOW_PRIORITY affecte la planification comme suit. Normalement, si une écriture dans une table arrive pendant la lecture de la table, l'écrivain est bloqué jusqu'à ce que le lecteur termine, car une fois qu'une requête est lancée, elle ne peut pas être interrompue. Si une autre demande de lecture arrive pendant que l'enregistreur attend, le lecteur est également bloqué car la stratégie de planification par défaut donne à l'enregistreur une priorité plus élevée qu'au lecteur. A la fin du premier programme de lecture, le programme d'écriture continue, et à la fin de ce programme d'écriture, le deuxième programme de lecture commence.

Si la requête d'écriture est une requête LOW_PRIORITY, l'opération d'écriture n'est pas considérée comme ayant une priorité supérieure à l'opération de lecture. Dans ce cas, si une deuxième demande de lecture arrive pendant que l'écrivain attend, laissez la deuxième opération de lecture être mise en file d'attente avant l'opération d'écriture en attente. L'enregistreur n'est autorisé à s'exécuter que s'il n'y a pas d'autres demandes de lecture. L'implication théorique de ce changement de planification est que les écritures LOW_PRIORITY peuvent se bloquer pour toujours. Chaque fois qu'une autre demande de lecture arrive alors qu'une demande de lecture précédente est en cours de traitement, cette nouvelle demande est autorisée à être mise en file d'attente avant l'écriture LOW_PRIORITY.

Le mot-clé HIGH_PRIORITY de la requête SELECT a un effet similaire. Cela provoque l'insertion du SELECT avant une opération d'écriture en attente, même si l'opération d'écriture a une priorité normale. Le modificateur ELAYED de INSERT fonctionne comme suit Lorsqu'une requête INSERT DELAYED pour la table arrive, le serveur met les lignes correspondantes dans une file d'attente et renvoie immédiatement un statut au programme client afin que le programme client puisse continuer à s'exécuter, même si celles-ci. lignes Il n'a pas encore été inséré dans le tableau. Si un lecteur lit dans la table, les lignes de la file d'attente sont en attente. Lorsqu'il n'y a aucune lecture, le serveur commence à insérer des lignes dans la file d'attente des lignes différées. De temps en temps, le serveur s'arrête pour voir si de nouvelles demandes de lecture sont arrivées et attend. Si tel est le cas, la file d'attente des lignes différées est suspendue et le lecteur est autorisé à continuer. Lorsqu'il n'y a pas d'autres opérations de lecture, le serveur recommence à insérer des lignes retardées. Ce processus se poursuit jusqu'à ce que la file d'attente retardée soit vide.

Cela n'apparaît pas dans toutes les versions de MySQL. Le tableau suivant répertorie ces modificateurs et les versions MySQL qui les prennent en charge. Vous pouvez utiliser ce tableau pour déterminer les fonctionnalités de la version de MySQL que vous utilisez :

INSERT DELAYED est utile si d'autres clients peuvent exécuter de longues instructions SELECT et que vous ne souhaitez pas attendre la fin de l'insertion. Les clients qui émettent INSERT DELAYED peuvent poursuivre l'exécution plus rapidement car le serveur insère simplement la ligne à insérer. Cependant, vous devez être conscient de la différence entre les performances normales d'INSERT et d'INSERT DELAYED. S'il y a une erreur de syntaxe dans INSERT DELAYED, une erreur est envoyée au client. Si c'est normal, aucun message n'est envoyé. Par exemple, la valeur AUTO_INCREMENT obtenue lorsque cette instruction est renvoyée n'est pas fiable. Vous ne pouvez pas non plus compter le nombre de doublons sur un index unique. Cela se produit car l’opération d’insertion renvoie un état avant que l’insertion réelle ne soit terminée. D'autres indiquent également que si les lignes d'une instruction INSERT DELAYED sont mises en file d'attente en attente d'insertion et que le serveur plante ou est arrêté (avec kill -9), alors ces lignes seront perdues. La terminaison normale de TERM ne fait pas cela, le serveur insérera ces lignes avant de quitter.

Ce qui précède est une brève analyse de la stratégie de planification de base de MySQL. Pour plus de contenu connexe, veuillez faire attention au site Web PHP chinois (www.php.cn) !