InnoDB的锁机制原理，通俗易懂

原创 已于 2025-06-24 11:44:59 修改 · 797 阅读 · 30 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#mysql #InnoDB

于 2025-06-24 09:59:35 首次发布

InnoDB的锁机制原理

一、知识回顾

MySQL 的锁机制是其实现并发控制的核心，用于保证数据的一致性和完整性。锁可以从多个维度进行分类，最常见的是根据锁的粒度（范围）、锁的模式（行为） 以及 锁的兼容性 来划分。以下是主要的分类：

1. 按锁的模式（行为/兼容性）分类

  1. 共享锁（Shared Lock , S Lock）

    • 行为：又称读锁，允许其他事务同时读取被锁定的资源（数据行，表）,但不允许其他事务获取该资源的排他锁 （即阻止其他事务写入）

    • 兼容性： 多个事务可以同时持有同一资源上的共享锁。

    • 加锁方式：

      ​ SELECT ... LOCK IN SHARE MODE (显式)

      ​ SELECT ... FOR SHARE (MySQL 8.0+ 语法，更推荐)

  2. 排他锁 （Exclusive Lock, X Lock）

    • 行为：又称写锁，阻止其他事务同时读取被锁定的资源（数据行，表），即阻止其他事务读取（脏读除外）和写入。

    • 兼容性： 同一时间只有一个事务能持有某个资源的排他锁

    • 加锁方式：

      ​ SELECT ... LOCK FOR UPDATE (显式)

      ​ UPDATE, DELETE, INSERT 语句在操作涉及的行上会自动加排他锁（隐式）

2. 按锁的粒度（范围）分类

  1. 全局锁：

  • 作用范围： 锁定整个 MySQL 实例的所有数据库。

  • **命令：**FLUSH TABLES WITH READ LOCK

  • 效果： 使整个实例处于只读状态。所有数据修改操作（DML）和表结构修改操作（DDL）都会被阻塞。

  • 用途： 主要用于做全库逻辑备份（如 mysqldump 时使用 --single-transaction 参数通常更好，因为它使用 MVCC 不阻塞写）。非常重量级，会严重影响业务，慎用。

  1. 表级锁：

    表锁（Table Lock）：

    • 作用范围： 锁定整个表
    • 命令： LOCK TABLES table_name [READ | WRITE] (显式锁，一般少用) / MySQL Server 层在某些语句执行时自动加。
    • 读锁（共享锁）： 允许其他会话读该表，但阻塞其他会话写该表（包括加写锁）。
    • 写锁（排他锁）： 阻塞其他会话对该表的所有读写操作（包括加读锁和写锁）。
    • 用途： 主要用于做全库逻辑备份（如 mysqldump 时使用 --single-transaction 参数通常更好，因为它使用 MVCC 不阻塞写）。非常重量级，会严重影响业务，慎用。

    元数据锁（Metadata Lock， MDL）：

    • 作用范围： 保证表结构（元数据）的一致性。当对一个表做 CRUD 操作（DML）时，加 MDL 读锁；当要对表结构做变更（DDL）时，加 MDL 写锁。
    • 命令： 无 ， MySQL Server 层自动管理，无需用户干预。
    • 冲突： MDL 读锁之间不互斥；MDL 写锁与 MDL 读锁、MDL 写锁都互斥。DDL 操作需要等待所有正在执行的 DML 事务释放 MDL 读锁，反之新的 DML 操作会等待 DDL 操作释放 MDL 写锁。长时间未提交的事务持有 MDL 锁可能导致 DDL 操作阻塞甚至拖垮数据库

    意向锁（Intention Lock）：

    • 目的： 表级锁，由 InnoDB 引擎引入，用于快速判断表中是否有更细粒度（行级）的锁存在，避免为了检查行锁而遍历所有行。
    • 意向共享锁（IS）： 表示事务打算在表中的某些行上加共享锁（S Lock）。
    • 意向排他锁（IX）： 表示事务打算在表中的某些行上加排他锁（X Lock）。
    • 兼容性： 意向锁之间相互兼容（IS 和 IX 不互斥），但它们会与普通的表级共享锁（S）和排他锁（X）冲突。

  2. 行级锁：

    • 作用范围： 锁定表中的单行或多行记录。这是 InnoDB 存储引擎 支持且最常用的锁粒度，提供了最高的并发度。

    常见类型（InnoDB 实现）：

    • 记录锁（Record Lock）：

      锁定索引记录本身。如果表没有定义索引，InnoDB 会创建一个隐藏的聚簇索引，记录锁就作用在这个隐藏索引上。

      保证锁定的行不能被其他事务修改或删除。

    • 间隙锁（Gap Lock）：

    ​ 锁定索引记录之间的间隙（开区间），或者第一个索引记录之前或最后一个索引记录之后的间隙。

    ​ 目的： 防止其他事务在间隙中插入新的记录（解决幻读问题的一种手段）。

    ​ 兼容性： 间隙锁之间不冲突（不同事务可以锁定同一个间隙）。

    • 临键锁（Next-Key Lock）：

    ​ 记录锁 + 间隙锁 的组合。锁定一个索引记录以及该记录之前的间隙（左开右闭区间）。

    ​ 目的： InnoDB 默认的行锁算法。既防止了幻读（通过间隙锁部分），又能锁定记录本身（通过记录锁部分）。

    • 插入意向锁（Insert Intention Lock）：

    ​ 特殊的间隙锁。在 INSERT 操作插入行之前设置。

    ​ 目的： 表示一个事务打算在某个间隙中插入新行。多个事务只要插入的位置（间隙）不冲突（即使在同一间隙内插入不同的位置），它们可以同时持有插入意向锁。插入意向锁会等待已有的间隙锁或临键锁释放。

3. 总结汇总如下：

分类维度锁类型描述主要实现/命令特点/用途
粒度全局锁锁整个实例FLUSH TABLES WITH READ LOCK全库备份，重量级
表级锁锁整张表
- 表锁显式表锁LOCK TABLES ... READ/WRITE读写互斥
- MDL元数据锁自动保护表结构，DML vs DDL
- 意向锁表级意向锁InnoDB 自动指示行锁意图，加速冲突检查
行级锁锁单行或多行InnoDB 特有高并发
- 记录锁锁索引记录UPDATE/DELETE/SELECT FOR UPDATE 等防止修改/删除
- 间隙锁锁索引间隙自动防止插入，解决幻读
- 临键锁记录锁+间隙锁InnoDB 默认行锁算法解决幻读和记录锁定
- 插入意向锁特殊间隙锁INSERT表示在间隙插入意图，等待间隙锁释放
模式/行为共享锁 (S)允许读，阻塞写SELECT ... LOCK IN SHARE MODE / FOR SHARE多个事务可同时持有
排他锁 (X)阻塞读写SELECT ... FOR UPDATE / UPDATE / DELETE独占锁
其他概念乐观锁应用层策略，基于版本号UPDATE ... WHERE version = old_version无锁读，更新时检查版本
悲观锁先获取数据库锁使用 FOR UPDATE 等强一致，可能降低并发
死锁事务循环等待InnoDB 自动检测并回滚一个事务

二、测试表以及数据

主键索引 ID

非唯一索引 real_name

CREATE TABLE `user` (
	`id` BIGINT NOT NULL COMMENT 'id',
	`user_name` VARCHAR(20) NOT NULL COMMENT '姓名' COLLATE 'utf8mb4_bin',
	`mobile` VARCHAR(16) NULL DEFAULT NULL COMMENT '手机号码 联系方式' COLLATE 'utf8mb4_bin',
	`real_name` VARCHAR(20) NOT NULL COMMENT '真实姓名' COLLATE 'utf8mb4_bin',
	`enable` INT NULL DEFAULT '1' COMMENT '0:禁用,1:启用',
	`job_title` VARCHAR(32) NULL DEFAULT NULL COMMENT '职位' COLLATE 'utf8mb4_bin',
	`user_type` VARCHAR(16) NULL DEFAULT NULL COMMENT '用户类型 管理员 ADMIN , 运营 OPERATE， 助教 ASSISTANT, 学校管理员SCHOOL_ADMIN' COLLATE 'utf8mb4_bin',
	`create_at` DATETIME NOT NULL COMMENT '创建时间',
	`create_by` BIGINT NOT NULL COMMENT '创建人',
	`update_at` DATETIME NOT NULL COMMENT '最后修改时间',
	`update_by` BIGINT NOT NULL COMMENT '最后修改人',
	PRIMARY KEY (`id`) USING BTREE,
	INDEX `real_name` (`real_name`) USING BTREE
)
COMMENT='用户表\r\n'
COLLATE='utf8mb4_bin'
ENGINE=InnoDB;

INSERT INTO `user` (`id`, `user_name`, `mobile`, `real_name`, `enable`, `job_title`, `user_type`, `create_at`, `create_by`, `update_at`, `update_by`) VALUES (1, '超管2', '1222', '超管', 1, NULL, 'ADMIN', '2023-05-11 10:02:30', 0, '2023-05-18 11:05:49', 1656479863111929856);
INSERT INTO `user` (`id`, `user_name`, `mobile`, `real_name`, `enable`, `job_title`, `user_type`, `create_at`, `create_by`, `update_at`, `update_by`) VALUES (8, '超管2', '1521317', '王奕值', 1, NULL, 'OPERATE', '2023-05-17 10:24:18', 1656479863111929856, '2023-05-17 10:24:18', 1656479863111929856);
INSERT INTO `user` (`id`, `user_name`, `mobile`, `real_name`, `enable`, `job_title`, `user_type`, `create_at`, `create_by`, `update_at`, `update_by`) VALUES (12, 'zlq', '15213', '张刘四', 1, NULL, 'OPERATE', '2023-05-17 10:24:42', 1656479863111929856, '2023-05-17 10:24:42', 1656479863111929856);
INSERT INTO `user` (`id`, `user_name`, `mobile`, `real_name`, `enable`, `job_title`, `user_type`, `create_at`, `create_by`, `update_at`, `update_by`) VALUES (15, 'sc', '1521', '舒创', 1, NULL, 'OPERATE', '2023-05-17 10:26:25', 1656479863111929856, '2023-05-18 19:38:22', 1656479863111929856);
INSERT INTO `user` (`id`, `user_name`, `mobile`, `real_name`, `enable`, `job_title`, `user_type`, `create_at`, `create_by`, `update_at`, `update_by`) VALUES (16, 'lp', '153198', '李', 1, NULL, 'OPERATE', '2023-05-17 10:43:34', 1656479863111929856, '2023-05-17 10:43:34', 1656479863111929856);
INSERT INTO `user` (`id`, `user_name`, `mobile`, `real_name`, `enable`, `job_title`, `user_type`, `create_at`, `create_by`, `update_at`, `update_by`) VALUES (17, 'apptest', '155789', '刘志', 1, NULL, 'OPERATE', '2023-05-17 17:04:32', 1656479863111929856, '2023-06-20 16:47:25', 1656479863111929856);
INSERT INTO `user` (`id`, `user_name`, `mobile`, `real_name`, `enable`, `job_title`, `user_type`, `create_at`, `create_by`, `update_at`, `update_by`) VALUES (18, 'test3', '1858034', '发送', 1, NULL, 'SCHOOL_ADMIN', '2023-05-17 21:46:40', 1656479863111929856, '2023-06-02 18:35:27', 1656479863111929856);
INSERT INTO `user` (`id`, `user_name`, `mobile`, `real_name`, `enable`, `job_title`, `user_type`, `create_at`, `create_by`, `update_at`, `update_by`) VALUES (19, 'nishishuia', '1858034', '测试坦诚据', 0, NULL, 'SCHOOL_ADMIN', '2023-05-17 21:58:20', 1656479863111929856, '2023-05-18 14:34:18', 1659077948723904512);
INSERT INTO `user` (`id`, `user_name`, `mobile`, `real_name`, `enable`, `job_title`, `user_type`, `create_at`, `create_by`, `update_at`, `update_by`) VALUES (20, 'ggg1', '1858034', '张', 0, NULL, 'ASSISTANT', '2023-05-17 22:01:41', 1656479863111929856, '2023-05-18 14:12:08', 1659077948723904512);
INSERT INTO `user` (`id`, `user_name`, `mobile`, `real_name`, `enable`, `job_title`, `user_type`, `create_at`, `create_by`, `update_at`, `update_by`) VALUES (21, 'test2', '', '弹弹弹ddd', 1, NULL, 'ASSISTANT', '2023-05-17 23:00:55', 1656479863111929856, '2023-06-05 16:06:50', 1656479863111929856);
INSERT INTO `user` (`id`, `user_name`, `mobile`, `real_name`, `enable`, `job_title`, `user_type`, `create_at`, `create_by`, `update_at`, `update_by`) VALUES (22, 'clh', '', 'c', 1, NULL, 'OPERATE', '2023-05-18 14:06:22', 1656479863111929856, '2023-05-19 15:52:56', 1656479863111929856);
INSERT INTO `user` (`id`, `user_name`, `mobile`, `real_name`, `enable`, `job_title`, `user_type`, `create_at`, `create_by`, `update_at`, `update_by`) VALUES (23, 'ff333', '', '发光时代dd', 1, NULL, 'OPERATE', '2023-05-18 19:34:32', 1656479863111929856, '2023-05-18 20:07:23', 1656479863111929856);
INSERT INTO `user` (`id`, `user_name`, `mobile`, `real_name`, `enable`, `job_title`, `user_type`, `create_at`, `create_by`, `update_at`, `update_by`) VALUES (24, 'hgh', '', '1', 1, NULL, 'ASSISTANT', '2023-05-18 19:36:47', 1656479863111929856, '2023-06-02 10:58:33', 1656479863111929856);
INSERT INTO `user` (`id`, `user_name`, `mobile`, `real_name`, `enable`, `job_title`, `user_type`, `create_at`, `create_by`, `update_at`, `update_by`) VALUES (25, 'tcj', '18888888', '谭', 1, NULL, 'OPERATE', '2023-05-18 19:44:31', 1656479863111929856, '2023-05-22 17:49:23', 1659163048132145152);
INSERT INTO `user` (`id`, `user_name`, `mobile`, `real_name`, `enable`, `job_title`, `user_type`, `create_at`, `create_by`, `update_at`, `update_by`) VALUES (26, 'xuexiao', '', 'xuexiaohghfghfg', 1, NULL, 'SCHOOL_ADMIN', '2023-05-21 14:54:35', 1656479863111929856, '2023-05-21 18:53:04', 1656479863111929856);
INSERT INTO `user` (`id`, `user_name`, `mobile`, `real_name`, `enable`, `job_title`, `user_type`, `create_at`, `create_by`, `update_at`, `update_by`) VALUES (27, 'chaoge', '138831', 'chaoge', 1, NULL, 'ASSISTANT', '2023-05-22 16:18:56', 1656479863111929856, '2023-05-26 12:40:43', 1656479863111929856);
INSERT INTO `user` (`id`, `user_name`, `mobile`, `real_name`, `enable`, `job_title`, `user_type`, `create_at`, `create_by`, `update_at`, `update_by`) VALUES (28, 'tant', '', '谭123', 1, NULL, 'ASSISTANT', '2023-05-22 17:54:04', 1656479863111929856, '2023-05-22 20:26:45', 1656479863111929856);
INSERT INTO `user` (`id`, `user_name`, `mobile`, `real_name`, `enable`, `job_title`, `user_type`, `create_at`, `create_by`, `update_at`, `update_by`) VALUES (29, 'tantest', '1858888', '谭测试', 1, NULL, 'ASSISTANT', '2023-06-02 17:46:49', 1656479863111929856, '2023-06-05 14:08:21', 1656479863111929856);
INSERT INTO `user` (`id`, `user_name`, `mobile`, `real_name`, `enable`, `job_title`, `user_type`, `create_at`, `create_by`, `update_at`, `update_by`) VALUES (30, 'tancj', '333', '非凡', 1, NULL, 'ASSISTANT', '2023-06-09 12:30:42', 1656479863111929856, '2023-06-09 12:32:52', 1656479863111929856);

1 非唯一索引执行流程如下：

是
否
是
否
事务A:更新操作
使用索引?
在索引上加Next-Key Lock
在索引后间隙加Gap Lock
在主键加记录锁
全表Next-Key Lock
事务B:插入操作
索引值是否在锁定区间?
阻塞
允许
1.非唯一索引且数据存在：

步骤1：开启事务

##real_name非唯一索引,数据存在
BEGIN;
UPDATE  user SET user_name='超管2' WHERE real_name = '王奕值2';

步骤2：查询加锁情况

performance_schema.data_locks 表有详细的统计

执行SQL: SELECT * FROM performance_schema.data_locks; 结果如下：

查询结果

我们重点关注 LOCK_MODE,LOCAK_DATA字段,可以看到 同时添加了 临键锁（X），间隙锁( X,GAP), 记录锁（X,REC_NOT_GAP）,表级锁(IX)

锁信息解读

  1. 表级锁：
    • TABLE; IX; GRANTED：意向排他锁，表示事务准备修改表中的某些行
  2. 非唯一索引锁(real_name)：
    • RECORD; X; GRANTED; '王奕值', 8：Next-Key Lock（临键锁），锁定索引记录和间隙
    • RECORD; X,GAP; GRANTED; '舒创', 15：间隙锁，锁定索引值之间的区间
  3. 主键索引锁：
    • RECORD; X,REC_NOT_GAP; GRANTED; 8：记录锁，仅锁定主键id=8的行

为什么需要三种锁？

  1. Next-Key Lock：
    • 防止其他事务修改当前找到的记录（id=8）
    • 防止在记录前插入新值（保持当前记录的"前间隙"不变）
  2. Gap Lock：
    • 防止在 '王奕值' 和 '舒创' 之间插入新记录
    • 避免幻读（Phantom Read）
    • 保证在事务期间执行相同查询会返回一致结果
  3. 主键记录锁：
    • 确保实际数据行的独占访问
    • 允许安全地更新行数据

对并发操作的影响

操作类型示例是否被阻塞原因
插入操作INSERT ... real_name='王奕值'✅ 阻塞被Next-Key Lock和Gap Lock阻止
更新相同行UPDATE ... WHERE id=8✅ 阻塞主键记录锁(X,REC_NOT_GAP)
更新其他行UPDATE ... WHERE id=15❌ 允许不影响其他行
读操作SELECT ...❌ 允许快照读不受影响
范围查询SELECT ... FOR UPDATE WHERE real_name>'A'✅ 部分阻塞可能冲突的区间被阻塞

步骤3：有了上面的理论基础，我们来验证，开启事务B

事务A先不提交，然后开启事务B

验证更新相同的行：结果阻塞，等待事务超时，截图如下：

在这里插入图片描述

验证更新其他行：执行成功，未阻塞，截图如下：

在这里插入图片描述

这里可能有同学会问，这个间隙锁（开区间）加锁的区间是怎么样的，而且本文的索引内容是中文，肉眼也没法判断，这里超哥给大家一个判断区间的方法，在上面的例子中，查询锁信息间隙锁显示为 '舒创', 15，那么可以用sql来计算SQL如下：

SELECT 
  real_name,
  id,
  CASE 
    WHEN real_name < '舒创' THEN '在区间前'
    WHEN real_name = '舒创' THEN '边界值'
    ELSE '在区间后'
  END AS position
FROM user
ORDER BY real_name;

结果如下：

real_nameidposition
124在区间前
c22在区间前
chaoge27在区间前
xuexiaohghfghfg26在区间前
刘志17在区间前
发光时代dd23在区间前
发送18在区间前
张20在区间前
张刘四12在区间前
弹弹弹ddd21在区间前
李16在区间前
测试坦诚据19在区间前
王奕值8在区间前
舒创15边界值
谭25在区间后
谭12328在区间后
谭测试29在区间后
超管1在区间后
非凡30在区间后

则锁定区间为： （王奕值,舒创 ），如果插入王奕值1则会阻塞

BEGIN;
INSERT INTO `user` (`id`, `user_name`, `mobile`, `real_name`, `enable`, `job_title`, `user_type`, `create_at`, `create_by`, `update_at`, `update_by`) VALUES (32, '超管', '12222222222', '王奕值1', 1, NULL, 'ADMIN', '2023-05-11 10:02:30', 0, '2023-05-18 11:05:49', 1656479863111929856);
COMMIT;
1063420481
关注
5、InnoDB引擎原理和实战，通俗易懂
细致-专业-实操
02-23 778
1. 缓冲池 1.2 默认引擎 1.3 设置缓冲池大小 1.4 优化缓冲池 1.5 管理缓冲池 1.7 数据页类型 2. 线程 2.1 IO线程 2.2 主线程 3. index page 4. insert buffer page 5. 重做日志 6. 回滚日志 7. checkpoint，刷写脏页check point 8. 关键特性 8.1 插入缓冲 8.2 数据写入可靠性提升技术-doublewrite 8.3 自适应哈希索引-AHI
最全、最通俗易懂的Java面试题积累【一】
WLK0423的博客
01-21 1213
1.String和StringBuilder和StringBuffer的区别 答： String：是不可变得字符序列，底层是’private final char’ StringBuilder：可变字符序列，效率低，但是线程安全 StringBuffer：可变字符序列，效率较高，但是线程不安全 2.String为什么不可变StringBuilder为什么可变 从String类的源码中可以看到，String是通过char value[]保存字符的。而且声明为private final，并且不提供我们写valu
InnoDB锁机制全解析
Gopher
09-21 1093
InnoDB是MySQL数据库的默认存储引擎，它提供了多种锁机制来保证数据的一致性和完整性。
InnoDB的七种锁
08-22
(1)自增锁(Auto-inc Locks) (2)共享/排它锁(Shared and Exclusive Locks) (3)意向锁(Intention Locks) (4)插入意向锁(Insert Intention Locks) (5)记录锁(Record Locks) (6)间隙锁(Gap Locks) (7)临键锁(Next-key Locks)
InnoDB 锁机制
pointer_future的专栏
06-10 405
1. Locking Read 示例 场景一 (for share): 假设想要在一个名叫 child 的表中插入新 row, 前提要确保在名叫 parent 的表中包含一个 parent row. 想要确保引用的完整性, 可以按照如下步骤组织代码: 首先, 不能使用 noblocking read 读取 parent row 的方式, 检查 parent row 是否存在. 因为其他的事务可能在你 select 和 insert 操作之间, 把 parent row 删除了. 而你这个事务却意识不到
MySQL innodb的锁机制解读
weixin_30808693的博客
06-30 180
网上有许多关于innodb的锁机制的文章，有许多文章讲述的不明白或者有问题，最近研究了好久，结合网上资料和实践操作，记录一下，供大家参考。如果有不对的地方，请随时留言。 一 Innodb具备的锁种类 1. 表锁（MySQL提供的，跟存储引擎无关） 2. 行锁（Innodb存储引擎实现） 二 Innodb内部实现的锁种类 1. 记录锁 对应Innodb的行锁，记录锁锁的是索引记录，不是具...
Innodb行锁源码学习(一)
weixin_34148508的博客
01-28 180
      Innodb是mysql数据库中目前最流行的存储引擎，innodb相对其它存储引擎一个很大的特点是支持事务，并且支持行粒度的锁。今天我重点跟大家分享下innodb行锁实现的基础知识。由于篇幅比较大，文章会按如下的目录结构展开。 {　　innodb锁结构　　锁机制关键流程　　innodb行锁开销　　innodb锁同步机制　　innodb等待事件实现} 先从一个简单的例子说起，如下表1...
innodb锁
xxq929604980的博客
11-16 823
数据库开发最核心的要解决的问题是并发和锁(即数据一致性问题) 不同存储引擎的锁粒度不同，innodb是行级别锁，mysiam是表级锁，还有些支持页锁。、
MySql索引算法原理解析（通俗易懂，只讲B-tree）
08-11
MySQL数据库在数据存储和检索中，索引是一种关键机制，极大地提高了查询效率。本文主要讲解的是MySQL中的B树（B-tree）索引算法原理，它是最常见的一种索引类型，适用于大多数情况。B树索引是数据库管理系统实现高效...
InnoDB为什么使用B+树实现索引？要求说明通俗易懂，有图解
最新发布
08-10
嗯，用户这次的问题很明确，就是要深入理解InnoDB选择B+树作为索引结构的原因，而且特别强调要通俗易懂带图解。看来用户可能是个数据库学习者或开发者，需要直观的理解而非纯理论。 从对话历史看，我之前已经详细...
数据库锁机制的原理是什么
02-27
同时，语言要通俗易懂，适合不同层次的读者理解。数据库锁机制是确保数据一致性与事务隔离性的核心技术，其原理可通过以下六个层面逐步解释： 1. **基本作用原理** 当事务A访问数据时，系统会像在图书馆借书一样给...
InnoDB引擎下的锁机制
qq_51210847的博客
03-05 540
InnoDB引擎下的锁机制：全局锁、表锁、行级锁、意向锁、读锁、排他锁（写锁）
数据库概述09（数据库中的锁机制）
weixin_44251806的博客
10-12 452
锁机制
MySQL InnoDB 的锁机制
tatasix的博客
12-11 1609
本文将深入探讨InnoDB锁机制的实现原理、各类锁的特性及其在实际应用中的最佳实践。具体包括悲观锁与乐观锁、系统锁、表锁、行锁、意向锁、Gap 锁、 Next-Key 锁、元数据等等。
innodb锁机制
qq_45313714的博客
09-17 436
innodb中的锁机制原理解析 1.共享锁 S锁，读锁，多个事务共享一把锁，都能访问到数据，只读，不可修改。A 在读，B可读，但是不可写。 select * from count where id = 1 lock on share mode； 2.排他锁 X锁，写锁，不能与其他锁并存。只有当获取排他锁的事务处理完后，其 他操作方可进行。updata 自动加排他锁 -语句后加for update innodb行锁？锁的是什么？ 行锁就是给索引项加锁 ，否则就是表锁。 3.意向共享锁 IS： 表示事务准备给
Innodb的行锁的实现原理
Apple_Andy的博客
09-27 2676
一.innodb行锁的实现 1.innodb的行锁是通过给索引的索引项加锁来实现的 2.innodb按照辅助索引进行数据操作时,辅助索引和主键索引都将锁定指定的索引项 3.通过索引进行数据检索时,innodb才使用行级锁,否则innodb将使用表锁 二.举例说明 1.这边有一张表,id为主键,name为普通字段 2.当用主键id来进行数据检索时,其余行仍然可以操作 3.另一个线程仍然可以操作id=1的数据,因为它只锁住了id=6这一列 4.当用非索引的字段来进行数据检索时,此时会升级为表锁,其余列就不
Innodb 行锁实现原理
程序猿进阶
11-20 1786
Innodb的行锁是通过给索引的索引项加锁来实现的
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值