MySQL 锁机制
锁是计算机协调多个进程或线程并发访问某一资源的机制(避免争抢)。
在数据库中，除传统的计算资源(如CPU、RAM、I/O等)的争用以外，数据也是一种供许多用户共享的资如何保证数据并发访问的一致性、有效性是所有数据库必须解决的一个问题，锁冲突也是影响数据库并发访问性能的一个重要因素。从这个角度来说，锁对数据库而言显得尤其重要，也更加复杂。
从对数据操作的粒度分：
1.表锁：操作时，会锁定整个表。
2.行锁：操作时，会锁定当前操作行。
从对数据操作的类型分：
1.读锁(共享锁)：针对同一份数据，多个读操作可以同时进行而不会互相影响。
2.写锁(排它锁)：当前操作没有完成之前，它会阻断其他写锁和读锁。
其中，InnoDB表锁和行锁都支持，而MyISAM只支持表锁
MySQL锁的特性
表级锁 偏向MyISAM存储引擎，开销小，加锁快不会出现死锁：锁定粒度大，发生锁冲突的概率最高，并发度最低。
行级锁 偏向InnoDB存储引擎，开销大，加锁慢；会出现死；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。
从上述特点可见，很难笼统地说哪种锁更好，只能就具体应用的特点来说哪种锁更合适！仅从锁的角度来说：
-
表级锁更适合于以查询为主，只有少量按索引条件更新数据的应用，如Web应用；
-
行级锁则更适合于有大量按索引条件并发更新少量不同数据，同时又有并查询的应用，如一些在线事务处理(OLTP)系统。
如何加锁
MyISAM表锁：MyISAM存储引擎只支持表锁
MyISAM在执行查询语句(SELECT)前，会自动给涉及的所有表加读锁，在执行更新操作(UPDATE、DELETE、INSERT等)前，会自动给涉及的表加写锁，这个过程并不需要用户干预，因此，用户一般不需要直接用LOCK TABLE 命令给MyISAM表显式加锁。
- 加读锁：lock table table_name read;
- 加写锁：lock table table_name write;
InnoDB行锁：
行锁特点：偏向InnoDB存储引擎，开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。
InnoDB与MyISAM的最大不同有两点：一是支持事务；二是采用了行级锁。
行锁模式：InnoDB 实现了以下两种类型的行锁。
共享锁(S) 又称为读锁，简称S锁，共享锁就是多个事务对于同一数据可以共享一把锁，都能访问到数据，但是只能读不能修改。
排他锁（X） 又称为写锁，简称x锁，排他锁就是不能与其他锁并存，如一个事务获取了一个数据行的排他锁，其他事务就不能再获取该行的其他锁，包括共享锁和排他锁，但是获取排他锁的事务是可以对数据就行读取和修改。
对于UPDATE、DELETE和INSERT语句，InnoDB会自动给涉及数据集加排他锁(X)；
对于普通SELECT语句，InnoDB不会加任何锁；
- 共享锁（S）：SELECT ★ FROM table name WHERE ... LOCK IN SHARE MODE
- 排他锁（X）：SELECT ★ FROM table name WHERE ... FOR UPDATE
死锁
死锁是指两个或多个事务在同一资源上相互占用，并请求锁定对方的资源，从而导致恶性循环的现象。
常见的解决死锁的方法：
- 如果不同程序会并发存取多个表，尽量约定以相同的顺序访问表，可以大大降低死锁机会。
- 在同一个事务中，尽可能做到一次锁定所需要的所有资源，减少死锁产生概率；
- 对于非常容易产生死锁的业务部分，可以尝试使用升级锁定颗粒度，通过表级锁定来减少死锁产生的概率；
哲学家进餐问题
哲学家就餐问题可以这样表述，假设有五位哲学家围坐在一张圆形餐桌旁，做以下两件事情之一：吃饭，或者思考。吃东西的时候，他们就停止思考，思考的时候也停止吃东西。而每个哲学家的左右两边仅有一根筷子，吃饭时，必须同时获得左右两只筷⼦才能吃饭（先获得左边，再获得右边）。
若五位哲学家同时饥饿⽽各⾃拿起了左边的筷⼦，这使五个信号量 chopstick 均为 0，当他们试图去拿起右边的筷⼦时，都将因⽆筷⼦⽽⽆限期地等待下去，即可能会引起死锁。
死锁，饥饿，死循环的区别
-
死锁：各进程互相等待对方手里的资源，导致各进程都阻塞，无法向前推进的现象。
-
饥饿：由于长期得不到想要的资源，某进程无法向前推进的现象。比如：在短进程优先(SPF)算法中，若有源源不断的短进程到来，则长进程将一直得不到处理机，从而发生长进程“饥饿”，甚至会导致长进程“饿死”。
-
死循环：某进程执行过程中一直跳不出某个循环的现象。有时是因为程序逻辑bug导致的，有时是程序员故意设计的。
共同点：都是进程无法顺利向前推进的现象(故意设计的死循环除外)
死锁产生的必要条件
产生死锁必须同时满足一下四个条件，只要其中任一条件不成立，死锁就不会发生。
-
互斥条件：只有对必须互斥使用的资源的争抢才会导致死锁(如哲学家的筷子、打印机设备)。像内存、扬声器这样可以同时让多个进程使用的资源是不会导致死锁的(因为进程不用阻塞等待这种资源)。
-
不剥夺条件：进程所获得的资源在未使用完之前，不能由 其他进程强行夺走，只能主动释放。
-
请求和保持条件：进程已经保持了至少一个资源，但又提出了新的资源请求，而该资源又被其他有，此时请 求进程被阻塞，但又对自己已有的资源保持不放。
-
循环等待条件：存在一种进程资源的循环等待链，链中的每一个进程已获得的资源同时被下一个进程所请求。
注意！发生死锁时一定有循环等待，但是发生循环等待时未必死锁（循环等待是死锁的必要不充分条件）
如果同类资源数大于1，则即使有循环等待，也未必发生死锁。但如果系统中每类资源都只有一个，那循环等待就是死锁的充分必要条件了。
什么时候会发生死锁
- 对系统资源的竞争。各进程对不可剥夺的资源(如打印机)的竞争可能引起死锁，对可剥夺的资源(CPU)的竞争是不会引起死锁的。
- 进程推进顺序非法。请求和释放资源的顺序不当，也同样会导致死锁。例如，并发执行的进程P1、P2分别申请并占有了资源R1、R2，之后进程P1又紧接着申请资源R2，而进程P2又申请资源R1，两者会因为申请的资源被对方占有而阻塞，从而发生死锁。
- 信号量的使用不当也会造成死锁。如生产者-消费者问题中，如果实现互斥的P操作在实现同步的P操作之前，就有可能导致死锁。(可以把互斥信号量、同步信号量也看做是一种抽象的系统资源)
总之，对不可剥夺资源的不合理分配，可能导致死锁。
如何预防死锁
破坏互斥条件
互斥条件：只有对必须互斥使用的资源的争抢才会导致死锁将临界资源改造为可共享使用的资源(如SPOOLing技术)
缺点：可行性不高，很多时候无法破坏互斥条件
破坏不剥夺条件
不剥夺条件：进程所获得的资源在未使用完之前，不能被其他进程强行夺走，只能主动释放
方案一，申请的资源得不到满足时，立即释放拥有的所有资源破坏不剥夺条件
方案二，申请的资源被其他进程占用时，由操作系统协助剥夺(考虑优先级）
缺点：实现复杂；剥夺资源可能导致部分工作失效；反复申请和释放导致系统开销大；可能导致饥饿
破坏请求和保持条件
运行前分配好所有需要的资源，之后一直保持
缺点：资源利用率低；可能导致饥饿
破坏循环等待条件
给资源编号，必须按编号从小到大的顺序申请资源
缺点：不方便增加新设备；会导致资源浪费；用户编程麻烦
什么是安全序列
所谓安全序列，就是指如果系统按照这种序列分配资源，则每个进程都能顺利完成。只要能找出一个安全序列，系统就是安全状态。当然，安全序列可能有多个。
如果分配了资源之后，系统中找不出任何一个安全序列，系统就进入了不安全状态。这就意味着之后可能所有进程都无法顺利的执行下去。当然，如果有进程提前归还了一些资源，那系统也有可能重新回到安全状态，不过我们在分配资源之前总是要考虑到最坏的情况。
如果系统处于安全状态，就一定不会发生死锁。如果系统进入不安全状态，就可能发生死锁(处于不安全状态未必就是发生了死锁，但发生死锁时一定是在不安全状态)
文章到这里就先结束了，这里主要记录了MySQL锁相关的知识点，以后还会持续更新其他的与MySQL相关的知识点和面试题。 以上文章中如果有什么不对的，不合理的地方或需要改进的地方，还请大佬留言指正哦。 制作不易，还望各位大佬多多支持哟~~ 再次谢谢大家
作者：小威要向诸佬学习呀
链接：https://juejin.cn/post/7167153745220861966
来源：稀土掘金
网友评论