According to the range of locking ,MySQL The locks inside can be roughly divided into global locks 、 Table level lock and row lock .

One 、 Global lock

MySQL It provides a way to add global read lock , The order is Flush tables with read lock (FTWRL). When you need to make the entire library read-only , You can use this command , After that, the following statements of other threads will be blocked ： Data update statement （ Data addition, deletion and modification ）、 Data definition statement （ Including building tables 、 Modify table structure, etc ） Commit statements for and update class transactions .

** A typical use scenario for global locks is , Make a full library logical backup .** That is to say, every table in the whole library select Come out and save it as text .

The official logic backup tool is mysqldump. When mysqldump Using parameter –single-transaction When , A transaction will be started before importing data , To ensure a consistent view . And because the MVCC Support for , During this process, the data can be updated normally .

You must be wondering , With this function , Why do we still need FTWRL Well ？ Consistent reading is good , But only if the engine supports this isolation level . such as , about MyISAM This engine does not support transactions , If there is an update during the backup , Always only get the latest data , Then it destroys the consistency of the backup . At this time , We need to use it FTWRL The command .

therefore ,single-transaction Method only applies to all tables using the transaction engine's Library . If some tables use an engine that does not support transactions , Then backup can only be through FTWRL Method .

Two 、 Table lock

MySQL There are two types of lock at the inner table level ： One is watch lock , One is metadata lock （meta data lock,MDL).

1、 Table locks 1： Lock the table structure and table data

The syntax of table lock is lock tables … read/write. And FTWRL similar , It can be used unlock tables Active release lock , It can also be released automatically when the client is disconnected . We need to pay attention to ,lock tables The syntax will restrict the reading and writing of other threads , It also defines the next operation objects of this thread .

for instance , If in a thread A In the implementation of lock tables t1 read, t2 write; This statement , Other threads write t1、 Reading and writing t2 All of the statements will be blocked . meanwhile , Threads A In execution unlock tables Before , It can only be read t1、 Reading and writing t2 The operation of . Linking t1 Not allowed , Naturally, you can't access other tables .

The disadvantage of this locking method is that the granularity of the lock is too large .

2、 Table locks 2： Table structure lock MDL（metadata lock)

stay MySQL 5.5 The version introduces MDL, When adding, deleting, modifying and querying a table , Add MDL Read the lock ; When you want to make structural changes to a table , Add MDL Write lock ,MDL The lock is added by default , No need for extra operation .

• Read locks are not mutually exclusive , So you can have multiple threads to add, delete, modify and query a table at the same time .
• Read-write lock 、 Write locks are mutually exclusive , To ensure the security of the operation to change the structure of the table . therefore , If two threads want to add fields to a table at the same time , One of them can't be executed until the other has finished .

Add fields to a table , Or modify the fields , Or the Caucasian , Need to scan the data of the whole table .

The environment is MySQL 5.6

We can see session A Start... First , I'll check my watch t Add one more MDL Read the lock . because session B What is needed is MDL Read the lock , So it can be executed normally .

after session C Will be blocked, Because session A Of MDL The lock has not been released , and session C need MDL Write lock , So it can only be blocked .

If only session C It doesn't matter that I'm blocked , But after that, it's all on the watch t New application MDL The request to read the lock will also be session C Blocking . We said that before , All operations of adding, deleting, modifying and querying tables need to be applied for first MDL Read the lock , They're all locked , It means that it's completely unreadable .

If the query statements on a table are frequent , And the client has a retry mechanism , That is to say, there will be a new one after the timeout session If you ask again , The threads in this library will soon be full .

You should know by now , In the transaction MDL lock , Apply at the beginning of statement execution , However, the statement is not released immediately after completion , It will wait until the whole transaction is committed before releasing , Therefore, you should be very careful when changing the table structure .

Based on the above analysis , Let's talk about a problem , How to add fields to a small table safely ？

First of all, we have to deal with long affairs , The transaction does not commit , Will always occupy MDL lock . stay MySQL Of information_schema Library innodb_trx In the table , You can find the current transaction in progress . If you want to do DDL The changed table happens to have a long transaction running , Consider suspending DDL, perhaps kill Drop this long business .

But think about this scenario . If the table you want to change is a hotspot table , Although the amount of data is small , But the requests are frequent , And you have to add a field , What should you do ？

Now kill It may not work , Because new requests are coming soon . The ideal mechanism is , stay alter table Set the waiting time in the statement , If you can get it within the specified waiting time MDL It's better to write lock , Don't block the following business statements if you can't get them , Give up first . Then the developer or DBA Repeat the process by retrying the command .

MariaDB Has merged AliSQL This function of , So these two open source branches currently support DDL NOWAIT/WAIT n This grammar .

ALTER TABLE tbl_name NOWAIT add column ...
ALTER TABLE tbl_name WAIT N add column ... 

3、 ... and 、 Row lock

MySQL The row lock is implemented by each engine in the engine layer . But not all engines support row locks , such as MyISAM The engine doesn't support row locks . Not supporting row locks means that concurrency control can only use table locks , For tables with this engine , Only one update can be executed on the same table at any time , This will affect the business concurrency .InnoDB It supports row locking , This is also MyISAM By InnoDB One of the important reasons for substitution .

stay InnoDB Transaction , Row locks are added when needed , But it's not about releasing them immediately when they don't need to , It's about waiting until the end of the transaction . This is the two-stage lock protocol .

If you need to lock multiple rows in your transaction , The most likely cause of lock conflict 、 The lock most likely to affect concurrency should be put back as far as possible .

Deadlock and deadlock detection

When there's a deadlock , There are two strategies ：

• One strategy is , Direct entry waiting , Until timeout . This timeout can be set by the parameter innodb_lock_wait_timeout To set up .
• Another strategy is , Initiate deadlock detection , After deadlock is found , Actively roll back a transaction in the deadlock chain , Allow other business to continue . The parameter innodb_deadlock_detect Set to on, Indicates that the logic is turned on ,mysql The default value is also on. Active deadlock detection when deadlock occurs , It can be found and processed quickly , But it also has an extra burden .

stay InnoDB in ,innodb_lock_wait_timeout The default value of is 50s, That means if you use the first strategy , When there's a deadlock , The first locked thread will pass 50s Will time out , Then it's possible for other threads to continue . For online services , This waiting time is often unacceptable .

If the time is too short, it may be the lock waiting for a longer time , So it may be accidentally injured .

therefore , Under normal circumstances, we still need to adopt the second strategy , namely ： Active deadlock detection .

How to solve the performance problem caused by this hot line update ？

1、 A method of treating headache , If you can make sure that there will be no deadlock in this business , Can temporarily turn off deadlock detection .

But there is a certain risk in this operation , Because business design generally does not regard deadlock as a serious error , After all, there's a deadlock , Just roll back , Then it's OK to retry through business , This is business intact . Turning off deadlock detection means that there may be a lot of timeouts , It's business that's damaging .

2、 Another idea is to control concurrency .
This concurrency control should be done on the database server . If you have Middleware , Consider middleware implementation ; If your team has the ability to modify MySQL Source person , It can also be done in MySQL Inside . The basic idea is , For peer updates , Queue up before getting into the engine . In this way InnoDB There won't be a lot of deadlock detection work inside .

If there is no database expert on the team for the time being , You can't do this , Can we optimize this problem from the design ？

You can consider reducing lock conflicts by changing one row to logical multiple lines . Take cinema accounts for example , Consider putting it on multiple records , such as 10 A record , The total number of cinema accounts is equal to this 10 The sum of the recorded values . So every time you have to add money to your movie theater account , Randomly select one of the records to add . So the probability of each conflict becomes the same 1/10, Can reduce the number of locks waiting , It also reduces the deadlock detection CPU Consume .

The plan seems to be undamaged , But in fact, such schemes need to be designed in detail according to business logic . If the account balance is likely to decrease , Such as refund logic , Then we need to consider when a branch record becomes 0 When , Code has to have special handling .