MySQL数据库的锁机制文档格式.docx
《MySQL数据库的锁机制文档格式.docx》由会员分享，可在线阅读，更多相关《MySQL数据库的锁机制文档格式.docx（6页珍藏版）》请在冰豆网上搜索。
行
∙行级锁
∙行级锁是Mysql中锁定粒度最细的一种锁，表示只针对当前操作的行进行加锁。
行级锁能大大减少数据库操作的冲突。
其加锁粒度最小，但加锁的开销也最大。
行级锁分为共享锁和排他锁。
∙特点
∙开销大，加锁慢；
会出现死锁；
锁定粒度最小，发生锁冲突的概率最低，并发度也最高。
表
∙表级锁是MySQL中锁定粒度最大的一种锁，表示对当前操作的整张表加锁，它实现简单，资源消耗较少，被大部分MySQL引擎支持。
最常使用的MYISAM与INNODB都支持表级锁定。
表级锁定分为表共享读锁（共享锁）与表独占写锁（排他锁）。
∙开销小，加锁快；
不会出现死锁；
锁定粒度大，发出锁冲突的概率最高，并发度最低。
页
∙页级锁是MySQL中锁定粒度介于行级锁和表级锁中间的一种锁。
表级锁速度快，但冲突多，行级冲突少，但速度慢。
所以取了折衷的页级，一次锁定相邻的一组记录。
BDB支持页级锁
∙开销和加锁时间界于表锁和行锁之间；
锁定粒度界于表锁和行锁之间，并发度一般
MySQL常用存储引擎的锁机制
MyISAM和MEMORY采用表级锁（table-levellocking）
BDB采用页面锁（page-levellocking）或表级锁，默认为页面锁
InnoDB支持行级锁（row-levellocking）和表级锁,默认为行级锁
∙InnoDB行锁是通过给索引上的索引项加锁来实现的，InnoDB这种行锁实现特点意味着：
只有通过索引条件检索数据，InnoDB才使用行级锁，否则，InnoDB将使用表锁！
在实际应用中，要特别注意InnoDB行锁的这一特性，不然的话，可能导致大量的锁冲突，从而影响并发性能。
行级锁都是基于索引的，如果一条SQL语句用不到索引是不会使用行级锁的，会使用表级锁。
行级锁的缺点是：
由于需要请求大量的锁资源，所以速度慢，内存消耗大。
实例说明
∙MySQLInnoDB引擎默认的修改数据语句：
update,delete,insert都会自动给涉及到的数据加上排他锁。
select语句默认不会加任何锁类型，如果加排他锁可以使用select…forupdate语句，加共享锁可以使用select…lockinsharemode语句。
所以加过排他锁的数据行在其他事务种是不能修改数据的，也不能通过forupdate和lockinsharemode锁的方式查询数据，但可以直接通过select…from…查询数据，因为普通查询没有任何锁机制。
行级锁与死锁
MyISAM中是不会产生死锁的，因为MyISAM总是一次性获得所需的全部锁，要么全部满足，要么全部等待。
而在InnoDB中，锁是逐步获得的，就造成了死锁的可能。
在MySQL中，行级锁并不是直接锁记录，而是锁索引。
索引分为主键索引和非主键索引两种，如果一条sql语句操作了主键索引，MySQL就会锁定这条主键索引；
如果一条语句操作了非主键索引，MySQL会先锁定该非主键索引，再锁定相关的主键索引。
在UPDATE、DELETE操作时，MySQL不仅锁定WHERE条件扫描过的所有索引记录，而且会锁定相邻的键值，即所谓的next-keylocking。
当两个事务同时执行，一个锁住了主键索引，在等待其他相关索引。
另一个锁定了非主键索引，在等待主键索引。
这样就会发生死锁。
发生死锁后，InnoDB一般都可以检测到，并使一个事务释放锁回退，另一个获取锁完成事务。
共享锁与排它锁
共享锁（ShareLock）
∙共享锁又称读锁，是读取操作创建的锁。
其他用户可以并发读取数据，但任何事务都不能对数据进行修改（获取数据上的排他锁），直到已释放所有共享锁。
如果事务T对数据A加上共享锁后，则其他事务只能对A再加共享锁，不能加排他锁。
获准共享锁的事务只能读数据，不能修改数据。
用法SELECT...LOCKINSHAREMODE;
在查询语句后面增加LOCKINSHAREMODE，Mysql会对查询结果中的每行都加共享锁，当没有其他线程对查询结果集中的任何一行使用排他锁时，可以成功申请共享锁，否则会被阻塞。
其他线程也可以读取使用了共享锁的表，而且这些线程读取的是同一个版本的数据。
排它锁（eXclusiveLock）
∙排他锁又称写锁，如果事务T对数据A加上排他锁后，则其他事务不能再对A加任任何类型的封锁。
获准排他锁的事务既能读数据，又能修改数据。
用法SELECT...FORUPDATE;
在查询语句后面增加FORUPDATE，Mysql会对查询结果中的每行都加排他锁，当没有其他线程对查询结果集中的任何一行使用排他锁时，可以成功申请排他锁，否则会被阻塞。
乐观锁（OptimisticLock）
是什么
∙假设认为数据一般情况下不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则让返回用户错误的信息，让用户决定如何去做。
相对于悲观锁，在对数据库进行处理的时候，乐观锁并不会使用数据库提供的锁机制。
一般的实现乐观锁的方式就是记录数据版本。
数据版本,为数据增加的一个版本标识。
当读取数据时，将版本标识的值一同读出，数据每更新一次，同时对版本标识进行更新。
当我们提交更新的时候，判断数据库表对应记录的当前版本信息与第一次取出来的版本标识进行比对，如果数据库表当前版本号与第一次取出来的版本标识值相等，则予以更新，否则认为是过期数据。
实现数据版本有两种方式，第一种是使用版本号，第二种是使用时间戳。
使用版本号实现乐观锁
∙使用版本号时，可以在数据初始化时指定一个版本号，每次对数据的更新操作都对版本号执行+1操作。
并判断当前版本号是不是该数据的最新的版本号。
1.查询出商品信息
select（status,status,version）fromt_goodswhereid=#{id}
2.根据商品信息生成订单
3.修改商品status为2
updatet_goods
setstatus=2,version=version+1
whereid=#{id}andversion=#{version};
优点与不足
∙乐观并发控制相信事务之间的数据竞争（datarace）的概率是比较小的，因此尽可能做下去，直到提交的时候才去锁定，所以不会产生任何锁和死锁。
但如果直接简单这么做，还是有可能会遇到不可预期的结果，例如两个事务都读取了数据库的某一行，经过修改以后写回数据库，这时就遇到了问题
悲观锁（PessimisticLock）
∙在整个数据处理过程中，将数据处于锁定状态。
悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）
悲观锁的流程
∙在对任意记录进行修改前，先尝试为该记录加上排他锁（exclusivelocking）。
∙如果加锁失败，说明该记录正在被修改，那么当前查询可能要等待或者抛出异常。
具体响应方式由开发者根据实际需要决定。
∙如果成功加锁，那么就可以对记录做修改，事务完成后就会解锁了。
∙其间如果有其他对该记录做修改或加排他锁的操作，都会等待我们解锁或直接抛出异常。
MySQLInnoDB中使用悲观锁
∙要使用悲观锁，我们必须关闭mysql数据库的自动提交属性，因为MySQL默认使用autocommit模式，也就是说，当你执行一个更新操作后，MySQL会立刻将结果进行提交。
setautocommit=0;
//0.开始事务
begin;
//1.查询出商品信息
selectstatusfromt_goodswhereid=1forupdate;
//2.根据商品信息生成订单
insertintot_orders（id,goods_id）values（null,1）;
//3.修改商品status为2
updatet_goodssetstatus=2;
//4.提交事务
commit;
上面的查询语句中，我们使用了select…forupdate的方式，这样就通过开启排他锁的方式实现了悲观锁。
此时在t_goods表中，id为1的那条数据就被我们锁定了，其它的事务必须等本次事务提交之后才能执行。
这样我们可以保证当前的数据不会被其它事务修改。
Java的锁机制
线程的同步问题
∙一段synchronized的代码被一个线程执行之前，他要先拿到执行这段代码的权限，在java里边就是拿到某个同步对象的锁（一个对象只有一把锁）；
如果这个时候同步对象的锁被其他线程拿走了，他（这个线程）就只能等了（线程阻塞在锁池等待队列中）。
取到锁后，他就开始执行同步代码（被synchronized修饰的代码）；
线程执行完同步代码后马上就把锁还给同步对象，其他在锁池中等待的某个线程就可以拿到锁执行同步代码了。
这样就保证了同步代码在统一时刻只有一个线程在执行。
线程的同步方法：
∙1.在需要同步的方法的方法签名中加入synchronized关键字。
∙2.使用synchronized块对需要进行同步的代码段进行同步。
∙3.使用JDK5中提供的java.util.concurrent.lock包中的Lock对象。
ThreadLocal
当使用ThreadLocal维护变量时，ThreadLocal为每个使用该变量的线程提供独立的变量副本，所以每一个线程都可以独立地改变自己的副本，而不会影响其它线程所对应的副本。
在ThreadLocal类中有一个Map，用于存储每一个线程的变量副本，Map中元素的键为线程对象，而值对应线程的变量副本。
使用ThreadLocal的典型场景如数据库连接管理，线程会话管理等场景，只适用于独立变量副本的情况，如果变量为全局共享的，则不适用在高并发下使用。
升级会员 