今晚圣诞节,时间原因,粗略讲下,
索引大家已经滚瓜烂熟了吧,直接切入正题,
锁,数据库锁的分类,
按照粒度划分,可分为表级锁、行级锁、页级锁(同一个存储块的相邻几行数据)。
按锁级别划分,可分为共享锁,排他锁
按加锁方式划分,可分为自动锁(增删改)、显示锁(sql中自己写的lock)
按操作划分,可分为DML锁(对数据进行操作的锁),DDL锁(对表结构进行变更的锁)
按使用方式划分,可分为乐观锁、悲观锁
MyISAM引擎默认用的是表级锁,不支持行级锁,InnoDB默认用的是行级锁,也支持表级意向锁(共享读锁IS,排他写锁IX,不需要轮询每行是不是有行锁),无论是行锁还是表级锁,均分为共享锁和排他锁,
X为排他锁,S为共享锁,冲突需要等待锁的释放,就是未commit或未rollback的时候。行级锁不一定会比表级锁好,锁的细腻度越高,代价越大,需要找到行加锁。InnoDB支持事务的同时也比MyISAM带来了更大的开销,学索引的时候我们了解过InnoDB有且只有一个聚集索引,数据文件是和索引绑在一起的,需要有主键,通过主键索引效率很高,但是辅助索引需要查两次,先查主键,再通过主键查到数据,而MyISAM是非聚集索引,数据文件是分离的,索引保存的是数据文件的指针,主键索引和辅助索引是独立的,因此MyISAM引擎在增删改很少的系统中性能要好于InnoDB,
1.MyISAM适合频繁执行全表count,会用一个表保存行数,不需要检查每行,2.对增删改频率不高,查询非常多场景。增删改会涉及锁表操作。3.没有事务的场景。
1.InnoDB适合增删改频繁的场所,增删改只会锁某些行,大多数情况下避免了堵塞,不像MyISAM每个增删改都锁整张表。2.可靠性要求比较高,要求支持事务。
这礼拜实操下乐观锁和悲观锁的实现,圣诞节溜了溜了,乐观锁主要是看版本version,读两次version都是0,读操作version是不会变的但是每次增删改更新,为了防止冲突,都会去先检查version,成功后version会加1,切记是提交后改变版本,提交前检测version,不能在提交前锁住字段,如果两个事务,对一个数据两次读写,就会出现不可预期结果。
下次再讲,溜了溜了,鸽了鸽了,撤撤撤。。。。
领取专属 10元无门槛券
私享最新 技术干货