锁模块
常见问题:
- MyISAM与Innodb关于锁方面的却别是什么
- MyISAM默认使用的是表级锁,不支持行级锁
- InnoDBmoren用的是行级锁,也支持表级锁
MyISAM引擎在进行查询的时候,会自动为表加上一个读锁,而对数据进行增删改的时候,会为我们操作的表,加上一个表级别的写锁,当读锁没有被释放,另外一个session想要对同一个表加上写锁,他就会被堵塞,知道所有的读锁被释放位置。如何显示的为表加上读锁,如下:
释放锁:
读锁有另外的名字:共享锁
以下是演示写锁,然后在是读锁或者写锁
然后在另外一个session中做读操作
在执行读操作的时候,由于已经有写锁,所以该此读操作被堵塞。
先执行修改操作(加写锁),在另外一个session中做修改操作(写锁),则该写锁会被堵塞。
写锁的别名:排它锁
insert、delete、update都可以上排它锁,对于select也可以上排它锁,如下:
当select操作上排它锁之后,其他session中的select也会被堵塞
InnoDB:
由于InnoDB支持事务,所以我们可以通过session获取锁,再是不提交的方式,模拟并发访问的过程。mysql是默认提交事务的。
如下模拟两个session对同一行数据进行修改的情况:
两个session的修改语句如下:
执行结果发现,并没有出现第二个session在执行时出现堵塞的情况
InnoDB使用个是二段锁,即加锁和解锁是分两个步骤完成的,即先对同一个事务里的一批操作分别进行加锁,然后到commit的时候,在对事务里加上的锁进行统一的解锁,而当前的commit是自动提交的,所以看起来和MyISAM没哟太大的区别。
我们可以通过执行以下命令得到结论:
on:代表事务默认是自动提交的。
关闭自动提交(该设置只针对当前的session,而其他session仍然是自动提交的):
操作验证如下(前提的首要关闭自动提交):
1:其中一个session加上共享锁,执行如下语句:
2:在另外一个session中对同一行执行update操作
实验结果是第二个session中的操作能修改数据成功。
原因如下:
InnoDB对select进行了改进,第一个session中的select操作并没有对该行上锁,所以才导致更新是成功的。InnoDB引擎下如何显示的加共享锁,如下:
当在另外一个session中执行update操作的时候就会堵塞
MyISAM的适用场景
InnoDB适合的场景
数据库锁的分类
- 数据库事务的四大特性
数据库事务作为一个单独的数据库逻辑单元执行的一系列操作,要么完全执行,要么全部都不执行。
ACID:
原子性(aotmic):事务包含的所有操作,要么全部执行,要么全部失败回滚,要么全做,要么全都不做
一致性(consistency):事务因确保数据库的状态,从原来的一直状态,转变为另外一致的状态,一致状态的含义是指:
数据库中的数据应满足完整性约束,就好比转账,假设用户A和用户B加起来的钱总和是2000,不管两者如何转账,事务结束后,两个用户的钱相加起来还要是2000,这就是事务的一致性
隔离性(isolation):多个事务并发执行时,一个事务的执行,不应该影响其他事务的执行
持久性(durability):一个事务一旦提交,他对数据库的修改,应该永久保存在数据库中,持久性意味着当数据库发生故障时,确保已提交事务的更新不能丢失,即对已提交事务的更新能恢复,一旦一个事务被提交,DBMS必须保证提供适当 的冗余,使其耐得住系统的故障,持久性主要是在于DBMS的恢复性能
- 事件隔离级别及各级别下的并发访问问题
事务并发访问引起的问题以及如何避免
- 更新丢失 mysql所有事务隔离级别在数据库层面上均可避免
即一个事务的更新覆盖了另外一个事务的更新
- 脏读 read-commit事务隔离界别以上可以避免
- 不可重复读 repeatable-read事务隔离界别以上可以避免
- InnoDB可重复读隔离级别下如何避免幻读
- RC,RR级别下的InnoDB的非堵塞读如何实现