数据库考点_7

MyISAM适合的场景

1. 适合频繁执行全表count语句,因为MyISAM用一个变量保存了整个表的行数,执行count语句只需要读出该变量即可,而InnoDB不保存表的具体行数,每次执行select count(*) from table时,需要重新扫描全表进行统计.
2. 对数据进行增删改的频率不高(因为增删改会锁表,降低执行速度),但是查询非常频繁.
3. 没有事务

InnoDB适合的场景

1. 数据增删改查都相当频繁(因为InnoDB默认使用行级锁).
2. 可靠性要求比较高,要求支持事务.

数据库锁的分类

1. 按锁的粒度来划分: 可分为表级锁,行级锁,页级锁.
2. 按锁级别划分: 可分为共享锁,排它锁.
3. 按加锁方式划分: 可分为自动锁(比如意向锁,更新语句上的排它锁等),显式锁(比如for update,lock in share mode等).
4. 按操作划分: 可分为DML(数据操作语言,主要对表的数据进行操作,比如增删改查)锁,DDL(数据定义语言,主要对表和数据库操作)锁.
5. 按使用方式划分: 可分为乐观锁,悲观锁.

乐观锁:乐观锁相对于悲观锁而言,它认为数据一般情况下不会造成冲突,所以在数据进行提交更新的时候,才会正式对数据的冲突与否进行检测,如果发现冲突了,则返回用户错误的信息,让用户决定咋整.
相对于悲观锁在对数据进行处理的时候呢,乐观锁不会用到数据库提供的锁机制,一般实现乐观锁的方式是记录数据版本(即为数据增加一个版本标志,一般是通过对数据库表增加一个数值类型的version字段实现),而实现记录数据版本有两种方式:

1. 第一种是使用版本号,数据每更新一次,就对version进行增加操作,比如加1,当我们并发的提交更新的时候,去获取数据库表中记录的当前版本信息与第一次取出来的version值进行比对,若相等,就对数据进行更新,不相等就认为是过期数据,更新不会成功.例子如下:

我们模拟两个程序对数据进行操作:
如下为程序一中的语句(看最后一句就成,前几句两个程序都是一样的)

若程序1的更新语句执行后再执行程序2的语句,因为程序1执行结束后,version版本已经变成了1,但是这里还是0,所以更新不会成功.

乐观并发控制不容易产生死锁的问题,但是还是会有其他问题,之后再写

2. 第二种是使用时间戳,实际操作和使用版本号一样的.

悲观锁:指的是对数据被外界(即本系统的其他事务和其他系统的事务处理)的修改持保守态度,因此在整个数据处理过程中,将数据处于锁定状态,悲观锁的实现 往往依靠锁机制,通过排它锁实现.

悲观并发控制实际上就是先取锁,再访问的保守策略. 为数据处理的安全提供了保证.但是在效率方面,处理数据过程中加锁的机制会让数据库产生额外的开销,也会增加产生死锁的机会(例如A在修改文件T1，B在修改文件T2，他们分别锁定了这两个文件，假设T1和T2内容相关，B在修改T2的时候发现他还需要修改T1，可是T1却被A锁定；与此同时，A在修改T1的时候也发现了他还需要修改T2，可是T2又被B锁定了，这样就出现了死锁),

在只读型事务处理中,由于不会产生冲突,就没必要使用锁,上锁只会增加系统负担,同时还会降低并行性,即一个事务如果锁定了某行数据,其他事务就必须等待该事务处理完才可以去处理.