InnoDB中的锁-意向锁

本文详细解析InnoDB数据库的意向锁机制,探讨IS与IX、X与IX、IS与IX之间的冲突案例,并解释了如何支持多粒度锁共存。通过实验演示,揭示了意向锁在行级与表级锁判断中的作用。

锁列表

  • 共享与列排他锁
  • 意向锁
  • 记录锁
  • 间隙锁
  • Next-Key锁
  • 插入意向锁
  • AUTO-INC锁

这次我们只来讨论和实验意向锁。

意向锁

InnoDB意向锁是为了支持多粒度锁共存而设计的,意向锁是一种特殊的行锁。在取得行锁之前需要先获取表的意向锁。
意向锁分为两类:意向共享锁和意向排他锁:

  • 意向共享锁IS:表示事务想要对表中的行设置共享锁。
  • 意向排他锁IX:表示事务想要对表中行设置排他锁。

意向锁主要是辅助表级和行级锁冲突的判断,因为InnoDB支持行级锁,如果没有意向锁,那么判断表级锁和行级锁冲突就需要遍历所有行的行锁,有了意向锁就可以直接判断意向锁是否存在就可以判断是否有行锁了。

意向锁兼容性

在这里插入图片描述

实验

X与IX冲突

事务A:先将表中的行设置一个IX锁,事务不提交

begin;
select * from sys_user where id=17 for update;

事务B:然后执行SQL

begin;
update sys_user set name_pinyin='wangwu1' where id=17;

事务B回滚:

MySQL [employees]> update sys_user set name_pinyin='wangwu1' where id=17;
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
MySQL [employees]> 

show engine innodb status输出:

---TRANSACTION 126451825, ACTIVE 40 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 1136, 1 row lock(s)
MySQL thread id 93, OS thread handle 139734682273536, query id 94962 192.168.1.83 root updating
update sys_user set name_pinyin='wangwu1' where id=17
------- TRX HAS BEEN WAITING 40 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 484 page no 7 n bits 328 index PRIMARY of table `employees`.`sys_user` trx id 126451825 lock_mode X locks rec but not gap waiting
Record lock, heap no 257
------------------

X与IS冲突

事务A:先将表中的行设置一个IS锁,事务不提交

begin;
select * from sys_user where id=17 for share;

事务B:然后执行SQL

begin;
update sys_user set name_pinyin='wangwu1' where id=17;

事务B回滚:

MySQL [employees]> update sys_user set name_pinyin='wangwu1' where id=17;
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

锁情况:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-QkfcinwY-1645429069042)(en-resource://database/1691:1)]

IS与IX冲突

事务A:先对记录增加了一个IS锁

begin;
select * from sys_user where id=17 for share;

事务B:后对记录申请一个IX锁

begin;
select * from sys_user where id=17 for update;

事务B回滚:

MySQL [employees]> select * from sys_user where id=17 for update;
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

注意

以上都是基于行进行的实验,具体的冲突矩阵大家可以使用以下SQL自行测试:

lock tables sys_user write;
lock tables sys_user read;

参考

  1. https://dev.mysql.com/doc/refman/8.0/en/innodb-locking.html#innodb-intention-locks
  2. https://www.infoq.cn/article/zau0ewzsdtx9zofr6c8w
<think>嗯,用户想了解MySQL InnoDB机制,这是个数据库核心问题。从引用内容看,用户应该已经查阅过相关资料,但需要系统性的梳理。 用户可能正在开发高并发应用,遇到了性能瓶颈或死问题。引用[3]提到排他的特性,引用[5]强调索引对行的重要性,说明用户关注的是的实际应用场景和优化方案。需要特别注意InnoDB与Oracle的差异(引用[1]),这点常被忽视但很关键。 机制需要分层讲解:先区分类型(表/行),再细分行里的共享/排他/意向锁,最后是算法(记录/间隙/临键)。引用[4]的监控指标很重要,但用户没明确说是否需要监控部分,可以放在进阶内容里。 用户引用的资料质量不错,特别是提到《高性能MySQL》和《MySQL技术内幕》,说明需要专业级内容。但要注意避免堆砌术语,比如解释“间隙”时必须配合具体SQL示例(如范围查询)。死分析部分要给出排查路径,因为引用[5]提到优化建议,用户可能正被死困扰。 最后考虑设计相关问题:兼容性(开发常踩坑)、死处理(运维刚需)、隔离级别影响(架构师关注点),覆盖不同层次需求。监控指标那题专门呼应引用[4],保持知识闭环。</think>以下是对MySQL InnoDB机制的系统性解析,结合核心特性和实践建议: --- ### **一、InnoDB的类型** 1. **行级(Row-Level Locks)** - **共享(S Lock)**:允许事务读取一行数据,其他事务可加共享但不可加排他。 ```sql SELECT ... LOCK IN SHARE MODE; -- 显式加共享 ``` - **排他(X Lock)**:允许事务更新或删除数据,其他事务无法加任何。 ```sql SELECT ... FOR UPDATE; -- 显式加排他 ``` 2. **表级(Table-Level Locks)** - 当**无法使用索引检索数据**时,InnoDB会退化为表(引用[^1])。 - 例如:`UPDATE table SET col=1 WHERE unindexed_col=2;` 若`unindexed_col`无索引,则定整表。 3. **意向锁(Intention Locks)** - **意向共享(IS)**:事务准备给数据行加共享前,先申请IS- **意向排他(IX)**:事务准备给数据行加排他前,先申请IX- **作用**:避免表与行的冲突(如:事务A持有行时,事务B想加表需先检查意向锁)。 --- ### **二、的算法(定范围)** 1. **记录(Record Lock)** - 定索引中的**单条记录**(即使表无索引,InnoDB也会创建隐藏聚簇索引)。 2. **间隙(Gap Lock)** - 定索引记录之间的**间隙**(开区间),防止其他事务插入。 - 示例:`SELECT * FROM table WHERE id BETWEEN 10 AND 20 FOR UPDATE;` 会定(10,20)区间。 3. **临键(Next-Key Lock)** - **记录 + 间隙**的组合(左开右闭区间),InnoDB默认使用此- 解决幻读问题(如`SELECT ... WHERE id > 10`定(10, +∞])。 --- ### **三、的兼容性与冲突** | 请求类型 | X(排他) | S(共享) | IX(意向排他) | IS(意向共享) | |------------|-----------|-----------|----------------|----------------| | **X(排他)** | ❌ | ❌ | ❌ | ❌ | | **S(共享)** | ❌ | ✓ | ❌ | ✓ | | **IX(意向排他)**| ❌ | ❌ | ✓ | ✓ | | **IS(意向共享)**| ❌ | ✓ | ✓ | ✓ | > ✓:兼容; ❌:冲突 --- ### **四、监控与性能指标** 通过`SHOW ENGINE INNODB STATUS`或系统表查看状态(引用[^4]): ```sql SHOW STATUS LIKE 'innodb_row_lock%'; ``` 关键指标: - `Innodb_row_lock_waits`:等待总次数 - `Innodb_row_lock_time_avg`:平均等待时长(毫秒) - `Innodb_row_lock_current_waits`:当前等待的事务数 --- ### **五、优化建议** 1. **强制使用行** - 确保WHERE条件使用**索引列**(否则退化为表,引用[^1][^5])。 2. **减少范围** - 避免大事务,尽量缩小事务操作的数据量。 - 精确使用索引(如避免`LIKE '%value'`导致全表扫描)。 3. **控制隔离级别** - 在`READ COMMITTED`级别下,间隙范围缩小,减少冲突。 4. **死处理** - InnoDB自动检测死并回滚代价较小的事务(需业务层重试机制)。 --- ### **六、实践案例** **场景**:高并发下单扣库存 ```sql -- 正确做法(使用索引+行) BEGIN; SELECT quantity FROM products WHERE id=100 FOR UPDATE; -- id为主键索引 UPDATE products SET quantity=quantity-1 WHERE id=100; COMMIT; ``` **错误做法**: ```sql UPDATE products SET quantity=quantity-1 WHERE name='ProductA'; -- name无索引 → 触发表! ``` > 关键原则:**通过索引检索数据是使用行的前提**(引用[^1][^3])。 ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值