Deadlock, I believe everyone is familiar with, plain speaking, there are both eating his bowl, bowl staring at each other, resulting in no way to eat all sides.
For example, A merchant bought a thing, will complete a series of very complex database operations, we can be simplified into two operations, the amount of accounts A -50, then the amount of business is 50. At the same time, small businesses also completed two just this last operation, reviewed a refund A, so the amount of business by 100, 100 to increase the amount of A account. So, in front of one operation we made modifications A row lock the account, the account will be reduced by 50 A, but the transaction is not completed, the need to increase 50 to merchant account. Operating behind a row lock made business, the merchant's account minus 100, if the transaction is not completed is also necessary to wait for row locks get A's, then increase the amount of accounts 100.
In this way, the previous transaction to the user's taken row locks, waiting to lock the business behind the business transaction acquires a lock, waiting for user locks, two people can not be met, the transaction can not be completed, the formation of a deadlock. So when Mysql encountered deadlock, how would you do it? MySQL is by such a configuration, innodb_lock_wait_timeout. That is, if the two sides deadlocked, after more than this time, the two sides let go, once again, this time in case it does not conflict. However, if this time is too long, we can not let users wait for a few tens of seconds and retry it, if we put this time is set too short, so they may be adhered to as accidental injury, had this statement will execute the implementation of two seconds, The results set timeout is one second, the final transaction is rolled back, equal to the white dry.
MySQL also provides another function is to check the deadlock, innodb_deadlock_detect, if we turn this switch on time, every time a statement is executed not get the lock, it will go to traverse the other thread, see if it is a deadlock . Under normal circumstances, I do not recommend turning this switch, for example, if there are 1,000 threads simultaneously update the same row, each transaction is only doing one thing alone because the other 999 threads get locked, it is necessary traverse each other, to see whether the formation of a deadlock, resulting in significant overhead.
So how do we avoid this deadlock encountered it? I think that should be in the business design time, they try to avoid a possible deadlock situation. First of all, we should avoid the above example of such unreasonable design, why do not we be able to make payment for refunds are designed to operate user amount, then the amount of operating businesses do? We have mentioned earlier, the high degree of concurrent Sql statement on the back of affairs, more conducive to the efficiency of the transaction. While reducing the possibility of deadlock, do both.