Discussion :

[J1]

Bonjour,

Je constate au niveau du serveur MySQL de l'application métier de mon entreprise que parfois, certaines requêtes assez lourdes bloquent l'exécution des autres requêtes. J'en avais donc conclu que MySQL exécutait peut-être les requêtes les unes après les autres selon le principe de la file d'attente.
En faisant des tests pour le vérifier, je me rends compte que ce n'est pas le cas : si je lance une requête A particulièrement lourde depuis une connexion A et que je lance ensuite une requête B moins lourde (mais portant sur les mêmes tables) depuis une connexion B, la requête B revient en premier. Preuve qu'elle n'a a priori pas été bloquée par la requête A.

Du coup, je me pose la question suivante : en considérant qu'aucune instruction LOCK TABLES n'est explicitement exécutée, qu'est-ce qui peut expliquer que parfois, une requête exécutée depuis une connexion donnée bloque l'exécution de requêtes lancées depuis une autre connexion ?

PS : je n'ai malheureusement pas le SQL des requêtes en question (celles qui ont tendance à bloquer les autres)

Merci d'avance pour vos lumières.

[escartefigue]

Bonjour,

La quasi-totalité des SGBD-R est multi-utilisateurs. Du coup, il y a une gestion du partage des données en lecture et en mise à jour via deux biais :

- La taille des verrous
- Le niveau d'isolation

La taille des verrous permet de choisir si vous ne bloquez qu'une seule ligne en vue de mise à jour, ou bien une page (1 ou plusieurs lignes selon la taille de la page, option non disponible sous MySQL) ou encore toute la table, ou bien le tablespace (non disponible sous MySQL).
Le niveau d'isolation permet de choisir le niveau de partage des données avec d'autres utilisateurs, du niveau le plus permissif qui autorise tous les accès concurrents, aux niveaux les plus restrictifs.
Là encore, MySQL ne propose pas beaucoup de choix dans les niveaux d'isolation

Les verrous sont libérés par l'ordre COMMIT ou ROLLBACK, ou implicitement à la fin de la transaction.
Si une ligne est demandée, même en lecture seule par une transaction T1, alors qu'une autre transaction T2 a déjà posé un verrou exclusif non commité, alors la première transaction attend la libération du verrou par T2. Si le délai d'attente dépasse celui paramétré pour le SGBD, alors il y a un plantage en "dead lock"

[J1]

Merci pour ces éléments de réponse, escartefigue.

Précision importante : l'application métier concernée tourne sur des tables MyISAM, qui ne gèrent donc ni les transactions, ni les verrous de ligne.
Du coup, dans mon cas, la seule possibilité pour qu'une requête SELECT soit bloquée est bien qu'un verrou de table du type LOCK TABLES MaTable WRITE ait été posé par une autre connexion ?