MySQL :: MySQL 5.0 Reference Manual :: 7.3.

1 Métodos de bloqueo Page 1 of 4

Skip navigation links

The world's most popular open source database

Se
Search

Login | Register

• Developer Zone
• Downloads
• Documentation

• MySQL Manual
• MySQL Workbench
• Expert Guides
• Topic Guides
• MySQL Cluster
• Other Docs
• MySQL Uni
• About
• Archives

• Documentation Library
◦ Table of Contents
◾ MySQL 5.0 Manual

Search manual:
Go
MySQL 5.0 Reference Manual :: 7 Optimización de MySQL :: 7.3 Temas relacionados con el
bloqueo :: 7.3.1 Métodos de bloqueo
« 7.3 Temas relacionados con el bloqueo
7.3.2 Cuestiones relacionadas con el
7.3.1. Métodos de bloqueo bloqueo (locking) de tablas »
Section Navigation [Toggle]
MySQL 5.0 supports table-level locking for MyISAM and
MEMORY tables, page-level locking for BDB tables, and row- • 7.3 Temas relacionados con
level locking for InnoDB tables. el bloqueo
In many cases, you can make an educated guess about • 7.3.1 Métodos de bloqueo
which locking type is best for an application, but generally it • 7.3.2 Cuestiones relacionadas
is difficult to say that a given lock type is better than another. con el bloqueo (locking) de
Everything depends on the application and different parts of tablas
an application may require different lock types.

To decide whether 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 many selects, relatively few deletes, updates

http://ftp.tcrc.edu.tw/MySQL/doc/refman/5.0/es/internal-locking.html 22/11/2017
MySQL :: MySQL 5.0 Reference Manual :: 7.3.1 Métodos de bloqueo Page 2 of 4

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.

The table-locking method MySQL uses for WRITE locks works as follows:

• If there are no locks on the table, put a write lock on it.

• Otherwise, put the lock request in the write lock queue.

The table-locking method MySQL uses for READ locks works as follows:

• If there are no write locks on the table, put a read lock on it.

• Otherwise, put the lock request in the read lock queue.

When a lock is released, the lock is made available to the threads in the write lock queue, then to the
threads in the read lock queue.

This means that if you have many updates for a table, SELECT statements wait until there are no more
updates.

You can analyze the table lock contention on your system by checking the Table_locks_waited
and Table_locks_immediate status variables:

mysql> SHOW STATUS LIKE 'Table%';

+-----------------------+---------+
| Variable_name | Value |
+-----------------------+---------+
| Table_locks_immediate | 1151552 |
| Table_locks_waited | 15324 |
+-----------------------+---------+

You can freely mix concurrent INSERT and SELECT statements for a MyISAM table without locks if the
INSERT statements are non-conflicting. That is, you can insert rows into a MyISAM table at the same
time other clients are reading from it. No conflict occurs if the data file contains no free blocks in the
middle, because in that case, records always are inserted at the end of the data file. (Holes can result
from rows having been deleted from or updated in the middle of the table.) If there are holes,
concurrent inserts are re-enabled automatically when all holes have been filled with new data.

If you want to do many INSERT and SELECT operations on a table when concurrent inserts are not
possible, you can insert rows in a temporary table and update the real table with the records from the
temporary table once in a while. This can be done with the following code:

mysql> LOCK TABLES real_table WRITE, insert_table WRITE;

mysql> INSERT INTO real_table SELECT * FROM insert_table;
mysql> TRUNCATE TABLE insert_table;
mysql> UNLOCK TABLES;

InnoDB uses row locks and BDB uses page locks. For these two storage engines, deadlocks are
possible. This is because InnoDB automatically acquires row locks and BDB acquires page locks
during the processing of SQL statements, not at the start of the transaction.

Advantages of row-level locking:

• Fewer lock conflicts when accessing different rows in many threads.

http://ftp.tcrc.edu.tw/MySQL/doc/refman/5.0/es/internal-locking.html 22/11/2017
MySQL :: MySQL 5.0 Reference Manual :: 7.3.1 Métodos de bloqueo Page 3 of 4

• Fewer changes for rollbacks.

• Makes it possible to lock a single row a long time.

Disadvantages of row-level locking:

• Takes more memory than page-level or table-level locks.

• Is slower than page-level or table-level locks when used on a large part of the table because
you must acquire many more locks.

• Is definitely much worse than other locks if you often do GROUP BY operations on a large part of
the data or if you often must scan the entire table.

• With higher-level locks, you can also more easily support locks of different types to tune the
application, because the lock overhead is less than for row-level locks.

Table locks are superior to page-level or row-level locks in the following cases:

• Most statements for the table are reads.

• Reads and updates on strict keys, where you update or delete a row that can be fetched with a
single key read:

UPDATE tbl_name SET column = value WHERE unique_key_col = key_value ;

DELETE FROM tbl_name WHERE unique_key_col = key_value ;

• 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.

Options other than row-level or page-level locking:

• Versioning (such as that used in MySQL for concurrent inserts) where it is possible to have one
writer at the same time as many readers. This means that the database or table supports
different views for the data depending on when access begins. Other common terms for this are
“time travel”, “copy on write”, or “copy on demand”.

• Copy on demand is in many cases superior to page-level or row-level locking. However, in the
worst case, it can use much more memory than using normal locks.

• Instead of using row-level locks, you can employ application-level locks, such as GET_LOCK()
and RELEASE_LOCK() in MySQL. These are advisory locks, so they work only in well-behaved
applications.

Ésta es una traducción del manual de referencia de MySQL, que puede encontrarse en
dev.mysql.com. El manual de referencia original de MySQL está escrito en inglés, y esta
traducción no necesariamente está tan actualizada como la versión original. Para cualquier
sugerencia sobre la traducción y para señalar errores de cualquier tipo, no dude en dirigirse a
[email protected].

Top / Previous / Next / Up / Table of Contents

• Developer Zone
• Documentation
• Librarian
• Developer Articles
• News & Events
• Forums

http://ftp.tcrc.edu.tw/MySQL/doc/refman/5.0/es/internal-locking.html 22/11/2017
MySQL :: MySQL 5.0 Reference Manual :: 7.3.1 Métodos de bloqueo Page 4 of 4

• Bugs
• Forge
• Planet MySQL
• Labs

• Downloads
• MySQL Community Server
• MySQL Proxy
• MySQL Cluster
• MySQL Workbench
• Connectors
• Archives
• Snapshots
• Mirrors

• Documentation
• MySQL Reference Manuals
• MySQL Workbench
• Expert Guides
• Topic Guides
• MySQL Cluster
• Other Documents
• MySQL University
• About
• Archives

• Support
• MySQL Meetups
• Guilds
• Lists
• Forums

• Other
• Privacy Policy
• Contact Us
• Site Map

Se

© 2010, Oracle Corporation and/or its affiliates

http://ftp.tcrc.edu.tw/MySQL/doc/refman/5.0/es/internal-locking.html 22/11/2017