加载中…
个人资料
  • 博客等级:
  • 博客积分:
  • 博客访问:
  • 关注人气:
  • 获赠金笔:0支
  • 赠出金笔:0支
  • 荣誉徽章:
正文 字体大小:

MYSQL事务与锁,需要手动加锁吗?

(2013-06-09 17:53:23)
标签:

杂谈

锁分为:隐式锁、显式锁。共享锁、排它锁。表锁、行锁、页级锁。
这些锁一般都是自动加锁。不用去管它,只需要知道在什么时候MYSQL会去加锁就行。
是否可以手动加锁?
可以。

事务中的锁 和 非事务中的锁

非事务中的锁,普通锁
手动加锁分为:悲观锁和乐观锁。估计是傻B式的加锁(结果是:从操作员读出数据、开始修改直至提交修改结果的全过程,甚至还包括操作 员中途去煮咖啡的时间,可能忘记解锁)
自动加锁:一般MYSQL在执行CREATE,ALTER,INSERT等命令时会自动加锁

事务中的锁
事务的四个隔离级别,对应不同的锁机制:
隔离级别:Read Uncommitted(读取未提交内容)、Read Committed(读取提交内容)、Repeatable Read(可重读)、Serializable(可串行化) 

Repeatable Read和Serializable2个事务隔离级别不需要手动加锁的,我认为在这2个事务级别中加锁是没有意义的,因为其他会话的事务是无法取得这2种事务中执行的数据的。Repeatable Read和Serializable)获取的永远是原始数据。

Read Uncommitted、Read Committed2个事务隔离级别可以手动加锁,因为这2种级别可能出现(脏读、不可重复读之类的“假数据”),所以在必要的时候进行手动加锁是不错的选择,我暂时是这样理解的。

解析1:默认事务中 从始至终只有一个锁闭合操作,即
LOCK TABLES tab;
#LOCK
#在此中间的 所有SQL语句都不会 锁和解锁,需要手动 锁的话见例1(READ-UNCOMMITTED操作)
#UNLOCK
UNLOCK TABLES;



例1(READ-UNCOMMITTED操作)
#会话a
START TRANSACTION; #开始事务1

select sleep(10) from feedback where id < 5;
#这里会默认 上隐式读锁。 这时我在事务2中 了写锁,看下是否会等待。(如果不 写锁可能会出现脏读等怪像;也就是说事务2不 写锁的话可以直接进行写操作,出现脏读,那就证明一个事务中 从始至终只有一个锁闭合操作,即解释1的说法)

select title from feedback where id = 1;
COMMIT; #提交事务

#会话b
START TRANSACTION; #开始事务2

LOCK TABLES feedback WRITE;
# 上写锁定, 这时会写锁等待吗?的确被锁住了,我要等待事务1解锁后,我才可以 写锁。以保证事务1能正确地读到我的更新信息,对于并发时候用这个隔离级别的话适合手动 锁来更新消息。
update feedback set title='609-1709' where id=3;#写锁权,执行写操作

UNLOCK TABLES; #解除写锁(注意:当当前所有的表均被锁定时,UNLOCK TABLES可以提交事务,我们不想UNLOCK TABLES提交事务,怎么办?

COMMIT; #提交事务






0

阅读 收藏 喜欢 打印举报/Report
  

新浪BLOG意见反馈留言板 欢迎批评指正

新浪简介 | About Sina | 广告服务 | 联系我们 | 招聘信息 | 网站律师 | SINA English | 产品答疑

新浪公司 版权所有