mariadb-lock-tables

Use LOCK TABLES tbl_name [AS alias] lock_type with READ, READ LOCAL, WRITE, LOW_PRIORITY WRITE, or WRITE CONCURRENT, optionally adding WAIT n or NOWAIT. You must lock every table and alias your session will reference, and UNLOCK TABLES releases all held locks.

GET_LOCK(str, timeout) acquires a server-wide named advisory lock, returning 1 on success, 0 on timeout, and NULL on error. Since MariaDB 10.0.2 a connection can hold multiple named locks simultaneously, and locks release only via RELEASE_LOCK, RELEASE_ALL_LOCKS, or connection close.

ERROR 1100 occurs when a statement references a table or alias not included in the LOCK TABLES clause. If you query t1 AS a, you must lock t1 AS a explicitly; locking the bare table name does not cover aliased references.

No. LOCK TABLES implicitly commits any active transaction before acquiring locks, and starting a new transaction releases all table locks. For transactional workflows, use SELECT ... FOR UPDATE row locking or GET_LOCK instead.

No, named locks are independent of transactions. COMMIT and ROLLBACK never release them; locks are released only by RELEASE_LOCK, RELEASE_ALL_LOCKS, or the connection ending normally or abnormally.

Avoid LOCK TABLES in stored procedures (it errors at creation), on Galera cluster nodes, and for serializing rows inside transactional workflows. It is also unsafe for statement-based replication; prefer row locking or GET_LOCK in those cases.