锁模块之MyISAM与InooDB关于锁方面的区别

锁模块

常见问题：

• MyISAM与Innodb关于锁方面的却别是什么

1. MyISAM默认使用的是表级锁，不支持行级锁
2. 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的非堵塞读如何实现