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

死锁

死锁是指两个或多个事务在同一资源上相互占用，并请求锁定对方的资源，从而导致恶性循环的现象。 常见的解决死锁的方法

1. 如果不同程序会并发存取多个表，尽量约定以相同的顺序访问表，可以大大降低死锁机会。

2. 在同一个事务中，尽可能做到一次锁定所需要的所有资源，减少死锁产生概率；

3. 对于非常容易产生死锁的业务部分，可以尝试使用升级锁定颗粒度，通过表级锁定来减少死锁产生的概率；

哲学家进餐问题

哲学家就餐问题可以这样表述，假设有五位哲学家围坐在一张圆形餐桌旁，做以下两件事情之一：吃饭，或者思考。吃东西的时候，他们就停止思考，思考的时候也停止吃东西。而每个哲学家的左右两边仅有一根筷子，吃饭时，必须同时获得左右两只筷⼦才能吃饭（先获得左边，再获得右边）。 若五位哲学家同时饥饿⽽各⾃拿起了左边的筷⼦，这使五个信号量 chopstick 均为 0，当他们试图去拿起右边的筷⼦时，都将因⽆筷⼦⽽⽆限期地等待下去，即可能会引起死锁。

死锁，饥饿，死循环的区别

死锁、饥饿、死循环的区别 死锁：各进程互相等待对方手里的资源，导致各进程都阻塞，无法向前推进的现象。 饥饿：由于长期得不到想要的资源，某进程无法向前推进的现象。比如：在短进程优先(SPF)算法中，若有源源不断的短进程到来，则长进程将一直得不到处理机，从而发生长进程“饥饿”，甚至会导致长进程“饿死”。 死循环：某进程执行过程中一直跳不出某个循环的现象。有时是因为程序逻辑bug导致的，有时是程序员故意设计的。 共同点：都是进程无法顺利向前推进的现象(故意设计的死循环除外)

死锁产生的必要条件

产生死锁必须同时满足一下四个条件，只要其中任一条件不成立，死锁就不会发生。 互斥条件：只有对必须互斥使用的资源的争抢才会导致死锁(如哲学家的筷子、打印机设备)。像内存、扬声器这样可以同时让多个进程使用的资源是不会导致死锁的(因为进程不用阻塞等待这种资源)。 不剥夺条件：进程所获得的资源在未使用完之前，不能由 其他进程强行夺走，只能主动释放。 请求和保持条件：进程已经保持了至少一个资源，但又提出了新的资源请求，而该资源又被其他有，此时请 求进程被阻塞，但又对自己已有的资源保持不放。 循环等待条件：存在一种进程资源的循环等待链，链中的每一个进程已获得的资源同时被下一个进程所请求。 注意！发生死锁时一定有循环等待，但是发生循环等待时未必死锁（循环等待是死锁的必要不充分条件） 如果同类资源数大于1，则即使有循环等待，也未必发生死锁。但如果系统中每类资源都只有 一个，那循环等待就是死锁的充分必要条件了。

什么时候会发生死锁

1.对系统资源的竞争。各进程对不可剥夺的资源(如打印机)的竞争可能引起死锁，对可剥夺的资源(CPU)的竞争是不会引起死锁的。 2.进程推进顺序非法。请求和释放资源的顺序不当，也同样会导致死锁。例如，并发执行的进程P1、 P2分别申请并占有了资源R1、R2，之后进程P1又紧接着申请资源R2，而进程P2又申请资源R1，两者会因为申请的资源被对方占有而阻塞，从而发生死锁。 3. 信号量的使用不当也会造成死锁。如生产者-消费者问题中，如果实现互斥的P操作在实现同步的 P操作之前，就有可能导致死锁。(可以把互斥信号量、同步信号量也看做是一种抽象的系统资 源) 总之，对不可剥夺资源的不合理分配，可能导致死锁。

如何预防死锁

1. 破坏互斥条件 互斥条件：只有对必须互斥使用的资源的争抢才会导致死锁 将临界资源改造为可共享使用的资源(如SPOOLing技术) 缺点：可行性不高，很多时候无法破坏互斥条件
2. 破坏不剥夺条件 不剥夺条件：进程所获得的资源在未使用完之前，不能被其他进程强行夺走，只能主动释放 方案一，申请的资源得不到满足时，立即释放拥有的所有资源破坏不剥夺条件 方案二，申请的资源被其他进程占用时，由操作系统协助剥夺(考虑优先级） 缺点：实现复杂；剥夺资源可能导致部分工作失效；反复申请和释放导致系统开销大；可能导致饥饿
3. 破坏请求和保持条件 运行前分配好所有需要的资源，之后一直保持 缺点：资源利用率低；可能导致饥饿
4. 破坏循环等待条件 给资源编号，必须按编号从小到大的顺序申请资源 缺点：不方便增加新设备；会导致资源浪费；用户编程麻烦

什么是安全序列

所谓安全序列，就是指如果系统按照这种序列分配资源，则每个进程都能顺利完成。只要能找出一个安全序列，系统就是安全状态。当然，安全序列可能有多个。 如果分配了资源之后，系统中找不出任何一个安全序列，系统就进入了不安全状态。这就意味着之后可能所有进程都无法顺利的执行下去。当然，如果有进程提前归还了一些资源，那系统也有可能重新回到安全状态，不过我们在分配资源之前总是要考虑到最坏的情况。 **

如果系统处于安全状态，就一定不会发生死锁。如果系统进入不安全状态，就可能发生死锁(处于不安全状态未必就是发生了死锁，但发生死锁时一定是在不安全状态)

文章到这里就先结束了，这里主要记录了MySQL锁相关的知识点，以后还会持续更新其他的与MySQL相关的知识点和面试题。 以上文章中如果有什么不对的，不合理的地方或需要改进的地方，还请大佬留言指正哦。 制作不易，还望各位大佬多多支持哟~~ 再次谢谢大家