Syntax:
    tbl_name [[AS] alias] lock_type
    [, tbl_name [[AS] alias] lock_type] ...

lock_type:
    READ [LOCAL]
  | [LOW_PRIORITY] WRITE


MySQL enables client sessions to acquire table locks explicitly for the
purpose of cooperating with other sessions for access to tables, or to
prevent other sessions from modifying tables during periods when a
session requires exclusive access to them. A session can acquire or
release locks only for itself. One session cannot acquire locks for
another session or release locks held by another session.

tables or views. (For view locking, LOCK TABLES adds all base tables
used in the view to the set of tables to be locked and locks them
automatically.) To use LOCK TABLES, you must have the LOCK TABLES
privilege, and the SELECT privilege for each object to be locked.

MySQL enables client sessions to acquire table locks explicitly Locks
may be used to emulate transactions or to get more speed when updating
tables. This is explained in more detail later in this section.

thread. Another use for UNLOCK TABLES is to release the global read
lock acquired with FLUSH TABLES WITH READ LOCK. (You can lock all
tables in all databases with a read lock with the FLUSH TABLES WITH
READ LOCK statement. See [HELP FLUSH]. This is a very convenient way to
get backups if you have a file system such as Veritas that can take
snapshots in time.)

The following discussion applies only to non-TEMPORARY tables. LOCK
TABLES is allowed (but ignored) for a TEMPORARY table. The table can be
accessed freely by the session within which it was created, regardless
of what other locking may be in effect. No lock is necessary because no
other session can see the table.

The following general rules apply to acquisition and release of locks
by a given thread:

o Table locks are acquired with LOCK TABLES.

o If the LOCK TABLES statement must wait due to locks held by other
  threads on any of the tables, it blocks until all locks can be
  acquired.

o Table locks are released explicitly with UNLOCK TABLES.

o Table locks are released implicitly under these conditions:

  o LOCK TABLES releases any table locks currently held by the thread
    before acquiring new locks.

  o Beginning a transaction (for example, with START TRANSACTION)
    implicitly performs an UNLOCK TABLES. (Additional information about
    the interaction between table locking and transactions is given
    later in this section.)

  o If a client connection drops, the server releases table locks held
    by the client. If the client reconnects, the locks will no longer
    be in effect. In addition, if the client had an active transaction,
    the server rolls back the transaction upon disconnect, and if
    reconnect occurs, the new session begins with autocommit enabled.
    For this reason, clients may wish to disable auto-reconnect. With
    auto-reconnect in effect, the client is not notified if reconnect
    occurs but any table locks or current transaction will have been
    lost. With auto-reconnect disabled, if the connection drops, an
    error occurs for the next statement issued. The client can detect
    the error and take appropriate action such as reacquiring the locks
    or redoing the transaction. See
    http://dev.mysql.com/doc/refman/5.1/en/auto-reconnect.html.

*Note*: If you use ALTER TABLE on a locked table, it may become
unlocked. See
http://dev.mysql.com/doc/refman/5.1/en/alter-table-problems.html.

A table lock protects only against inappropriate reads or writes by
other clients. The client holding the lock, even a read lock, can
perform table-level operations such as DROP TABLE. Truncate operations
are not transaction-safe, so an error occurs if the client attempts one
during an active transaction or while holding a table lock.

URL: http://dev.mysql.com/doc/refman/5.1/en/lock-tables.html

