MySQL row-level locks, table-level locks, and page-level locks _ MySQL

MySQL row-level lock, table-level lock, page-level lock details page-level: engine BDB.
Table-level: engine MyISAM, which is interpreted as locking the entire table and reading at the same time.
Row-level: engine INNODB, locking a single row of records

Mysql lock shared

At the table level, the entire table is locked directly. during the lock period, other processes cannot perform write operations on the table. If you are writing a lock, other processes are not allowed to read it.
Row-level, which only locks specified records, so that other processes can still operate on other records in the same table.

Mysql lock
Page-level, table-level locks are fast, but there are many conflicts, less row-level conflicts, but the speed is slow. Therefore, the compromised page level is used to lock a group of adjacent records at a time.

MySQL 5.1 supports table-level locking for MyISAM and MEMORY tables, page-level locking for BDB tables, and RoW-level locking for InnoDB tables.
The table locking method for WRITE and MySQL is as follows: database locks mysql
If there is no lock in the table, put a write lock on it.
Otherwise, put the lock request in the write lock queue.

Mysql update lock

The locking method for READ and MySQL is as follows:
If there is no write lock on the table, place a read lock on it.
Otherwise, put the lock request in the read lock queue.

Mysql show locks 

InnoDB uses row locking and BDB uses page locking. Both storage engines may have deadlocks. This is because, during SQL Statement Processing, InnoDB automatically acquires row locks and BDB obtains page locks, rather than at transaction startup.

Advantages of row-level locking: mysql select lock
Only a small number of lock conflicts exist when different rows are accessed in many threads.
Only a few changes are allowed during rollback.
A single row can be locked for a long time.

Disadvantages of row-level locking:
More memory is occupied than page-level or table-level locking.
When used in most tables, it is slower than page-level or table-level locking because you must obtain more locks.
If you often perform group by operations on most data or scan the entire table frequently, it is much slower than other locks.
With high-level locking, you can easily adjust the application by supporting different types of locking because the lock cost is less than the row-level locking.

In the following cases, table locking takes precedence over page-level or row-level locking:
Most of the table statements are used for reading.
Read and update strict keywords. you can update or delete a row that can be extracted with a single read keyword:
UPDATE tbl_name SET column = value WHERE unique_key_col = key_value;
Delete from tbl_name WHERE unique_key_col = key_value;
SELECT combines parallel INSERT statements with few UPDATE or DELETE statements.
There are many scan or group by operations on the entire table without any write operations.

/* ==================================== Mysql lock table type and unlock statement ======== ================================= */

If you want to perform a large number of INSERT and SELECT operations on a table, but parallel INSERT is not possible, you can INSERT records into the temporary table, then, the data in the temporary table is updated to the actual table on a regular basis. You can use the following command:

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;

Row-level locks have the following advantages:
Reduce the conflict lock when multiple threads request different records.
Reduce Data changes during transaction rollback.
It is possible to lock a single row of records for a long time.

Row-level locks have the following disadvantages:
It consumes more memory than page-level locks and table-level locks.
A lock is a mechanism by a computer to coordinate multiple processes or threads to concurrently access a certain resource. the lock mechanisms of different databases are similar. Because database resources are resources shared by many users, how to ensure consistency and effectiveness of concurrent data access is a problem that all databases must solve, lock conflicts are also an important factor affecting the concurrent database access performance. The unlocking mechanism not only enables us to develop and utilize database resources more effectively, but also enables us to better maintain the database and thus improve the database performance.

The locking mechanism of MySQL is relatively simple. its most notable feature is that different storage engines support different locking mechanisms.

For example, the MyISAM and MEMORY storage engines use table-level-locking; the BDB storage engine uses page-level-locking ), table-level locks are also supported. The InnoDB storage engine supports both row-level locks and table-level locks. row-level locks are used by default.

The features of the above three locks can be roughly summarized as follows:
1) table-level locks: low overhead and fast locking; no deadlocks; large lock granularity, the highest probability of lock conflicts and the lowest concurrency.
2) row-level locks: high overhead and slow locking; deadlocks may occur; minimum lock granularity, minimum probability of lock conflicts, and highest concurrency.
3) page lock: the overhead and lock time are between table locks and row locks. deadlocks may occur. the lock granularity is between table locks and row locks, and the concurrency is average.

Each of the three locks has its own characteristics. from the perspective of the lock, table-level locks are more suitable for queries-oriented applications with only a small amount of data updated based on index conditions, such as WEB applications; row-level locks are more suitable for applications with a large number of concurrent updates of a small amount of different data based on index conditions and concurrent queries, such as some online transaction processing (OLTP) systems.

MySQL Table-level locks can be used in two modes: Table Read Lock and Table Write Lock ). What does this mean? when reading a MyISAM table, it does not block read requests from other users to the same table, but blocks write operations on the same table; write operations on the MyISAM table will block read and write operations on the same table by other users.

The read and write operations of MyISAM tables are sequential, that is, they cannot be performed during read operations, and the opposite is true. However, under certain conditions, MyISAM tables also support concurrent query and insertion operations. the mechanism is to control a system variable (concurrent_insert, when the value is set to 0, concurrent insertion is not allowed. when the value is set to 1, if the MyISAM table has no holes (that is, the table has no rows deleted ), myISAM allows another process to insert records from the end of the table while reading the table; when the value is set to 2, no matter whether the MyISAM table has holes, records can be inserted concurrently at the end of the table.

How is MyISAM lock scheduling implemented? this is also a key issue. For example, if a process requests the read lock of a MyISAM table and another process also requests the write lock of the same table, what will MySQL process preferentially? Studies show that the write process will first obtain the lock (even if the read request first goes to the lock wait queue ). However, this also causes a major defect, that is, a large number of write operations will make query operations difficult to obtain read locks, which may cause permanent blocking. Fortunately, we can adjust the scheduling behavior of MyISAM through some settings. You can specify the low-priority-updates parameter so that the MyISAM default engine gives the read request priority and sets its value to 1 (set low_priority_updates = 1) to lower the priority.

The biggest difference between InnoDB locks and MyISAM locks is that they support transactions and use row-level locks. We know that a transaction is a logical processing unit composed of a group of SQL statements. It has four attributes (ACID attributes:

Atomicity: a transaction is an atomic operation unit. modifications to the data are either performed in full or not all;
Consistent: data must be Consistent at the beginning and end of the transaction;
Isolation: the database system provides a certain Isolation mechanism to ensure that transactions are executed in an "independent" environment not affected by external concurrent operations;
Durable: after a transaction is completed, it modifies the data permanently, even if a system failure occurs.

InnoDB has two modes of row Lock:

1) shared Lock: allows a transaction to read a row to prevent other transactions from obtaining exclusive locks for the same dataset.
(Select * from table_name where... lock in share mode)

2) exclusive lock: allow the transaction that obtains the exclusive lock to update data and prevent other transactions from obtaining the shared read lock and exclusive write lock for the same dataset. (Select * from table_name where... for update)
In order to allow row locks and table locks to coexist and implement multi-granularity locks, there are also two types of internal intention locks (both table locks), which are intention shared locks and intention exclusive locks respectively.
InnoDB row locks are implemented by locking the index items. that is, InnoDB uses row-level locks only when data is retrieved through Index conditions. otherwise, table locks are used!

In addition, insert and update several important parameters for performance optimization.

Bulk_insert_buffer_size
Batch insert cache size. this parameter is for the MyISAM storage engine. this method improves the efficiency when more than 100-1000 records are inserted at a time. the default value is 8 MB. double the data size.

Concurrent_insert
Concurrent insert. when the table has no holes (records deleted), other processes can insert the read locks at the end of the table when a process obtains the read locks.

The value can be set to 0 and cannot be inserted concurrently. 1. when the table has no holes, concurrent insertion is performed. 2. concurrent insertion is performed regardless of whether there are holes.
The default value is 1. the deletion frequency is set for the table.

Delay_key_write
For the MyISAM storage engine, index update is delayed. this means that when the update record is updated, the data is first up to the disk, but the index is not up, and the index is stored in the memory. when the table is closed, the memory index is written to the disk. if the value is 0, it is disabled. if the value is 1, it is enabled. enabled by default.

Delayed_insert_limit, delayed_insert_timeout, delayed_queue_size
Delayed insertion: The data is first handed over to the memory queue and then inserted slowly. however, not all storage engines support these configurations. Currently, common InnoDB does not support these configurations, and MyISAM does. increase the value according to the actual situation. generally, it is enough by default.

/* ================================ MySQL InnoDB lock table and lock row ================ ================= */

Because InnoDB defaults to Row-Level Lock, MySQL will only execute Row lock (only Lock the selected data example) if a specified primary key is specified explicitly ), otherwise, MySQL will execute Table Lock (Lock the entire data form ).

For example, assume that there is a form products, which contains two columns: id and name. id is the primary key.

Example 1: (specify the primary key and use this document, row lock)
SELECT * FROM products WHERE id = '3' for update;
SELECT * FROM products WHERE id = '3' and type = 1 for update;

Example 2: (specify a primary key. if no data is found, no lock is required)
SELECT * FROM products WHERE id = '-1' for update;

Example 3: (no primary key, table lock)
SELECT * FROM products WHERE name = 'mouse 'for update;

Example 4: (the primary key is not clear, table lock)
SELECT * FROM products WHERE id <> '3' for update;

Example 5: (the primary key is not clear, table lock)
SELECT * FROM products WHERE id LIKE '3' for update;

Note 1: for update only applies to InnoDB and must be in the transaction block (BEGIN/COMMIT.
Note 2: to test the locking status, you can use the Command Mode of MySQL to open two windows for testing.

In MySql 5.0, the test is true.

In addition, MyAsim only supports table-level locks and InnerDB supports row-level locks.
Data that has been added (row-level lock/table-level lock) locks cannot be locked by other transactions or be modified (modified or deleted) by other transactions)
The table is locked no matter whether or not records are queried.
In addition, if both A and B query the table id but cannot query the records, A and B do not apply the row lock in the query, but both A and B obtain the exclusive lock, at this time, if A inserts another record, it will be in the waiting state because B has A lock. if B inserts another record with the same data, it will throw the Deadlock found when trying to get lock; try restarting transaction and release the lock. at this time, A Gets the lock and inserts it successfully.