数据库的锁模块（上）

今晚圣诞节，时间原因，粗略讲下，

索引大家已经滚瓜烂熟了吧，直接切入正题，

锁，数据库锁的分类，

按照粒度划分，可分为表级锁、行级锁、页级锁（同一个存储块的相邻几行数据）。

按锁级别划分，可分为共享锁，排他锁

按加锁方式划分，可分为自动锁（增删改）、显示锁（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，不能在提交前锁住字段，如果两个事务，对一个数据两次读写，就会出现不可预期结果。

下次再讲，溜了溜了，鸽了鸽了，撤撤撤。。。。