In MySQL and MariaDB, the keyword READ appears only as part of the LOCK TABLES statement. When you lock a table with READ, the current session obtains a shared read lock. Other sessions can still read the table but cannot insert, update, delete, or otherwise modify rows until the lock is released with UNLOCK TABLES or the connection terminates. READ locks guarantee a consistent view of the data for the locking session, which is useful for backups, bulk exports, or long analytical queries.READ locks are session-level and block all write operations (INSERT, UPDATE, DELETE, REPLACE, ALTER, TRUNCATE, LOAD DATA, etc.) by other sessions. They also block DDL that would change table structure. The locking session itself cannot perform writes while holding a READ lock; attempting to do so raises an error. If you need to allow the locking session to write, use the WRITE lock instead.The lock remains active until UNLOCK TABLES is issued explicitly or the session ends. Because READ locks can cause write starvation under heavy traffic, use them sparingly and keep lock durations short.READ is not a standalone SQL statement and does not exist in PostgreSQL, SQL Server, Oracle, or SQLite. Those databases provide different mechanisms such as transaction isolation levels, advisory locks, or explicit lock modes.
LOCK TABLES, READ LOCAL, WRITE lock, UNLOCK TABLES, SET TRANSACTION READ ONLY, transaction isolation levels
MySQL 3.23
The lock stays in place for the lifetime of the session, blocking writes from other sessions. Always run UNLOCK TABLES as soon as your read-only task is complete.
No. READ LOCAL allows other sessions to perform non-conflicting INSERT operations (for MyISAM) while READ blocks all writes. Use READ LOCAL when slight write flexibility is acceptable.
LOCK TABLES implicitly commits any active transaction in MySQL. Use START TRANSACTION READ ONLY if you need transactional consistency without explicit table locks.
Yes, but the underlying base tables are locked, not the view definition itself.