I. Background
MySQL inside the lock can be divided into global lock table level three and row locks. The original intention of the design database lock is to deal with concurrency issues. We know that when multiple users share the resources of time, there may occur concurrent access, database access rules would need a reasonable control of resources, therefore, the lock came into being, it is mainly used to achieve these important data access rules structure.
Second, the global lock
As the name suggests, a global lock is to lock the entire database instance, you can lock the entire database instance sub-Flush tables with read lock (FTWRL) command. Let the entire library read-only, they can use this command, the following statement after the other threads will be blocked: Data update statements (additions and deletions to the data), data definition statements (including the construction of the table, modify table structure, etc.) and update submit statements of affairs category.
Global Lock has a classic usage scenario is to do a full backup of database logic, it means that the entire database each table are saved as text with select out. Before there is a practice by FTWRL ensure that no other thread to make a database update, and then make a backup of the entire library. Note that the backup process is completely the entire library is read-only.
At this point you are not that dangerous?
If you backed up on the main library, it can not perform updates during the backup, business basically have to shut down;
If you back up from the library, then the backup can not be performed during synchronized from the main library from the library's binlog, will lead to a master-slave delay.
Looks really dangerous, but we think of it, why do you want to lock it back up? If we do not lock any problem would happen?
Suppose you want to maintain the purchasing system Jingdong concern is that the user account balance tables and user product table.
Now initiate a logical backup. During assume a backup, there is a user, he bought a piece of merchandise, business logic where necessary to deduct his balance, then go inside of items purchased, plus a commodity.
If the order is the time to back up the account balances (u_account), then users to buy, and then back up user product table (u_course), what will happen? You can look at this chart:
From the chart you can see the user's data status is "account balance did not buckle, but the user commodity which has more than a commodity." If later use this backup to restore the data, users actually find themselves actually own account for no reason more than 50, standing in the company point of view, you pack up and leave it. But users do not happy, if the backup order table, in turn, to back up a user account balances merchandise table and then back up the table, and what the outcome might be?
That of course is back with this backup to restore the data, users actually find themselves account money detained, but did not buy a razor. In other words, do not lock it, backup system to back up to get the library is not a logical point in time, this view is inconsistent logic. This is the time you definitely want to talk about the transaction isolation channel talking about my previous article, in fact, is there a way to be able to get a consistent view.
Yes, without a doubt it is to open in a repeatable read transaction isolation sectors under can get a consistent view.
The official comes logical backup tool is mysqldump. When mysqldump When using parameter -single-transaction, it will start a transaction before the guide data, to ensure to get a consistent view. And because of MVCC support, data in this process is normally updated.
Since there are so useful feature, why do you need to do a backup FTWRL it?
Consistency is a good read, but do not forget that the premise is the engine to support this isolation level. For example, for MyISAM engine does not support such a transaction, if the backup process of an update, always to only take the most recent data, then it undermines a consistent backup. This time FTWRL the command comes in handy.
Thus, single-transaction method can only be used for all tables transaction engine library. If any table using the engine does not support transactions, the backup only through FTWRL method. That's one of the reasons why the InnoDB than myISAM popularity.
Here, you might think, why we do not set global readonly = true command so that the whole library in read-only state?
Note that this is strictly prohibited production, mainly for two reasons:
1. In some systems, readonly values will be used to do other logic, such as a library is used to determine the main library or a library equipment. There is no doubt modify global variables affect the way a larger surface.
2. there are differences in the exception handling mechanism. If you execute the command after FTWRL abnormal because the client is disconnected, then MySQL automatically releases the global lock, the entire library may return to normal status updates. The entire library is set to readonly after, if the client is an exception occurs, the database will remain readonly state, this will cause the entire library for a long time in a non-writable state, it is likely to cause accidents.
Third, the table-level locking
MySQL inside the table level lock, there are two: one is a table lock a lock metadata (meta data lock, MDL).
The syntax is a table lock lock tables ... read / write. And FTWRL similar, can unlock tables initiative to release the lock can also be automatically released when the client disconnects. Note, lock tables in addition to the syntax outer limit read another thread, this thread also defines the next operation target. For example, if you do lock tables t1 read in a thread in A, t2 write; this statement, the other threads write t1, t2 read the statement will be blocked. Meanwhile, before executing thread A unlock tables, you can only perform read t1, t2 of the read and write operations. Writing for t1 are not allowed to, naturally, can not access other tables.
When more fine-grained lock has not yet appeared, the table lock is the most common way to handle concurrency. And this support for InnoDB row lock engine, generally do not use lock tables commands to control concurrency, after all, the impact was still too big to lock the entire table, the impact of concurrency.
The other table-level locking is MDL (metadata lock). MDL no explicit use is automatically added when accessing a table. When a table to do CRUD operations when adding MDL read lock; when you want to change the structure of the table to do the operation, plus MDL write lock. You can imagine, if a query is through the data in a table, and during the execution of another thread on this table structure make changes, delete one, then the query to get the result with the thread structure not on the table, certainly not of. Therefore, the introduction of the MDL in the MySQL 5.5 release.
We know not mutually exclusive read lock, so you can have multiple threads simultaneously on a table CRUD. But between the read-write lock, write lock is between mutually exclusive, to ensure the safety of the operation of the change table structure. Therefore, if there are two threads to simultaneously add fields to a table, to wait for another one to begin executing the execution.
Please note that a lot of people in MDL lock a little carelessness will fall into the pit: a small table to add a field, leading to the entire library hung up. We all know that to add a table fields, or modify the field, or indexed, you need a full table scan data. When operating on a large table, you will certainly be particularly careful to avoid impact on the online service. In fact, even a small table, careless operation will go wrong. The following sequence of operations we look, suppose table t is a small table.
As shown above, before starting the session A, t this time will add MDL table read locks. Session B is MDL read lock, we know, by the above knowledge to know, before MDL read locks are not mutually exclusive, so you can execute properly.
Next Session C will be blocked, why is it blocked? Combined with the above knowledge, we know that MDL read lock A session has not been released, but the session requires C MDL write locks, it can only be blocked. If the only session will be blocked C own good, after all to think carefully about the new application requesting MDL read lock on the table conversation C t will be blocked. Through previous knowledge, we know that all additions and deletions to the table to change search operations need to apply for MDL read lock, were all locked, not completely equal to the performance of read and write. If there is frequent statements on a table query, but clients have to retry this mechanism, after a timeout will be renewed again request a new session, then thread the library will soon be full. This is why even a small table, careless operation, leading to the entire library hung up. We now know that the MDL lock transaction, the statement is executed at the beginning of the application, but after the end of the statement and will not be released immediately, but will wait until the entire transaction to commit before release.
Based on the above analysis, we discuss a problem, how to safely add fields to the little table?
First of all we have to solve a long transaction, the transaction is not submitted, it would have been occupied MDL lock. Innodb_trx table in the MySQL information_schema library, you can check the current execution of the transaction. If you do happen to have a table DDL changes in long transaction execution, pause to consider the DDL, or kill off the long transaction.
但考虑一下这个场景。如果你要变更的表是一个热点表，虽然数据量不大，但是上面的请求很频繁，而你不得不加个字段，你该怎么做呢？
这时候kill可能未必管用，因为新的请求马上就来了。比较理想的机制是，在alter table语句里面设定等待时间，如果在这个指定的等待时间里面能够拿到MDL写锁最好，拿不到也不要阻塞后面的业务语句，先放弃。之后开发人员或者DBA再通过重试命令重复这个过程。MariaDB已经合并了AliSQL的这个功能，所以这两个开源分支目前都支持DDL NOWAIT/WAIT n这个语法。
ALTER TABLE tbl_name NOWAIT add column ...
ALTER TABLE tbl_name WAIT N add column ...
接下来聊聊InnoDB的行锁，以及如何通过减少锁冲突来提升业务并发度。为什么我不讲解基于MyISAM的呢？，大家别忘了我们前面提到的MyISAM引擎就不支持行锁。不支持行锁意味着并发控制只能使用表锁，对于这种引擎的表，同一张表上任何时刻只能有一个更新在执行，这就会影响到业务并发度。InnoDB是支持行锁的，这也是MyISAM被InnoDB替代的重要原因之一。
那什么是行锁呢？见其名知其意，行锁主要是针对数据库表中行记录的锁，举个通熟易懂的例子，比如事务A更新一行，与此同时，事务B 也要要更新同一行，则必须等事务A的操作完成后才能进行更新。
我这里为什么要讲这些概念性东西呢？很简单，如果我们对概念的理解不透彻，进行生产的时候，一不小心就导致程序出现一些非预期的行为。就好比如二阶段锁。
接下来通过一个例子讲解二阶段锁的注意事项，例子如下：
从上图可以看到，按照时间的顺序操作，事务执行update 语句时，会发什么事情呢？上图的 id 是表T的主键。
这问题主要看事务A在执行完两条update 后，拥有哪些锁，在什么时候释放锁。很明显事务B 的update 会被阻塞，知道事务A执行commit提交时候后，事务B才能继续执行。因为事务A持有的两个记录的行锁，都是commit 的时候才释放的。
因此，在InnoDB事务中，行锁是在需要的时候才加上的，但并不是不需要了就立刻释放，而是要等到事务结束时才释放。这个就是两阶段锁协议。
我们知道这个设定，有什么用呢？貌似对于我们使用事务有什么帮助呢？
还是很有帮助的，例如，如果你的事务中需要锁多个行，要把最可能造成锁冲突、最可能影响并发度的锁尽量往后放。如果你此时负责实现一个在线交易的购物平台，用户A在某东上购买了一部手机，这个过程主要涉及一下几个操作：
1.从用户A账户中扣除手机的价钱；
2.给某东的账户余额增加这部手机的价钱；
3.记录一条交易日志。
这个操作过程，为了保证交易的原子性，必然要把这三个操作放在一个事务中的，我们需要update 两条记录，并且insert 一条记录，那么我们如何安排这三个语句在事务中的顺序呢？
如果此时还有另外一个用户B在某东上买了一本Java，那么两个事务中冲突的部门必然是语句 2 了，因为它们要更新某东账户的余额，需要更改同一行数据。
根据两阶段锁协议，不论你怎样安排语句顺序，所有的操作需要的行锁都是在事务提交的时候才释放的。所以，如果你把语句2安排在最后，比如按照3、1、2这样的顺序，必然某东余额这一行的锁时间就最少。这就最大程度地减少了事务之间的锁等待，提升了并发度。
虽然余额这一行的行锁在一个事务中不会停留很长时间，但是并不能完全解决问题。
下面再举个例子，如果某东 6.18活动，低价预售所有的商品，活动刚开始的时候，你发现你的数据库突然就挂了，那么此时你进行排查问题，top 命令等一系列操作，于是看到CPU 几乎百分百，但是整个数据库每秒就执行不到2000个事务（这里我只是假设的呀，我也不知道某东的具体情况，不要抬杠，哈哈）。到这里，就必须说说死锁和死锁的检测了。
四、死锁和死锁检测
当并发系统中不同线程出现循环资源依赖，涉及的线程都在等待别的线程释放资源时，就会导致这几个线程都进入无限等待的状态，称为死锁。接下来用行锁举个例子。
从上图可以看到，事务A在等待事务B释放id=2的行锁，而事务B在等待事务A释放id=1的行锁。 事务A和事务B在互相等待对方的资源释放，就是进入了死锁状态。
当出现死锁以后，有两种策略：
- 一种策略是，直接进入等待，直到超时。这个超时时间可以通过参数innodb_lock_wait_timeout来设置。在InnoDB中，innodb_lock_wait_timeout的默认值是50s，意味着如果采用第一个策略，当出现死锁以后，第一个被锁住的线程要过50s才会超时退出，然后其他线程才有可能继续执行。对于在线服务来说，这个等待时间往往是无法接受的。但是，我们又不可能直接把这个时间设置成一个很小的值，比如1s。这样当出现死锁的时候，确实很快就可以解开，但如果不是死锁，而是简单的锁等待呢？所以，超时时间设置太短的话，会出现很多误伤。
- 另一种策略是，发起死锁检测，发现死锁后，主动回滚死锁链条中的某一个事务，让其他事务得以继续执行。将参数innodb_deadlock_detect设置为on，表示开启这个逻辑。所以，正常情况下我们还是要采用第二种策略，即：主动死锁检测，而且innodb_deadlock_detect的默认值本身就是on。主动死锁检测在发生死锁的时候，是能够快速发现并进行处理的，但是它也是有额外负担的。
你可以想象一下这个过程：每当一个事务被锁的时候，就要看看它所依赖的线程有没有被别人锁住，如此循环，最后判断是否出现了循环等待，也就是死锁。
那如果是我们上面说到的所有事务都要更新同一行的场景呢？
每个新来的被堵住的线程，都要判断会不会由于自己的加入导致了死锁，这是一个时间复杂度是O(n)的操作。假设有1000个并发线程要同时更新同一行，那么死锁检测操作就是100万这个量级的。虽然最终检测的结果是没有死锁，但是这期间要消耗大量的CPU资源。因此，你就会看到CPU利用率很高，但是每秒却执行不了几个事务。
根据上面的分析，我们来讨论一下，怎么解决由这种热点行更新导致的性能问题呢？问题的症结在于，死锁检测要耗费大量的CPU资源。
第一种方法就是如果你能确保这个业务一定不会出现死锁，可以临时把死锁检测关掉。但是这种操作本身带有一定的风险，因为业务设计的时候一般不会把死锁当做一个严重错误，毕竟出现死锁了，就回滚，然后通过业务重试一般就没问题了，这是业务无损的。而关掉死锁检测意味着可能会出现大量的超时，这是业务有损的。
另一个思路是控制并发度。根据上面的分析，你会发现如果并发能够控制住，比如同一行同时最多只有10个线程在更新，那么死锁检测的成本很低，就不会出现这个问题。一个直接的想法就是，在客户端做并发控制。但是，你会很快发现这个方法不太可行，因为客户端很多。我见过一个应用，有600个客户端，这样即使每个客户端控制到只有5个并发线程，汇总到数据库服务端以后，峰值并发数也可能要达到3000。
因此，这个并发控制要做在数据库服务端。如果你有中间件，可以考虑在中间件实现；如果从MySQL 源码上修改，基本思路就是，对于相同行的更新，在进入引擎之前排队。这样在InnoDB内部就不会有大量的死锁检测工作了。
那么我们能不能从设计上优化这个问题呢？
你可以考虑通过将一行改成逻辑上的多行来减少锁冲突。还是以某东账户为例，可以考虑放在多条记录上，比如10个记录，某东的账户总额等于这10个记录的值的总和。这样每次要给某东账户加金额的时候，随机选其中一条记录来加。这样每次冲突概率变成原来的1/10，可以减少锁等待个数，也就减少了死锁检测的CPU消耗。
这个方案看上去是无损的，但其实这类方案需要根据业务逻辑做详细设计。如果账户余额可能会减少，比如退货逻辑，那么这时候就需要考虑当一部分行记录变成0的时候，代码要有特殊处理。