系列文章
一、原来一条select语句在MySQL是这样执行的《死磕MySQL系列 一》
二、毕生挚友redo log、binlog《死磕MySQL系列 二》
最近数据库老是呈现上面死锁状况，借着这俩种状况登程具体的了解一下MySQL中的锁。
Lock wait timeout exceeded; try restarting transaction
Deadlock found when trying to get lock; try restarting transaction
一、MySQL中有那些锁
全局锁
依据全局两个字，就能够必定的是给一个整体加上锁。全局锁就是对整个数据库实例加锁。
对于flush tables with read lock，执行实现后整库就处于只读状态，所有语句将被梗塞，包含增删改查、创立表、批改表构造等语句。
表锁
表锁大家都十分相熟了，执行命令lock tables kaka read ,kaka2 write直到unlock tables之前，其它线程是无奈对kaka写kaka2读的。
执行命令的这个线程也只能够对kaka读，kaka2写。
行锁
行锁是在引擎层由各个引擎本人实现的。在MySQL中Innodb存储引擎反对行锁，若不反对行锁意味着并发管制只能应用表锁，对于这种引擎的表，同一张表上任何时刻只能有一个更新在执行，这就会影响到业务并发度。（因为篇幅的起因，下期细谈）
二、全局锁
演示执行flush tables with read lock命令后数据库处于什么状态。
终端1执行全局锁命令
端口2执行删除操作，它不会间接执行胜利，而是在端口1解锁后返回。
这个SQL须要3分钟的执行工夫，这3分钟就是咔咔关上终端2并连贯数据库的工夫。
当初见证了开篇所说的全局锁间接让整个库处于只读状态，这里只演示了删除操作其它的几个操作本人尝试一下。
在蒋老师的文章中看到全局锁最典型的场景是用于逻辑备份，即是将整个库的每一个表都select存储成文本。
当初，你想想这种场景是在什么须要下呈现的。
如果只有一个主库，执行了全局锁整库处于只读状态，那么业务根本停摆，产品无奈应用。
此时你会有疑难我在从库上备份啊！备份期间，不能执行主库同步过去的binlog的，数据量如果十分大，将引发主从提早过大，必须进行全量备份。
以上是全局锁引发的负面状况，但再看备份不加全局锁会呈现什么问题。
置信大多数小伙伴都开发过领取类我的项目，接下来就用领取案例让大家很清晰的了解备份不加全局锁引发的问题。
发动一个逻辑备份。如果一个用户在备份期间购买了你公司的服务，在业务逻辑先扣除用户余额，而后给用户增加你公司对应的产品。
显然，这个逻辑没有问题的，但在非凡案例下执行备份操作就会引发问题。
若在工夫程序上先备份用户余额，而后用户发动购买，接着备份用户购买的产品表。
一个十分清晰的问题呈现了，用户余额没减胜利但用户却取得了对应的产品。
从用户的角度登程那是赚大发了，但这种执行程序如果反过来的话就会产生不一样的后果。
先备份用户产品表，而后备份用户余额表，就会呈现用户钱花了货色没得着，这还得了，用户都是衣食父母这不是再割父母的韭菜。
也就是说，在备份不加锁的话，不同表之间的执行备份的程序不同，如果某个表在备份的过程中进行了更新并且胜利备份而关联的表曾经备份实现无奈再进行跟新，此时就会呈现数据不统一。
在MVCC那篇文章中提到了一个十分重要的概念一致性视图（read view），一致性视图是依据快照读那一刻所有未提交事务的汇合，前提是隔离级别为可反复。
这时你应该晓得要说什么了，没错就是官网大大给提供的逻辑备份工具mysqldump。
mysqldump的备份原理是通过协定连贯到 MySQL 数据库，将须要备份的数据查问进去，将查问出的数据转换成对应的insert 语句，当咱们须要还原这些数据时，只有执行这些 insert 语句，即可将对应的数据还原。
例如备份test库的命令为mysqldump -uroot -p test > /backup/mysqldump/test.db。
当mysqldump应用参数--single-transaction时，备份数据之前会启动一个事物，拿到一致性视图（read view），所以在整个备份的过程中是反对更新的。
既然有了官网大大提供的mysqldump工具为何还要应用flush tables with read lock来将整表锁住呢？
别忘记了刚提到的能够在备份过程中进行更新，能够更新的前提是能够失去一致性视图，获取一致性视图的前提是开启事务。这里你应该分明，不是所有存储引擎都反对事物。
如果有的表应用了别的存储引擎不反对事物，那么就只能应用flush tables with read lock办法，说到这里心愿大家尽量在创立表时都抉择Innodb存储引擎。
看着好一会了，还能记得咱们要干什么吗？需要是全库处于只读状态。
如果你搭建过MySQL的主从架构，就会晓得主库用来写数据，从库用来读数据并且从库不反对写入操作，能够实现这样的成果都是来自于参数readonly。
同样执行set global readonly=true也能够达到整库只读状态，那么为什么从一开始没有给大家说这个计划，那是有起因的。
一是，刚刚提到的搭建主从架构须要应用readonly来判断主库与从库。
二是，在异样解决的形式不同。如果应用flush talbes with read lock命令客户端异样后MySQL会主动开释全局锁，让整个库回到失常状态。而整库设置为readonly后，一旦产生异样就会始终处于只读状态，导致整库长时间处于不可写状态。
所以说数据库一旦加上全局锁后数据的增删改、批改表构造、批改字段等操作都会被锁住。
三、表锁
表锁跟全局锁开释的命令统一unlock tables，同样客户端断开的时候也会主动开释。
在老一辈的反动前辈解决并发都是用的表锁，应该都晓得锁表的影响虽不迭锁库影响大，但在明天锁的粒度曾经反对到行锁了（前提是应用Innodb存储引擎，就没必要再应用行锁来解决并发了。
再来看表锁中的另一位哥们“元数据锁”（metalock）简称“MDL”，这个锁预计很少人晓得，因为在理论开发过程中是不会有理论的语法来开启或敞开。
这个个性是在MySQL5.5版本后引入的，就是为了解决A线程正在查问一个表的数据，在这期间B线程批改了表的数据结构，那么就会造成查问的后果跟表构造对不上，这必定是不行的。
当你拜访一个表时会默认加上MDL写锁，不论在任何时候记住读锁与读锁之间不互斥，读锁与写锁，写锁与写锁之间互斥，晓得行锁的共享锁、排它锁也是这么个理。
那么MDL 不须要显示调用，那它是在什么时候开释的?
答复是：“MDL 是在事务提交后才会开释，这意味着事务执行期间，MDL 是始终持有的。”
那么看一个场景。
首先，线程A开启事务并执行查问语句时，对表加上了MDL锁。
而后，线程B执行的是查问，并不会梗塞住，因为读与读并不抵触。
接着，线程C批改表构造，此时的线程A还未提交事务，MDL还未开释，这时的线程因无奈获取到MDl写锁，就会被阻塞。
最初线程D执行查问会产生什么呢？
答案是梗塞。
到这里依照失常的逻辑，线程C没有获取到MDL的写锁，线程D是能够申请到MDL读锁的，那为什么还会梗塞呢！
这是因为申请MDL锁的操作会造成一个队列，队列中写锁获取优先级高于读锁，一旦呈现MDL写锁期待，会阻塞后续该表的所有CURL操作。
到这里你有没有后背发凉，一旦你在一个未提交事务之后执行了DDL操作，那么等到的后果就是MySQL挂掉，客户端会有重试机制，DDL后所有CURD会在超时后从新发动申请，这个库的线程会很快爆满。
既然这样如何给表平安的执行DDL操作呢？
首先，必须解决到长事务，事务不提交MDL锁就无奈开释。
而后，在MySQL零碎表里找到infomation_schema库中的innodb_trx，能够查看以后正在执行中的事务ID，这个表在事务那期文章中也没少提。
接着，你是不是想kill掉这些长事务而后执行DDL不就得了。
试想一下，当你kill掉的下一刻一个新的事务又进来了，同时你又执行了DDL操作，结果是什么应该分明了哈！这种操作必定是不行的。
官网大大怎么会容许这种状况产生呢！
于是当你执行DDL操作时alter table kaka wait 30 add name能够加一个等待时间，如果在这个等待时间拿到MDL写锁最好，拿不到也不能梗塞后边的业务逻辑，先放弃。再重试执行这个命令。
四、总结
保持学习、保持写作、保持分享是咔咔从业以来所秉持的信念。愿文章在偌大的互联网上能给你带来一点帮忙，我是咔咔，下期见。