First, the section reviews the plan today
In the previous article, I introduced the Global MySQL table-level locks and lock with you, today we have to say something about the line lock MySQL.
MySQL's row lock is achieved by each engine tier engines themselves. But not all engines support line lock, such as MyISAM engine does not support row lock. Does not support row lock concurrency control means can only use table locks, for this lead
engine of the table, with a table any time on only one update on the implementation, this will affect the business concurrency. InnoDB supports row lock, which is one of the important reasons for MyISAM be replaced InnoDB.
Today, we will talk mainly of InnoDB row lock, as well as how to improve business concurrency by reducing lock conflicts.
As the name suggests, is the row lock lock data rows in the table for the record. This is well understood, such as Transaction A updates a row, but this time the transaction B should update the same row, you must be able to update and other operations after the transaction A is completed.
Of course, the database and some not so clear concept and design, to understand these concepts and if used improperly, the program appears likely to lead to unexpected behavior, such as two-phase locking.
Second, the two-phase locking Speaking
1, which holds the lock and release at what time
Let me give you an example. In the sequence of operations below, update statements Transaction B would be what a phenomenon it is executed? T id field is assumed that the primary key table.
Conclusions this question depends on transaction A After you perform two update statements, which locks held, and release at what time. You can verify this: actually update statement transaction B will be blocked until the transaction A performs
after commit, the transaction B to continue.
Know the answer, you must know the row lock A two records held by the transaction are not released at the time of the commit.
In other words, InnoDB transaction, the lock is in line only when needed plus, but not immediately does not require a release, but to wait until the end of the transaction release. This is the two-phase locking protocol.
2, if you need transaction locks multiple rows, make the most likely cause lock conflicts, most likely to affect the degree of concurrency lock put back as much as possible.
Know this setting, we use the transaction to have any help? That is, if you need transaction locks multiple rows, make the most likely cause lock conflicts, most likely to affect the degree of concurrency lock put back as much as possible. I'll give you an example.
Suppose you responsible for the realization of a movie ticket online trading business, customer A to buy movie tickets in the theater B. We simplify it, this business need to involve the following:
1. A customer deducted from the account balance in ticket prices; 2. account balance to increase this B movie theater fare; 3. Record a transaction log.
In other words, to complete this transaction, we need to update two records, and insert a record. Of course, in order to ensure atomic transaction, we want these three operations in one transaction. So, how would you arrange these three
sequential statements in a transaction it?
1, we want these three operations in one transaction How would you arrange the order of these three statements in a transaction it?
Imagine if at the same time there is another customer to buy a ticket at the theater C B, then part of the conflict of these two transactions is a 2 statement. Because they want to update the same theater account balance, you need to modify the same rows of data.
According to the two-phase locking protocol, no matter how you arrange the order of statements, row lock all operations are needed when the transaction was submitted released. So, if you put the statement in the last 2 arrangements, such as 3,1,2 in this order,
then the lock time theater account balances row would least. This minimizes the lock wait between transactions, enhance the degree of concurrency.
2, to minimize the lock wait between transactions to enhance the
Well, now thanks to your right design, theater row locks balance of this line in a transaction not stay very long. However, this does not completely solve your problems.
If the theater to do activities, it can be low-cost sale of movie tickets all year, and this event only one day. So in the event start time, your MySQL hung up. You board a look at the server, CPU consumption is nearly
100%, but less than 100 on the implementation of the entire database transactions per second. This is what causes it? Here, I will when it comes to a deadlock and deadlock detection.
Third, deadlock detection and deadlock
When different threads appear circulation system resource dependence concurrent threads involved are waiting for the other thread to release resources, which will lead to several threads wait indefinitely into the state, called the deadlock. Here I give an example with a row lock the database.
At this time, the transaction A releases the lock id = 2 in row B waiting for a transaction, the transaction A transaction B releases the waiting row lock id = 1. Transaction A and Transaction B in each other's resources to wait for the release, is to enter a deadlock state. When the deadlock
in the future, there are two strategies:
1, entered a deadlock situation. When the deadlock occurs, there are two strategies
One strategy is to go directly to wait until a timeout. The timeout period can be set by parameters innodb_lock_wait_timeout.
Another strategy is to initiate deadlock detection, we found that after a deadlock, the deadlock in the chain initiative to roll back a transaction, so that other transactions to proceed. Innodb_deadlock_detect parameter set to on, will indicate on this logic.
1, InnoDB, the default value innodb_lock_wait_timeout is?
In InnoDB, the default value is 50s innodb_lock_wait_timeout
2, innodb_lock_wait_timeout settings that affect the size of the
In InnoDB, the default value is innodb_lock_wait_timeout 50s, means that if the first strategy, when after the deadlock, the first to be locked thread to exit through the 50s before timing out, then other threads may have
to continue carried out. For online services, this waiting time is often unacceptable.
However, we can not directly put this time is set to a small value, such as 1s. So when there is a deadlock, indeed soon be solved, but if it is not a deadlock, but a simple lock wait? Therefore, the timeout
is too short, there will be a lot of friendly fire.
2, under normal circumstances, we adopt the second strategy
Therefore, under normal circumstances, we still have to adopt the second strategy, namely: active deadlock detection, and the default value innodb_deadlock_detect itself is on. Initiative deadlock detection in the event of deadlock, is
able to quickly identify and deal with, but it also has an additional burden.
You can imagine this process: Every time a transaction is locked, it is necessary to see it depends thread has not locked the others, and so on, and finally determine whether there is a waiting loop, which is a deadlock.
3, if it is above us all transactions will be updated when it comes to the scene on the same line it?
1, the second strategy problems
Each new thread is blocked, and will not be judged because of their added led to a deadlock, which is a time-multiplexed
miscellaneous degree is O (n) operation. Suppose there are 1000 concurrent threads to simultaneously update the same row, then the deadlock detection operation will
be 1 million this magnitude. Although the results of the final test is no deadlock, but it consumes a lot of CPU time
resources. So, you will see the CPU utilization is high, but it can not perform several transactions per second.
According to the above analysis, let's talk about how to solve performance problems caused by such hot-line update causes it? Problem
crux is that the deadlock detection to spend a lot of CPU resources
2, a method of piecemeal, that is, if you can ensure that the business will not deadlock, the deadlock detection can temporarily switch off
A method of piecemeal, that is, if you can ensure that the business will not deadlock, deadlock detection can temporarily put off. But the operation itself with a certain risk, because when business is generally not designed to deadlock as Yi
serious mistake, after all deadlock, and it rolled back and try again generally no problem through the business, which business is lossless. The deadlock detection means may turn off a lot of time out there will be, which is detrimental to the business.
3. Another approach is to control the degree of concurrency
Another idea is to control the degree of concurrency. Based on the analysis above, you will find that if a concurrent can control, such as the same line at the same time only a maximum of 10 threads in the update, then a very low cost deadlock detection, it will not have this problem. A
straightforward idea is to make the client concurrency control. However, you will soon find that this approach is not feasible, because a lot of clients. I've seen an application, there are 600 clients, so that even if each client to control only five concurrent
threads, rolled up to the database server after the peak number of concurrent also possible to reach 3000.
Therefore, concurrency control to do this in
1, the database server.
2, if you have the middleware, consider Middleware;
3, if you have a team of people able to modify MySQL source code, which can be done in MySQL.
The basic idea is for updating the same row, line up before entering the engine. So there is not a lot of deadlock detection work inside the InnoDB
4, if the team is not being experts in databases, and can not achieve such a program, this problem can not be optimized from the design?
You may wish to consider the line into multiple lines of logic to reduce lock conflicts. Or in the theater account, for example, can be considered on many records, such as 10 records, total account value equal to the sum of the theater these 10 records. Thus each
secondary account to increase the amount of time the theater, where randomly selected to add a record. So each collision probability becomes 1/10, can reduce the number of lock wait, it reduces the CPU consumption deadlock detection.
This program appears to be lossless, but in fact, such programs need to do the detailed design based on business logic. If the account balance may be reduced, such as refund logic, then this time you need to consider when part of rows becomes 0 when the code
must be special treatment.
IV Summary
Today, I introduce you to the MySQL row lock, involving a two-phase locking protocol, deadlock detection and deadlock the two most content.
Among them, I have a two-stage agreement as a starting point, and you together to discuss how to arrange the correct transaction statement at the time of development. The principle here / My advice to you is: If your transaction requires more than one row lock, the lock should most likely to cause conflict,
most likely to affect the timing of the application concurrency lock put back as much as possible.
However, adjusting the sequence of statements does not completely avoid deadlock. So we introduced the concept of deadlocks and deadlock detection, and offers three programs to reduce the impact of deadlocks on the database. The main direction of reducing the deadlock, is to control access to the same
transaction amount of concurrent resources.
Finally, I leave you a question now. If you want to delete the first 10,000 rows of data inside a table, there are three ways to do this:
- The first, direct execution delete from T limit 10000;
- The second, connected in a loop is executed 20 times the delete from T limit 500;
- Third, while performing delete from T limit 500 in the 20 connection.
Which method would you choose? why?
You can put your thoughts and ideas written in the comments section, I will end next article and you discuss this issue. Thank you for listening, you are welcome to send this share to more friends to read together.
Fifth, on the issue of time
On Problems I left you is: When did the logical standby database backups with -single-transaction time, if a DDL statement came from what happens binlog main library?
Assuming that this is the DDL for table t1, where I put the backup process in several key statements listed:
Q1:SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ; Q2:START TRANSACTION WITH CONSISTENT SNAPSHOT； /* other tables */ Q3:SAVEPOINT sp; /* 时刻 1 */ Q4:show create table `t1`; /* 时刻 2 */ Q5:SELECT * FROM `t1`; /* 时刻 3 */ Q6:ROLLBACK TO SAVEPOINT sp; /* 时刻 4 */ /* other tables */
At the beginning of the backup, in order to ensure RR (repeatable read) isolation level, and then set a RR isolation level (Q1); start a transaction, here WITH CONSISTENT SNAPSHOT ensure the implementation of this statement is finished you can get a
consistent view (Q2) ; save a set point, this is very important (Q3);
show create table structure in order to get (Q4), and the formal derivative data (Q5), the rollback SAVEPOINTsp, role here is to release the lock of t1 MDL (Q6). Of course, this part are "Chaogang", inside the body not mentioned above.
DDL pass from the main library over time according to different effect, I played four times. Topic set to a small table, we assume that after arrival, if started, you will soon be able to perform to complete.
Reference answer is as follows:
1. If you arrive before Q4 statement is executed, the phenomenon: no effect, get back up the table structure is the DDL.
2. If the "time 2" arrives in, the table structure is to change, when executed Q5, reported Table definition haschanged, please retry transaction, phenomena: mysqldump termination;
between 3. If the "time 2" and "time 3" reach, mysqldump occupied t1 of MDL read lock, binlog is blocked phenomenon: the master-slave delay until execution is completed Q6.
4. From the "time 4" Start, mysqldump release of MDL read lock phenomenon: no effect, get back up the table structure is in front of DDL.