13.3.5.3 Table-Locking Restrictions and Conditions

You should not lock any tables that you are
using with INSERT DELAYED. An
INSERT DELAYED in this case
results in an error because the insert must be handled by a
separate thread, not by the session which holds the lock.

For some operations, system tables in the
mysql database must be accessed. For example,
the HELP statement requires the
contents of the server-side help tables, and
CONVERT_TZ() might need to read
the time zone tables. The server implicitly locks the system
tables for reading as necessary so that you need not lock them
explicitly. These tables are treated as just described:

If you want to explicitly place a WRITE lock
on any of those tables with a LOCK
TABLES statement, the table must be the only one
locked; no other table can be locked with the same statement.

Normally, you do not need to lock tables, because all single
UPDATE statements are atomic; no
other session can interfere with any other currently executing
SQL statement. However, there are a few cases when locking
tables may provide an advantage:

If you are going to run many operations on a set of
MyISAM tables, it is much faster to lock
the tables you are going to use. Locking
MyISAM tables speeds up inserting,
updating, or deleting on them because MySQL does not flush
the key cache for the locked tables until
UNLOCK
TABLES is called. Normally, the key cache is
flushed after each SQL statement.

The downside to locking the tables is that no session can
update a READ-locked table (including the
one holding the lock) and no session can access a
WRITE-locked table other than the one
holding the lock.

If you are using tables for a nontransactional storage
engine, you must use LOCK
TABLES if you want to ensure that no other session
modifies the tables between a
SELECT and an
UPDATE. The example shown
here requires LOCK TABLES to
execute safely: