LOCK TABLES et UNLOCK TABLES

Syntax

LOCK TABLE[S]
    tbl_name [[AS] alias] lock_type
    [, tbl_name [[AS] alias] lock_type] ...
    [WAIT n|NOWAIT]

lock_type:
    READ [LOCAL]
  | [LOW_PRIORITY] WRITE
  | WRITE CONCURRENT

UNLOCK TABLES

Description

Le lock_type peut être l'un des:

MariaDB permet aux sessions client d'acquérir des verrous de table explicitement dans le but de coopérer avec d'autres sessions pour accéder aux tables, ou empêcher d'autres sessions de modifier des tables pendant les périodes où une session nécessite un accès exclusif. Une session peut acquérir ou libérer les verrous uniquement pour lui-même. Une session ne peut pas acquérir de verrous pour une autre session ou des verrous de publication détenus par une autre session.

Les verrous peuvent être utilisés pour émuler des transactions ou pour accélérer la vitesse de mise à jour des tables.

LOCK TABLES acquiert explicitement des verrous de table pour la session client en cours. Les verrous de table peuvent être acquis pour les tables de base ou les vues. Pour utiliser LOCK TABLES , vous devez avoir le privilège LOCK TABLES et le privilège SELECT chaque objet à verrouiller. Voir GRANT

Pour le verrouillage de vue, LOCK TABLES ajoute toutes les tables de base utilisées dans la vue aux ensembles de tables à verrouiller et les verrouillent automatiquement. Si vous verrouillez une table explicitement avec LOCK TABLES, toutes les tables utilisées dans les déclencheurs sont également verrouillées implicitement, comme décrit dans Triggers and Implicit Locks.

UNLOCK TABLES libère explicitement les verrous de table détenus par le session actuelle.

Une autre utilisation pour UNLOCK TABLES est de libérer le verrou de lecture globale acquise avec la déclaration FLUSH TABLES WITH READ LOCK, qui vous permet de verrouiller toutes les tables dans toutes les bases de données. Voir FLUSH. (C'est un moyen très pratique d'obtenir des sauvegardes si vous avez un système tel que Veritas pour prendre des Snapshots à temps..)

Limitations

LOCK TABLES ne fonctionne pas lorsque vous utilisez Galera cluster. Vous pouvez rencontrer des blocages ou des verrous lorsque vous utilisez Galera.

LOCK TABLES fonctionne uniquement sur les tables XtraDB / InnoDB si la variable système innodb_table_locks est définie sur 1 et autocommit est défini sur 0 (le défaut dans les deux cas). Veuillez noter qu'aucun message d'erreur ne sera retourné sur LOCK TABLES avec innodb_table_locks = 0.

LOCK TABLES implicitly commits la transaction active, le cas échéant. En outre, le lancement d'une transaction libère toujours tous les verrous de table acquis avec LOCK TABLES. Cela signifie qu'il n'y a aucun moyen d'avoir des verrous de table et une transaction active en même temps. Les seules exceptions sont les transactions dans le mode autocommit. Pour préserver l'intégrité des données entre les tables transactionnelles et non-transactionnelles, la fonction GET_LOCK () peut être utilisée.

Lorsqu'une connexion contient un verrou de lecture explicite sur une table, elle ne peut pas le modifier. Si vous essayez, l'erreur suivante sera produite:

ERROR 1099 (HY000): Table 'tab_name' was locked with a READ lock and can't be updated

Lorsqu'une connexion contient un verrou explicite sur une table, elle ne peut pas accéder à une table non verrouillée. Si vous essayez, l'erreur suivante sera produite:

ERROR 1100 (HY000): Table 'tab_name' was not locked with LOCK TABLES

Lorsqu'une connexion contient un verrou explicite sur une table, elle ne peut pas émettre ce qui suit: INSERT DELAYED, CREATE TABLE, CREATE TABLE ... LIKE, and DDL des instructions impliquant des programmes et des vues stockés (à l'exception des déclencheurs). Si vous essayez, l'erreur suivante sera produite:

ERROR 1192 (HY000): Can't execute the given command because you have active locked tables or an active transaction

LOCK TABLES ne peut pas être utilisé dans les routines stockées - si vous essayez, l'erreur suivante sera produite lors de la création:

ERROR 1314 (0A000): LOCK is not allowed in stored procedures