mysql死锁了会一直在吗？
当MySQL发生死锁时，系统会自动检测到并尝试解锁，但如果解锁失败，它将一直停留在死锁状态，直到手动干预解锁。
在这种情况下，我们需要通过查看mysql错误日志，分析死锁原因并手动解锁。在实际应用中，我们应该避免死锁的发生，可以通过合理的数据库设计和优化查询语句等方式来尽量减少死锁的概率。
mysql死锁的原因面试题？
产生原因：
所谓死锁<DeadLock>：是指两个或两个以上的进程在执行过程中,因争夺资源而造成的一种互相等待的现象,若无外力作用，它们都将无法推进下去.此时称系统处于死锁状态或系统产生了死锁，这些永远在互相等待的进程称为死锁进程。表级锁不会产生死锁.所以解决死锁主要还是针对于最常用的InnoDB。
死锁的关键在于：两个(或以上)的Session加锁的顺序不一致。
那么对应的解决死锁问题的关键就是：让不同的session加锁有次序
mysql使用悲观锁需要设置什么？
使用悲观锁set autocommit ＝0这个肯定是必须的！
先来看下什么是悲观锁？悲观锁就是对数据操作持悲观态度，为了防止数据并发时候对数据一致性的影响，对操作的数据进行加锁的策略，通常为数据库锁级别！
怎么使用数据库悲观锁呢？
首先查询语句为类似于select *where ID ＝# for update！然后做更新操作，最后使用commit提交事务！在这整个过程中，事务涉及到的数据都处于锁定状态，其余的事务不能进行操作数据！由于舍弃了mysql的自动提交事务机制，改为手动提交，所以需要设置autoCommit ＝0，不然事务分步提交无法保证数据的一致性，失去了锁的意义！
再来对比下乐观锁！
为什么要有乐观锁？悲观锁严重的影响了数据库性能的最大化，同时，使用数据库锁实现的悲观锁有很大的可能会有较长的事务锁定期，影响并发环境中的访问速度，而乐观锁是在数据确认提交的时候才对数据进行检测如果发现冲突，由用户本身自己去处理冲突，可以说是业余端自己实现的锁机制！
怎么使用乐观锁？
一般在需要加锁的数据上使用时间戳或者数据版本来控制数据的安全！
具体如下:比如说加版本version，事务一获取到数据的时候version为1，事务二获取到的时候也为1，但是，事务二优先修改了version变为version ＋1＝2！这个时候事务一提交了，sql语句类似为update ....where version ＝#{version}，但此时的版本已经变为2了，也就是说事务一的版本是过期的了，事务一的提交被驳回由程序进行处理！这样来看每次的version修改都由一个事务提交，不会有数据的重复等问题！！使用时间戳的原理相同！
乐观锁在一定程度上，释放了数据库的性能，把数据一致性控制在业务代码中，有了更大的灵活性！
更多的技术分享，敬请持续关注。。。
使用什么锁是根据隔离级别和不同表加索引的情况来确定的。
例如：
主键:索引上锁，数据行上锁
唯一索引:索引上锁，数据行上锁
普通索引:会锁住所有符合条件的索引和行，还会上间隙锁
无索引:会锁全表，逐渐释放不符合条件的锁
因此要尽可能只锁需要的行，避免不同事务锁住互相需要的行，造成死锁。
还没有评论，来说两句吧...