https://blog.csdn.net/a5582ddff/article/details/79566678
MySQL table lock solution
First, my process
1, the investigation process, mainly the ID lookup table that is locked process
SHOW PROCESSLIST;
2, process kill off the lock table ID
KILL 10866; // digital instant process behind ID
Online to find some information, to understand a bit, the first to share:
Two, mysql lock table problem
SHOW PROCESSLIST view the status of the database table, whether the lock;
the kill the above mentioned id // kill the table is locked
=========================== ========================
SET the autocommit = 0;
SELECT * from T1 WHERE UID = 'XXXX' // Update for the indexed (e.g., uid) in the case where the row is locked, otherwise it is a table lock
INSERT INTO T1 values (. 1, 'XXXXX');
the commit;
========================= ============================
Lock Write Tables T1 | Read;
INSERT INTO T1 values (2, 'XXXXX'); // only INSERT
UNLOCK the Tables;
2 "MySQL database easily grasp the relevant principles of the lock mechanism."
MySQL 5.1 support for MyISAM and MEMORY tables for table-level locking for BDB tables page-level locking, InnoDB tables on row level locking. In many cases, you can use what type of lock type of training best guess based on the application, but generally very difficult to give a given lock type better than the other. Everything depends on the application, different parts of the application may require different types of locks. In order to determine whether the storage engine you want to use row-level locking, and see what the application should do and what mix of select and update statements. For example, most Web applications perform many choices, and rarely deleted, only the value of the key is updated, and only a small amount of insertion of specific table. Basic MySQL MyISAM setup is adjusting very well.
In MySQL to use table-level locking storage engine, lock the table will not deadlock when. This is managed by always start immediately when a query request all necessary locks and always lock the table in the same order.
The principle table locking method WRITE, MySQL used as follows:
◆ If there are no locks on the table, put it above a write lock.
◆ Otherwise, the lock request on the write lock queue.
The principle READ, MySQL uses locking method is as follows:
◆ If there are no write locks on the table, put a read lock on top of it.
◆ Otherwise, the lock request on the read lock queue.
When a lock is released, the lock can be written in the thread gets locked queue, then the read lock queue thread.
This means that if you have many updates on a table, SELECT statements will wait until there are no more updates.
If the INSERT statement does not conflict, can be freely mixed for the MyISAM table INSERT and SELECT statements in parallel without the need for locking.
InnoDB uses row locks, BDB uses page locks. For both storage engines, deadlocks are likely to exist. This is because, during processing the SQL statement, InnoDB row lock automatically, BDB obtain page locks, rather than get in the transaction starts.
Row-level locking advantages:
• When accessing different rows in many threads there is only a small amount of lock conflict.
· Only a small number of changes rollback.
• You can lock a single row a long time.
Row-level locking shortcomings:
· Than page-level or table-level locking up more memory.
· When used in most of the table, than the page level or table-level locking is slower, because you have to get more locks.
If you frequently GROUP BY operation on most of the data or must always scan the entire table, obviously much slower than other locks.
* High-level locking, by supporting different types of locks, you can easily adjust the application, because it locks cost less than row-level locking.
In the following cases, the table lock to lock the priority level or row-level page:
* Most of the table statement to read.
· Strict reading and updating keywords, you can update or delete a row can be used to read a single keyword to extract:
• UPDATE tbl_name the WHERE unique_key_col the SET column = value = key_value;
• DELETE the FROM tbl_name the WHERE unique_key_col = key_value;
· the SELECT combined with concurrent INSERT statements, and only a few UPDATE or DELETE statement.
· There are many scans or GROUP BY operations on the entire table, no write operation.
Option is different from the row level or page level locking:
* version (for example, to insert in MySQL using the technology in parallel), which can be a write operation, while many read operations. This next data-dependent database or table supporting different views, depending on when to start access. Other common term is "time tracking", "writing copy" or "on-demand replication."
· Demand replication, in many cases take precedence or page-level locking to row level. However, in the worst case, it may be locked to use more memory than conventional.
* In addition to row-level locking, the you can use application-level locks, such as the use of GET_LOCK () and RELEASE_LOCK () in MySQL. These are the recommendations of locking, they can only work in a well-run applications.
To achieve the highest lock speed, except InnoDB and BDB, for all storage engines, MySQL uses table locking (instead of page, row or column locking). For InnoDB and BDB tables, if you use explicit LOCK TABLES locks tables, MySQL uses only table locking; to ensure transaction isolation if you do not use LOCK TABLES, because InnoDB uses automatic row-level locking and BDB uses page-level locking.
But for large tables, for most applications, the table lock better than row locking, but there is some defect. Table lock many threads to read from a table, but if a thread wants to write on the table, it must first obtain exclusive access. During the update, all other threads that want to access the table must wait until the update is complete.
Table updates normally considered more important than the retrieval table, so give them a higher priority. This should ensure that updates a table of activities can not "starve", even if there are on the table very heavy SELECT activity.
Table locking in this case will cause problems, such as when the thread is waiting, because the hard drive is full and there must be free space before the thread can handle. In this case, all threads that want to table the issue of access is also set to appear in a waiting state until more disk space is available.
Table locking in the following cases there is a problem:
• A client sent a long running query.
* Then, another customer on the same table to be updated. The client must wait until the SELECT is finished.
· Another client issues another SELECT statement on the same table. Because UPDATE higher priority than SELECT, UPDATE statement waits for the completion of the SELECT, SELECT 1 and waits for the first to complete.
The following describes some ways to avoid or reduce competition caused by the table lock:
· Trying to SELECT statements run faster. You may have to create some summary (summary) tables do.
• Start mysqld with -low-priority-updates. This will give all update (modify) a table of the statement SELECT statement than the lower priority. In this case, in the case of the first two previous SELECT statement executed before the UPDATE statement, without the need to wait for the first SELECT to finish.
• You can use SET_UPDATES = 1 statement to specify that all updates specific connection should use a low priority.
• You can give a specific INSERT LOW_PRIORITY with property, UPDATE, or DELETE statement lower priority.
• You can give a property with HIGH_PRIORITY specific SELECT statement higher priority.
· Specify a low value to start mysqld as max_write_lock_count system variable to force MySQL to temporarily raise the priority of all wait for a table SELECT statement after a specific number of insertion is completed. This allows a given READ locks after a certain number of WRITE lock.
If you have problems with INSERT combined with SELECT, switch to use the new MyISAM tables, because they support concurrent SELECT and INSERT.
If you mix inserts and deletes on the same table, INSERT DELAYED will be of great help.
If you mix SELECT and DELETE statements on the same table problems, DELETE the LIMIT option can be helpful.
Use SQL_BUFFER_RESULT SELECT statement so that the table can help lock time is short.
• You can change the lock code is mysys / thr_lock.c is to use a single queue. In this case, write locks and read locks would have the same priority, would be helpful for some applications.
Here are some tips related to MySQL table lock:
· If you do not need to check and update the selected mixing a plurality of rows in the same table, may be performed in parallel.
• You can use LOCK TABLES to increase speed, because many newer than the update is not locked in a much faster locking. The contents of the table cut into several tables also can be helpful.
· Experiencing speed problems, you can convert the table if the table is locked in a MySQL InnoDB or BDB table to improve performance
you confused about life right? Then packed up, it started a long journey
Benpian Transfer from: http: //www.cnblogs.com/daxian2012/archive/2012/09/04/mysql.html
Third, the mechanism locks the table
In order to better optimize mysql under high concurrency, it is necessary to look at the lock mechanism when the table mysql query update.
I. Overview
MySQL There are three levels of locks: page-level, table level, row level.
MyISAM and MEMORY storage engine uses a table-level lock (table-level locking); BDB storage engine uses page locks (Page-Level
locking), but also support table lock; the InnoDB storage engine supports both row-level locks (row -level locking), also supports table-level locking, but the default is to use row-level locking.
MySQL lock these three characteristics may be roughly summarized as follows:
Table-level lock: Small overhead, lock fast; not deadlock; lock large size, the probability of lock conflicts of the highest and lowest degree of concurrency.
Row-level locking: large overhead, locking slow; there will be a deadlock; locking the smallest size, lowest probability of lock conflicts, have the highest degree of concurrency.
Page lock: locking overhead and time boundaries between the table and row locks; there will be a deadlock; locking granularity boundary between the table and row locks, concurrency in general.
Two, MyISAM table locks
MyISAM storage engine supports only table lock, is now the most used storage engine.
1, the query table-level lock contention
By checking table_locks_waited table_locks_immediate state variables and analysis table lock contention on the system:
MySQL> Show Status like '% Table';
+ -------- + ---- +
| variable_name | the Value |
+ - + ---- + ------
| Table_locks_immediate | 76,939,364 |
| Table_locks_waited | 305 089 |
+ -------- + ---- +
value 2 rows in set (0.00 sec) Table_locks_waited relatively high , indicating that there is a more serious table-level lock contention.
2, MySQL table lock lock mode
MySQL table-level locking has two modes: a shared table read locks (Table Read Lock) and table exclusive write locks (the Table the Write
Lock). MyISAM before executing the query (SELECT), will be automatically added to all table read locks involved, before performing the update operation (UPDATE, DELETE, INSERT, etc.), will be automatically added to the table write locks involved.
So for MyISAM table operation, there will be the following:
a, a read operation MyISAM tables (plus read lock), without blocking other processes read requests for the same table, but will block write requests to the same table. Only after reading the lock is released, it will perform the write operation of other processes.
b, writes for MyISAM tables (write-lock), will block other processes on the same table read and write operations, write only when the lock is released, will perform read and write operations of other processes.
To verify the above point below by way of example. Data Sheet gz_phone there are over two million data fields id, phone, ua, day. Concurrently while the operating table by analyzing a plurality of clients.
a, I use the client when a relatively long time for a read operation, the client terminal 2 respectively read and write operations:
client1:
mysql>select count(*) from gz_phone group by ua;
75508 rows in set (3 min 15.87 sec) client2:
select id,phone from gz_phone limit 1000,10;
+——+——-+
| id | phone |
+——+——-+
| 1001 | 2222 |
| 1002 | 2222 |
| 1003 | 2222 |
| 1004 | 2222 |
| 1005 | 2222 |
| 1006 | 2222 |
| 1007 | 2222 |
| 1008 | 2222 |
| 1009 | 2222 |
| 1010 | 2222 |
+——+——-+
10 rows in set (0.01 sec)
mysql> update gz_phone set phone=’11111111111′where id=1001;
Query OK, 0 rows affected (2 min 57.88 sec)
Rows matched: 1 Changed: 0 Warnings: 0
Description When the data table has a read lock, other processes query can be executed immediately, but need to wait for the update operation will be performed after a read lock is released.
B, when used to update a client operating a long time, by the client 2 and 3, respectively, read and write operations:
client1:
mysql> update gz_phone set phone=’11111111111′;
Query OK, 1671823 rows affected (3 min 4.03 sec)
Rows matched: 2212070 Changed: 1671823 Warnings: 0 client2:
mysql> select id,phone,ua,day from gz_phone limit 10;
+—-+——-+——————-+————+
| id | phone | ua | day |
+—-+——-+——————-+————+
| 1 | 2222 | SonyEricssonK310c | 2007-12-19 |
| 2 | 2222 | SonyEricssonK750c | 2007-12-19 |
| 3 | 2222 | MAUI WAP Browser | 2007-12-19 |
| 4 | 2222 | Nokia3108 | 2007-12-19 |
| 5 | 2222 | LENOVO-I750 | 2007-12-19 |
| 6 | 2222 | BIRD_D636 | 2007-12-19 |
| 7 | 2222 | SonyEricssonS500c | 2007-12-19 |
| 8 | 2222 | SAMSUNG-SGH-E258 | 2007-12-19 |
| 9 | 2222 | NokiaN73-1 | 2007-12-19 |
| 10 | 2222 | Nokia2610 | 2007-12-19 |
+—-+——-+——————-+————+
10 rows in set (2 min 58.56 sec) client3:
mysql> update gz_phone set phone=’55555′where id=1;
Query OK, 1 row affected (3 min 50.16 sec)
Rows matched: 1 Changed: 1 Warnings: 0
When the data table has a write lock, the read and write operations are required to wait for other processes will be performed after a read lock is released.
3, concurrent insert
In principle, the data table has a read lock, the other process can not update this table, but under certain conditions, MyISAM table queries and also supports insertion of concurrent operations carried out.
MyISAM storage engine has a variable concurrent_insert system, specifically to control the behavior of concurrent insert, and its value may be 0, 1 or 2.
a, is set to 0 when the concurrent_insert, not allow concurrent insertion.
B, when concurrent_insert set to 1, if no voids MyISAM tables (i.e., the middle of the table without being deleted row), while allowing a MyISAM table reading process, another process is inserted from the end of the table records. This is the MySQL default settings.
C, is set to 2 when concurrent_insert, regardless MyISAM table has no voids, allows concurrent insertion end of the table records.
4, MyISAM lock scheduling
Because MySQL write requests are generally considered to be more important than the read request, so if there is simultaneous read and write requests, then, MYSQL will give priority to the write operation. When such a MyISAM table after a lot of update operations (especially in the presence of the field in the updated index) will cause the query operation is difficult to obtain a read lock, resulting in blockage query.
We can adjust the scheduling behavior MyISAM through a number of settings:
a, by specifying boot parameters low-priority-updates, given that the default MyISAM engine as claimed priority to read requests.
b, by executing the command SET LOW_PRIORITY_UPDATES = 1, so that the connection update request sent by lower priority.
C, by specifying the INSERT, UPDATE, LOW_PRIORITY DELETE statement properties, lowers the priority of the statement.
Three methods are either top priority update, or query preferred method. To note here is, do not blindly give priority mysql to read, because some query operation takes a long time to run, but also make the process of writing "starve to death." Only according to your actual situation, to decide what action to take precedence setting. These methods did not solve the problem at the same time query and update fundamentally.
In a high large amount of data and published mysql, we can also adopt another strategy to optimize, that is, to achieve load balancing from (read-write) separated by mysql master, it can avoid the priority which operate so another operation may cause clogging. It will be used to illustrate a write space of separation techniques mysql