6.08.2009

Internal Locking Methods

Locking performed within the MySQL server itself to manage contention for table contents by multiple sessions. This type of locking is internal because it is performed entirely by the server and involves no other programs. External locking occurs when the server and other programs lock table files to coordinate among themselves which program can access the tables at which time.

MySQL uses -
Table-level locking for - MyISAM, MEMORY, and MERGE tables, and
Row-level locking for - InnoDB tables.

Generally it is difficult to say that a given lock type is better than another. Everything depends on the application and different parts of an application may require different lock types.

If you want to use a storage engine with row-level locking, you should look at what your application does and what mix of select and update statements it uses.

For example, most Web applications perform many selects, relatively few deletes, updates based mainly on key values, and inserts into a few specific tables. The base MySQL MyISAM setup is very well tuned for this.

Table locking (in MySQL) is deadlock-free for storage engines that use table-level locking. Deadlock avoidance is managed by always requesting all needed locks at once at the beginning of a query and always locking the tables in the same order.

MySQL grants table write locks as follows:
1. If there are no locks on the table, put a write lock on it.
2. Otherwise, put the lock request in the write lock queue.

MySQL grants table read locks as follows:
1. If there are no write locks on the table, put a read lock on it.
2. Otherwise, put the lock request in the read lock queue.

Table updates are given higher priority than table retrievals. Therefore, when a lock is released, the lock is made available to the requests in the write lock queue and then to the requests in the read lock queue. This ensures that updates to a table are not “starved” even if there is heavy SELECT activity for the table. However, if you have many updates for a table, SELECT statements wait until there are no more updates.

The MyISAM storage engine supports concurrent inserts to reduce contention between readers and writers for a given table: If a MyISAM table has no free blocks in the middle of the data file, rows are always inserted at the end of the data file. In this case, you can freely mix concurrent INSERT and SELECT statements for a MyISAM table without locks. That is, you can insert rows into a MyISAM table at the same time other clients are reading from it. Holes can result from rows having been deleted from or updated in the middle of the table. If there are holes, concurrent inserts are disabled but are enabled again automatically when all holes have been filled with new data.. This behavior is altered by the concurrent_insert system variable.

Advantages of row-level locking:
  • Fewer lock conflicts when different sessions access different rows
  • Fewer changes for rollbacks
  • Possible to lock a single row for a long time
Disadvantages of row-level locking:
  • Requires more memory than table-level locks
  • Slower than table-level locks when used on a large part of the table because you must acquire many more locks
  • Slower than other locks if you often do GROUP BY operations on a large part of the data or if you must scan the entire table frequently
Generally, table locks are superior to row-level locks in the following cases:
  • Most statements for the table are reads
  • Statements for the table are a mix of reads and writes
  • SELECT combined with concurrent INSERT statements, and very few UPDATE or DELETE statements
  • Many scans or GROUP BY operations on the entire table without any writers
With higher-level locks, you can more easily tune applications by supporting locks of different types, because the lock overhead is less than for row-level locks.