1.1 Overview of locks:
The MySQL lock mechanism is relatively simple. Different storage engines support different lock mechanisms: MyISAM and MEMORY storage engines support table-level locks; DBD supports page locks, but it also supports table-level locks; InnoDB supports both row-level locks and table-level locks. locks, but supports row-level locks by default;
Table-level locks: low overhead
1.2MyISAM table lock:
1.2.1 Query table lock contention:
mysql> SHOW STATUS LIKE 'table%';
+----------------------------+-------+ | Variable_name | Value | +------ -----------------------+-------+ | Table_locks_immediate | 7 | | Table_locks_waited | 0 | | Table_open_cache_hits | 0 | | Table_open_cache_misses | 0 | | Table_open_cache_overflows | 0 | +----------------------------+-------+ The value of Table_locks_waited is relatively high, This shows that there is serious table-level lock competition;
1.2.2 MYSQL table-level lock lock mode:
Table shared read lock (Table Read Lock)
Table Write Lock
Read operations on the MySAM table will not block other users' read requests for the same table, but will block write requests on the same table; write operations on the MyISAM table will block other users' read and write operations on the same table;
MyISAM table locks are serial between read operations and write operations, and between write operations. When a thread obtains a write lock on a table, only the thread holding the lock can update the table. Read operations from other threads will wait until the lock is released.
1.2.3 How to add table lock:
MyISAM will automatically add read locks to all tables involved before executing the query statement (SELECT). Before executing update operations (UPDATE, DELETE, INSERT, etc.), it will automatically add write locks to the tables involved. This process does not require User intervention, therefore, users generally do not need to directly use the LOCK TABLE command to explicitly lock the MyISAM table.
Explicit locking of MyISAM tables is generally done to simulate transaction operations to a certain extent and achieve consistent reading of multiple tables at a certain point in time.
What is display locking: it refers to writing out the locking command of Lock table table_name read;
Code example:
1. When I use the command line to connect to the database, I simulate the session1 user and use Navicat to connect as the session2 user;
Session1 performs write locking and session2 performs read operations. You can see the first screenshot. The session is obviously blocked there.
When session1 releases the lock immediately, session2 immediately gets the result of the read operation;
You can try out the read-write blocking relationship between locks in an environment, but I won’t demonstrate too much here.
1.2.4 Concurrent Insert: (Councurrent Insert):
MyISAM tables are read and written serially, but that's in general. Under certain conditions, MyISAM tables also support concurrent query and insert operations. The MyISAM storage engine has a system variable concurrent insert, which is specifically used to control its concurrent insert behavior. Its value can be 0, 1 or 2 respectively.
When concurrent insert is set to 0, concurrent inserts are not allowed
When concurrent insert is set to 1, if there are no holes in the MyISAM table (that is, there are no deleted rows in the middle of the table), MyISAM allows one process to read the table while another process inserts records from the end of the table. This is also the default setting for MySOI (or Auto). When concurrent insert is set to 2, records are allowed to be inserted concurrently at the end of the table regardless of whether there are holes in the MyISAM table.
You can use the concurrent insert feature of the MyISAM storage engine to solve the lock contention for the same table query and insert in the application. For example, setting the concurrent_insert system variable to 2 always allows concurrent inserts; at the same time, by executing it regularly when the system is idle OPTIMIZE TABLE statement to defragment the space and recover the intermediate holes caused by deleting records.
1.2.5 Lock scheduling:
The read lock and write lock of the MyISAM storage engine are mutually exclusive, and read and write operations are serial. So a process requests a read lock on a MyISAM table, and at the same time another process also requests a write lock on the same table. How does MySQL handle this? The answer is that the writing process acquires the lock first. Not only that, even if the read request arrives in the lock waiting queue first and the write request arrives later, the write lock will be inserted before the read lock request! This is because MySQL believes that write requests are generally more important than read requests. This is why MyISAM tables are not suitable for applications with a large number of update operations and query operations, because a large number of update operations will make it difficult for query operations to obtain read locks, which may block forever. However, we can adjust the scheduling behavior of MyISAM through some settings.
● By specifying the startup parameter low-priority-updates, the MyISAM engine gives priority to read requests by default. ● Execute the command SETLOW PRIORITY UPDATES=1 to lower the priority of update requests issued by this connection. ● Lower the priority of an INSERT, UPDATE, or DELETE statement by specifying the LOW_PRIORITY attribute of the statement. Although the above three methods are either update-first or query-first methods, they can still be used to solve the serious problem of read lock waiting in applications where querying is relatively important (such as user login systems).
In addition, MvSOL also provides a compromise method to adjust read and write conflicts, that is, setting an appropriate value for the system parameter max_write_lock_count. When the read lock of a table reaches this value, MySQL will temporarily reduce the priority of the write request. , giving the reading process a certain chance to obtain the lock.
It should also be emphasized here: some long-running query operations will also "starve" the writing process! Therefore, long-running query operations should be avoided in applications, and do not always want to use a SELECT statement to solve the problem. , because this seemingly clever SQL statement is often complex and takes a long time to execute. If possible, the SQL statement can be "decomposed" by using intermediate tables and other measures, so that each step of the query can be processed in a relatively short time. Complete in a short time, thereby reducing lock conflicts. If complex queries are unavoidable, they should be scheduled to be executed during idle periods of the database. For example, some regular statistics can be scheduled to be executed at night.