金三银四面试题（十九）：MySQL中的锁

2024-04-10 14:14:01
开发
13

在MySQL中，锁是非常重要的，特别是在多用户并发访问数据库的环境中，因此也是面试中常问的话题。

请说说数据库的锁？

关于MySQL 的锁机制，可能会问很多问题，不过这也得看面试官在这方面的知识储备。
MySQL 中有共享锁和排他锁，也就是读锁和写锁。

共享锁：不堵塞，多个用户可以同一时刻读取同一个资源，相互之间没有影响。
排他锁：一个写操作阻塞其他的读锁和写锁，这样可以只允许一个用户进行写入，防止其他
用户读取正在写入的资源。
表锁：系统开销最小，会锁定整张表，MyISAM 使用表锁。
行锁：容易出现死锁，发生冲突概率低，并发高，InnoDB 支持行锁（必须有索引才能实现，
否则会自动锁全表，那么就不是行锁了）。

说说什么是锁升级？

行锁只能加在索引上：
MySQL的InnoDB存储引擎使用的是行级锁。当对表中的某一行进行操作（如更新或删除）时，InnoDB会尝试在该行上加锁以确保数据的一致性。然而，这种行级锁只能加在索引上。因为InnoDB使用B+树来组织索引，而行数据存储在索引的叶子节点中。因此，要锁定某行数据，必须先定位到该行所在的索引，然后在该索引上加锁。
不走索引会升级为表锁：
如果执行的操作不走索引，而是对整个表或者大部分行进行扫描，MySQL无法定位到要加锁的行所在的索引，因此无法使用行级锁。这时，MySQL会将锁升级为表级锁，以确保操作的原子性和一致性。表级锁会锁定整个表，会对并发性能造成较大的影响，因为其他事务需要等待锁释放才能进行操作。
InnoDB的索引结构和行锁原理：
InnoDB在B+树的叶节点上同时保存了索引键值和相应的行数据。这意味着，当通过索引查找行数据时，可以直接定位到叶子节点，而不需要再次查找数据行，从而提高了查询效率。因此，InnoDB一定会有一个主键索引（primary key index），而其他辅助索引（secondary index）也是通过找到对应的主键值来进一步定位到相应的数据行。这也是为什么只有在索引上加锁才能使用行级锁的原因。
当非唯一索引上记录数超过一定数量时，行锁也会升级为表锁。测试发现当非唯一索引相同的内容不少于整个表记录的二分之一时会升级为表锁。因为当非唯一索引相同的内容达到整个记录的二分之一时，索引需要的性能比全文检索还要大，查询语句优化时会选择不走索引，造成索引失效，行锁自然就会升级为表锁。

说说悲观锁和乐观锁

悲观锁

说的是数据库被外界（包括本系统当前的其他事物以及来自外部系统的事务处理）修改保持着保守态度，因此在整个数据修改过程中，将数据处于锁状态。悲观的实现往往是依靠数据库提供的
锁机制，也只有数据库层面提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统汇总实现了加锁机制，也是没有办法保证系统不会修改数据。在悲观锁的情况下，为了保证事务的隔离性，就需要一致性锁定。读取数据时给加锁，其他事务无法修改这些数据。修改删除数据时也要加锁，其他事务无法读取这些数据。

乐观锁

相对悲观锁而言，乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。而乐观锁机制在一定程度上解决了这个问题。乐观锁，大多是基于数据版本（Version）记录机制
实现。何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个“version”字段来实现。读取出数据时，将此版本号一同读出，之后更新
时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。

怎样尽量避免死锁的出现？

设置获取锁的超时时间，至少能保证最差情况下，可以退出程序，不至于一直等待导致死锁；
设置按照同一顺序访问资源，类似于串行执行；
避免事务中的用户交叉；
保持事务简短并在一个批处理中；
使用低隔离级别；
使用绑定链接。

在这里插入图片描述

原文地址:https://blog.csdn.net/weixin_45700531/article/details/137591642 本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：https://www.suanlizi.com/kf/1777943095346860032.html 如若内容造成侵权/违法违规/事实不符，请联系《酸梨子》网邮箱：1419361763@qq.com进行投诉反馈，一经查实，立即删除！

阅读全部