关于MySQL涉及锁的问题详解(2)-木庄网络博客

　　　　MyISAM存储引擎采用的是表级锁。

　　　　有两种模式：表共享读锁和表独占写锁。加读锁的命令：lock table 表名 read;　　去掉锁的命令：unlock tables。

　　　　支持并发插入：支持查询和插入操作并发运行（在表尾并发插入）。

　　　　锁调度机制：写锁优先。一个进程请求某个MyISAM表的读锁，同时另一个进程也请求同一表的写锁，MySQL如何处理呢？答案是写进程先获得锁。

　　2、行级锁：仅对指定的记录进行加锁，这样其他进程还是可以对同一个表中的其他记录进行操作。特点：开销大，加锁慢；会出现死锁；锁粒度最小，发生锁冲突的概率最低，并发度也最高。

　　　　InnoDB存储引擎既支持行级锁，也支持表级锁，但默认情况下是采用行级锁。

　　3、页级锁：一次锁定相邻的一组记录。开销和加锁时间介于表锁和行锁之间；会出现死锁；锁定粒度介于表锁和行锁治安，并发度一般。

　　最常用的处理多用户并发访问的方法是加锁。当一个用户锁定数据库中的某个对象时，其他用户就不能再访问该对象。加锁对并发访问的影响体现在锁的粒度上。比如，（表锁）放在一个表上的锁限制对整个表的并发访问；（页锁）放在数据页上的锁限制了对整个数据页的访问；（行锁）放在行上的锁只限制对该行的并发访问。

乐观锁和悲观锁的概念，实现方式和使用场景

锁有两种机制：悲观锁和乐观锁。

　　悲观锁，锁如其名，它对世界是悲观的，它认为别人访问正在改变的数据的概率是很高的，所以从数据开始更改时就将数据锁住，直到更改完成才释放。

一个典型的依赖数据库的悲观锁调用：

　　select * from account where name="Erica" for update

　　这条SQL语句锁定了account表中所有符合检索条件（name="Erica"）的记录。本事务提交之前（事务提交时会释放事务过程中的锁），外界无法修改这些记录。该语句用来锁定特定的行（如果where子句，就是满足where条件的那些行）。当这些行被锁定后，其他会话可以选择这些行，但不能更改或删除这些行，直到该语句的事务被commit语句或rollback语句结束终止。需要注意的是，select ...for update要放到MySQL的事务种，即begin和commit中，否则不起作用。

　　悲观所可能会造成加锁的时间很长，并发行不好，特别是长事务，影响系统的整体性能。

　　悲观所的实现方式：

　　　　悲观锁，也是基于数据库的锁机制实现。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁、写锁等，都是在做操作之前先上锁。

　　乐观锁，它对世界比较乐观，认为别人访问正在改变的数据的概率是很低的，所以直到修改完成准备提交所作的修改到数据库的时候才会将数据锁住，当你读取以及改变该对象时并不加锁，完成更改后释放。乐观锁不能解决脏读的问题。

　　乐观锁加锁的时间要比悲观锁短，大大提升了大并发量下的系统整体性能表现。

　　乐观锁的实现方式：

　　　　1、大多是基于数据版本（version）记录机制实现，需要为每一行数据增加一个版本标识（也就是每一行数据多一个字段version），每次更新数据都要更新对应的版本号+1。

　　　　工作原理：读出数据时，将此版本一同读出，之后更新时，对此版本号加一。此时，将提交的数据的版本信息与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据，不得不重新读取该对象并作出更改。

　　　　2、使用时间戳来实现

　　　　同样是在需要乐观锁控制的table中增加一个字段，名称无所谓，字段类型使用时间戳（timestamp），和上面的version类似，也是在更新提交的时候检查当前数据库中数据的时间戳和自己更新前取到的时间戳进行对比，如果一致则OK，否则就是版本冲突。

悲观锁与乐观锁的适用场景：

　　如果并发量不大，可以使用悲观锁解决并发问题；但如果系统的并发量非常大的话，悲观所定会带来非常大的性能问题，所以我们就要选择乐观锁定的方法。现在大部分应用都应该是乐观锁的。