Innodb的行锁和表锁

本文详细介绍了MySQL数据库InnoDB引擎的锁机制,包括行锁和表锁的概念、特点及应用场景。解析了行锁中的共享锁与排他锁,以及表锁的工作原理。同时探讨了锁在事务隔离级别中的作用。
一.什么是Innodb?什么是行锁和表锁?
  1. Innodb:是MySQL的数据库引擎之一,现为MySQL的默认存储引擎,其实也就是一套放在 MySQL后台的完整数据库系统,InnoDB 在主内存中建立其专用的缓冲池用于高速缓冲数据和索引.
    InnoDB 给 MySQL 提供了具有事务(transaction)、回滚(rollback)和崩溃修复能力(crash recovery capabilities),并且支持MVCC.

  2. 行锁:对一个表锁住某几行,其他事务对锁住的行不能进行写操作.

  3. 表锁:锁住整个表,其他事务对整个表不能进行写操作.

  4. 注意:这两个锁都是针对于事务来说的,没有开启事务或者是在一个事务里面也就不存在锁了.

二.行锁和表锁的特点.
  1. 行锁可以支持更好的并发,但可能发生死锁
  2. 表锁不会发生死锁,对并发支持低.
三.分类.
  1. 行锁.
    (1).共享锁: 在执行语句后加上lock in share mode,又叫读锁

    当一个事务对某几行上读锁操作时,可以允许其他事务读,不允许写,但允许其他事务上读锁,

    (2).排他锁: 在执行语句后加上for update,又叫写锁.

    当一个事务对某几个上写锁时,不允许其他事务写,但允许读。更不允许其他事务给这几行上任何锁

  2. 表锁.

四.注意事项.

1.如果对某几行上行锁,但是没有索引,会变成表锁.行锁是针对索引来实现的

其实这里不太恰当的,并不是对变成表锁,而是对整个所有的数据行加行锁,因为在不使用索引的情况下,mysql并不知道哪些符合条件。会全部加锁返回。
      举例: 在一个事务中执行.
      SELECT * FROM account WHERE NAME IN(‘张三’,‘嗨’) LOCK IN SHARE MODE
      这个时候就会对整个表加锁.
      然后在另一个窗口执行. 将张三的名字改成张五
      UPDATE account SET NAME=“张五” WHERE id=2.
      就会发现不能更改,被锁住.但是如果对name加了索引就不会被锁住了.就会由表锁变为行锁.

2.两个事务不能锁同一个索引.

五.深入理解锁.

数据库的事务及其事务的隔离级别,但是数据库是怎样隔离事务的呢?这时候就牵连到了数据库锁。当插入数据时,就锁定表,这叫做”锁表”(其他不能做删除或新增操作,可以做更新);当更新数据时,就锁定行,这叫做”锁行”。

锁在数据网络传输中是一个非常重要的概念,当多个用户对数据库进行操作时,会带来数据不一致的情况,所以,锁主要是在多用户情况下保证数据库数据完整性和一致性。

六.数据库得自动加锁,针对于InnoDB引擎.

当对表执行update,insert,delete操作时,会对涉及到得行默认加行级锁.其他事务可以读,但是不可以写.

<think>好的,我现在需要帮助用户理解数据库中的的区别及应用场景。根据用户的问题,他们想了解这两个概念以及它们的区别应用场景。首先,我得回忆一下相关的数据库知识,特别是MySQL中的机制,因为引用中多次提到InnoDB引擎的相关内容。 首先,的基本区别是什么?根据引用5,是加在索引上的,如果没有使用索引,InnoDB会使用。这意味着的粒度更细,只定特定,而定整个。引用3提到,允许其他事务访问中的其他,而则会阻止其他事务对的大部分操作。这是关键的区别之一。 接下来是应用场景。引用3指出,适用于高并发读写的场景,因为不同事务可以访问不同的,减少争用。而可能更适合于写操作较多或者需要全扫描的情况,比如数据迁移或批量更新。引用4提到,当SQL语句使用不当,比如没有正确使用索引,可能会导致升级为,这会影响并发性能。 另外,性能方面,由于定范围小,通常支持更高的并发,而可能导致更多的阻塞,但开销较小。根据引用5,InnoDB中通过索引实现,所以正确的索引使用对至关重要。 还需要考虑不同存储引擎的支持。比如,InnoDB支持,而MyISAM只支持。这可能也是用户需要注意的地方,不同的引擎选择会影响机制的为。 用户可能还关心如何手动获取,但根据引用1中的问题列,用户提到了手动获取的方法,但当前的问题主要是区别应用场景,所以可能在回答中简要提到,但不需要深入。 需要确保回答结构清晰,分点说明区别应用场景,并举例说明。同时,根据系统指令,使用中文回答,数学达式用$...$,不过这个问题可能涉及较少的数学公式,但如果有涉及的地方需要注意格式。比如,在解释的粒度时,可能需要用例子来说明,但不需要数学公式。 总结一下,回答的结构应该是: 1. 定义 2. 主要区别(定范围、并发性能、索引依赖、存储引擎支持) 3. 应用场景(分别举例) 4. 注意事项(如索引的使用,升级的情况) 同时,需要引用提供的参考资料,比如引用3、4、5中的内容,在适当的地方添加引用标识。例如,在解释需要索引时引用5,在升级的情况引用4。 现在检查是否有遗漏点。用户的问题还包括如何优化并发性能,这可能与的选择有关,但问题主要是区别应用场景,优化可以作为相关部分提及,但可能属于相关问题部分。 最后,生成相关问题,如不同存储引擎对的支持,如何避免升级为,性能优化方法等。</think>### 的区别及应用场景 #### 一、基本概念 1. **** 数据库中的**单数据**,其他事务仍可访问中其他依赖索引实现,若SQL未使用索引,则退化为[^5]。例如更新语句`UPDATE users SET age=20 WHERE id=1`(假设`id`是索引字段)仅定`id=1`的。 2. **** 定**整个**,其他事务无法修改或插入数据。例如MyISAM引擎的写操作默认加,或InnoDB中未使用索引的更新语句(如`UPDATE users SET status=0 WHERE name LIKE '%test%'`)会触发全[^4]。 --- #### 二、核心区别 | **对比维度** | **** | **** | |--------------------|-----------------------------------|-----------------------------------| | 定范围 | 单或多(通过索引定位)[^3] | 整 | | 并发性能 | 高(允许多事务操作不同)[^3] | 低(事务串化) | | 索引依赖 | 必须使用索引,否则退化为[^5] | 不依赖索引 | | 存储引擎支持 | InnoDB支持 | MyISAM默认支持,InnoDB特定场景触发| --- #### 三、应用场景 1. **适用场景** - **高并发读写**:如电商库存扣减(不同用户购买不同商品)[^3]。 - **事务需精细控制**:例如银转账仅定涉及账户的。 - **OLTP系统**(联机事务处理):短事务、高响应速度需求。 2. **适用场景** - **全操作**:数据迁移`ALTER TABLE`或统计全`COUNT(*)`[^4]。 - **低并发写**:报系统批量写入历史数据。 - **MyISAM引擎**:读多写少的场景(如日志)。 --- #### 四、注意事项 1. **索引设计** 使用时需确保SQL命中索引,避免升级。例如`WHERE`条件字段未加索引会导致全[^5]。 2. **冲突** 可能引发大面积阻塞,如`LOCK TABLES users WRITE`会阻止所有写操作。 3. **事务拆分** 长事务持有会增加死风险,需尽量缩短事务时间。 --- #### 示例对比 ```sql -- 示例(命中索引) BEGIN; UPDATE orders SET amount=100 WHERE order_id=123; -- order_id是主键索引 COMMIT; -- 示例(未命中索引) BEGIN; UPDATE orders SET status='expired' WHERE create_time < '2023-01-01'; -- create_time无索引 COMMIT; ``` ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

程序员bling

义父,感谢支持

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值