Spec-Zone .ru
спецификации, руководства, описания, API
|
|
Spec-Zone .ru
спецификации, руководства, описания, API
|
InnoDB tables use row-level locking so that multiple sessions and applications can
read from and write to the same table simultaneously, without making each other wait or producing inconsistent
results. For this storage engine, avoid using the LOCK TABLES statement, because it does not offer any extra protection, but
instead reduces concurrency. The automatic row-level locking makes these tables suitable for your busiest
databases with your most important data, while also simplifying application logic since you do not need to lock
and unlock tables. Consequently, the InnoDB storage engine is the default in MySQL
5.6.
MySQL uses table locking (instead of page, row, or column locking) for all storage engines except InnoDB. The locking operations themselves do not have much overhead. But because only
one session can write to a table at any one time, for best performance with these other storage engines, use
them primarily for tables that are queried often and rarely inserted into or updated.
InnoDB When choosing whether to create a table using InnoDB or a different storage engine,
keep in mind the following disadvantages of table locking:
Table locking enables many sessions to read from a table at the same time, but if a session wants to write to a table, it must first get exclusive access, meaning it might have to wait for other sessions to finish with the table first. During the update, all other sessions that want to access this particular table must wait until the update is done.
Table locking causes problems when a session is waiting because the disk is full and free space needs to become available before the session can proceed. In this case, all sessions that want to access the problem table are also put in a waiting state until more disk space is made available.
A SELECT statement that takes a long time to run prevents other sessions
from updating the table in the meantime, making the other sessions appear slow or unresponsive. While a
session is waiting to get exclusive access to the table for updates, other sessions that issue SELECT
statements will queue up behind it, reducing concurrency even for read-only sessions.
The following items describe some ways to avoid or reduce contention caused by table locking:
Consider switching the table to the InnoDB storage
engine, either using CREATE TABLE ... ENGINE=INNODB during setup, or using
ALTER TABLE ... ENGINE=INNODB for an existing table. See Section
14.2, "The InnoDB Storage Engine" for more details about this
storage engine.
Optimize SELECT
statements to run faster so that they lock tables for a shorter time. You might have to create some
summary tables to do this.
Start mysqld
with --low-priority-updates. For storage engines that use only table-level
locking (such as MyISAM, MEMORY, and MERGE), this gives all statements that update (modify) a table lower
priority than SELECT statements. In this case, the second SELECT statement in the preceding scenario would execute before the
UPDATE
statement, and would not wait for the first SELECT
to finish.
To specify that all updates issued in a specific connection should be done with low
priority, set the low_priority_updates server system variable equal to 1.
To give a specific INSERT, UPDATE, or DELETE statement lower priority, use the LOW_PRIORITY
attribute.
To give a specific SELECT statement higher priority, use the HIGH_PRIORITY
attribute. See Section
13.2.9, "SELECT Syntax".
Start mysqld
with a low value for the max_write_lock_count system variable to force MySQL to temporarily
elevate the priority of all SELECT statements that are waiting for a table after a specific
number of inserts to the table occur. This permits READ locks after a
certain number of WRITE locks.
If you have problems with INSERT
combined with SELECT, consider switching to MyISAM
tables, which support concurrent SELECT and INSERT
statements. (See Section 8.10.3, "Concurrent Inserts".)
If you mix inserts and deletes on the same nontransactional table, INSERT DELAYED may help. See Section
13.2.5.2, "INSERT DELAYED Syntax".
As of MySQL 5.6.6, INSERT
DELAYED is deprecated, and will be removed in a future release. Use INSERT (without DELAYED) instead.
If you have problems with mixed SELECT and DELETE statements, the LIMIT option to DELETE
may help. See Section
13.2.2, "DELETE Syntax".
Using SQL_BUFFER_RESULT with SELECT statements can help to make the duration of table locks shorter.
See Section 13.2.9, "SELECT Syntax".
Splitting table contents into separate tables may help, by allowing queries to run against columns in one table, while updates are confined to columns in a different table.
You could change the locking code in mysys/thr_lock.c
to use a single queue. In this case, write locks and read locks would have the same priority, which
might help some applications.