关于mysql:MySQL学习笔记4锁

I、锁分类

锁粒度越大，开销越小，锁抵触的概率越小，安全性也就越高，但业务并发度以及性能越差；反之锁粒度越小，开销也就越大，锁抵触的概率越大（易导致死锁），安全性也就越低，但业务并发度以及性能越好。

II、全局锁

1、应用场景：全库逻辑备份。反对 MVCC 的可不必。
2、应用危险：
——如果在主库备份，在备份期间不能更新，业务停摆
——如果在从库备份，备份期间不能执行主库同步的 binlog，导致主从提早。
3、官网自带的逻辑备份工具 mysqldump，当 mysqldump 应用参数 –single-transaction 的时候，会启动一个事务，确保拿到一致性视图。而因为 MVCC 的反对，这个过程中数据是能够失常更新的。然而前提是引擎要反对这个隔离级别。
4、如果要全库只读，为什么不应用 set global readonly=true 的形式？
——在有些零碎中，readonly 的值会被用来做其余逻辑，比方判断主备库。所以批改 global 变量的形式影响太大。
——在异样解决机制上有差别。如果执行 FTWRL 命令之后因为客户端产生异样断开，那么 MySQL 会主动开释这个全局锁，整个库回到能够失常更新的状态。而将整个库设置为 readonly 之后，如果客户端产生异样，则数据库就会始终放弃 readonly 状态，这样会导致整个库长时间处于不可写状态，危险较高。

III、表级锁

1、分类：表锁，元数据所 (meta data lock,MDL)。
表锁的语法是:lock tables … read/write
2、unlock tables 命令被动开释锁，客户端断开的时主动开释。
3、lock tables 语法除了会限度别的线程的读写外，也限定了本线程接下来的操作对象。对于 InnoDB 这种反对行锁的引擎，个别不应用 lock tables 命令来管制并发，毕竟锁住整个表的影响面还是太大。
4、MDL 保障读写的正确性
——不须要显式应用，在拜访一个表的时候会被主动加上。
——何时应用：在对一个表做增删改查操作的时候；当要对表做构造变更操作的时候
——读锁之间不互斥。读写锁之间，写锁之间互斥。
——MDL 直到事务提交才开释

IV、行锁

1、两阶段锁协定：在 InnoDB 事务中，行锁是在须要的时候才加上的，但并不是不须要了就立即开释，而是要等到事务完结时才开释。
2、如果你的事务中须要锁多个行，要把最可能造成锁抵触、最可能影响并发度的锁尽量往后放。锁的粒度越大，锁抵触的可能性越大，语句越后执行；锁粒度越小，锁抵触的可能性越小，语句越先执行。
3、死锁：当并发零碎中不同线程呈现循环资源依赖，波及的线程都在期待别的线程开释资源时，就会导致这几个线程都进入有限期待的状态。如 A 等 B，B 等 C，C 等 A。
4、死锁解决方案：
——设置超时工夫（参数：innodb_lock_wait_timeout，InnoDB 默认 50s）。
——发动死锁检测。发现死锁后，被动回滚死锁链条中的某一个事务，让其余事务得以持续执行（参数：innodb_deadlock_detect=on，默认开启）。过程示例：新来的线程 F，被锁了后就要查看锁住 F 的线程（假如为 D）是否被锁，如果没有被锁，则没有死锁，如果被锁了，还要查看锁住线程 D 的是谁，如果是 F，那么必定死锁了，如果不是 F（假如为 B），那么就要持续判断锁住线程 B 的是谁，始终走晓得发现线程没有被锁（无死锁）或者被 F 锁住（死锁）才会终止。
5、热点行更新景象：每个新来的被堵住的线程，都要判断会不会因为本人的退出导致了死锁，这是一个工夫复杂度是 O(n)的操作。假如有 1000 个并发线程要同时更新同一行，那么死锁检测操作就是 100 万这个量级的。尽管最终检测的后果是没有死锁，然而这期间要耗费大量的 CPU 资源。
热点行更新：
1、不倡议：如果你能确保这个业务肯定不会呈现死锁，能够长期把死锁检测敞开掉。
2、管制并发度。对应雷同行的更新，在进入引擎之前排队。这样在 InnoDB 外部就不会有大量的死锁检测工作了。如果你有中间件，能够思考在中间件实现；如果你的团队有能批改 MySQL 源码的人，也能够做在 MySQL 外面。基本思路就是，对于雷同行的更新，在进入引擎之前排队。这样在 InnoDB 外部就不会有大量的死锁检测工作了。
3、将热更新的行数据拆分成逻辑上的多行来缩小锁抵触，然而业务复杂度可能会大大提高。