MySQL中的锁机制用于管理并发访问数据库，防止数据一致性问题

MySQL中的锁机制用于管理并发访问数据库，防止数据一致性问题

引用

CSDN

1.

https://blog.csdn.net/blog_programb/article/details/144560274

MySQL中的锁机制用于管理并发访问数据库，防止数据一致性问题。本文将详细介绍MySQL不同版本的锁行为差异、不同粒度的锁（表级、页级、行级）、如何查看锁定状态、死锁现象及其解决方案等内容。

MySQL中的锁机制用于管理并发访问数据库，防止数据一致性问题。在不同的MySQL版本和粒度下，锁有不同的行为：

MySQL 5.7及之前的版本

• 如果尝试获取锁而失败，MySQL会进入阻塞模式，直到锁定资源可用或达到innodb_lock_wait_timeout设置的超时时间。这保证了事务的串行化执行，但可能增加延迟。

MySQL 8.0及以上

• 提供了NOWAIT和SKIP LOCKED选项来改变行为。NOWAIT会使查询立即失败并返回错误，而不等待；SKIP LOCKED则忽略已锁定的行，仅返回未锁定的行。

数据操作粒度

• 表级锁（如共享锁（S）和独占锁（X））对整个表进行锁定，影响范围大但效率低。
• 页级锁（InnoDB引擎特有的）锁定的是数据页，提高并发性能，但可能会导致热点页竞争。
• 行级锁（行共享锁（S）和行exclusive锁（X））是最细粒度的锁定方式，每个事务只能锁住一行或多行，提高了并发读取能力，但写入时存在死锁风险。

行级锁示例

要查看当前系统的锁定状态，你可以运行如下SQL：

SELECT object_schema, object_name, index_name, lock_type, lock_mode, lock_data 
FROM performance_schema.data_locks;

这将显示锁定的对象（表名和索引）、锁定类型（行锁或意向锁）、锁定模式以及锁定的具体信息。

死锁现象

MySQL中的死锁现象是指两个或更多个事务因为互相等待对方释放已经持有的资源而陷入一种僵局，每个事务都在等待对方先完成操作。这种情况通常发生在以下场景：

1. 资源竞争与顺序依赖：事务A锁定表A并开始读写，这时事务B也试图锁定表A并且对表A进行修改。由于事务A尚未完成，B无法继续，于是它去锁定另一个表B。接着，事务A发现B正在等待它的资源，于是也进入等待状态。
2. 锁定策略：MySQL使用的是悲观锁定，即在操作开始时就尽可能多地获取可能需要的锁，这可能导致不同事务之间形成互斥的锁，进而引发死锁。

解决死锁的方法

1. 避免资源的循环等待：如在设计应用程序时，建议事务按照固定的顺序访问数据库资源，减少死锁的可能性。
2. 一次性锁定所需的全部资源：在一个事务内部，如果可能，应尽快获取所有必要的锁，避免其他事务加入到等待队列。
3. 升级锁定粒度：如果某个事务只需要对整个表进行操作，可以选择表级锁定而不是行级锁，这样可以减少冲突。
4. 使用分布式事务锁或乐观锁：在某些情况下，可以采用分布式锁管理机制，或者利用乐观锁（如行版本号）来避免死锁的发生。

死锁的检测和解除通常是数据库管理系统自动处理的，但在复杂的应用场景下，程序员也需要理解和监控系统的死锁行为。

MySQL死锁检测机制

MySQL中的死锁现象确实涉及到事务之间的相互等待。当两个或更多的事务各自持有部分锁定的资源，并尝试进一步锁定其他事务正在等待的资源时，就会形成死锁。这种情况下，每个事务都无法继续执行，因为它们都在等待对方先释放资源。

MySQL通过其内部的wait-for graph算法来检测和解决死锁。该算法运行时，它会收集两个关键信息：

1. 锁的信息链表：记录当前哪些事务持有特定的锁以及这些锁的所有者。
2. 事务等待链表：跟踪每个阻塞事务等待的锁及其对应的目标事务。

一旦检测到死锁，MySQL会采取干预措施。具体来说，它会选择一个"死锁的参与者"（通常是事务中活跃时间最长的一个），强制回滚这个事务以释放已持有的资源。这样，其他的事务就可以继续执行，从而打破死锁的循环。这是通过InnoDB引擎实现的，默认策略是回滚最近提交的一次事物来避免死锁升级。

相关问题

1. MySQL如何防止死锁的发生？
2. 回滚事务是如何解除死锁的？
3. 如何查看MySQL是否发生过死锁事件？

本文原文来自CSDN