MYSQL加锁的测验
存储引擎 支持的锁定级别
myisam 表级别
memory 表级别
inndb 行级别
bdb: 页级别
lock锁定类型
锁定方式 目的
读锁 自己与其他线程只能读取该表
写锁 只有当前线程能够对表进行写入操作(其他线程也无法读这部分数据)
读锁的英文叫法是shared locks,shared是共享的意思,共享锁,就是所有用户都可以共享进行读(包括加锁的用户),不能写。
写锁的英文叫法是Exclusive Locks,Exclusive是独有、排外的意思,只有自己(加锁的用户)才能进行些写入操作,其他用户只能读。有些书籍中有不同叫法,比如互斥锁、排他锁。
纠正一下:以前理解错误了。加了排他锁定,其他事务是无法读取数据的。网上的资料比较零散。
最近看了jim Gray那本《事务处理概念与技术》,里面提到排他锁时:保留对该节点写的权利,防止其他事务在该节点及其后代节点加{x,u,s,six,is,ix}锁。
提到的s就是共享锁了,既然防止其他事务加s锁,那么其他线程是无法读的(所有线程获取数据之前必须先申请锁才能操作)。文章下面加的试验也会证明了这点。
ps:看来总结也好,加深了理解,如果不总结,也不会发现细节理解偏差。
测试一:测验读锁
运行一个读锁:“lock table `cat` READ”
然后尝试使用update语句操作 :
update `cat` set remark= 'ceshi'
报错如下:
Table 'a' was locked with a READ lock and can't be updated
现在解锁(针对当前线程锁定的所有表解锁):"unlock tables"
然后再次运行update语句,报错消失。完成更新操作。说明已经解除读锁了(可以进行更新)
测验二:测验写锁
1、 我在一个客户端SQLyog中运行一个写锁sql:LOCK TABLE cat WRITE;
2、另外开一个客户端(线程),尝试运行更新:
update `cat` set remark= 'jgjgjg'
情况:因为使用了写锁,只有自己能够修改数据,其他线程无法执行update操作,此时服务器端的php程序一直等待数据库给予响应结果,数据被锁定了,根本没法执行sql语句,处于等待中,数据库并不会报错,因为这本来就是一个很正常的情况,需要等待释放锁才能执行update操作,其实大并发环境下就是这种情况(很多用户同时在执行sql操作,有的加了写锁定),于是速度就慢下来了。
结果phpmyadmin一直处于等待中,等待服务器给予客户端(浏览器)数据,截图如下:
经验:使用phpmyadmin无法模拟出一个线程的情况。因为每次php运行完毕后,与数据库的连接就会自动断开(php脚本特性)。
而SQLyog这样的工具能够保持连接不断掉。所以,测验写锁的时候完全可以使用同一个工具测验出来。
增加测验:测验加写锁后,其他事务无法读数据的情况
同样也是在SQLyog这样的工具中运行:LOCK TABLE cat WRITE
因为加了x锁后,其他事务是无法获得s锁,所以根本无法读数据。phpmyadmin这边查询这个表,都是等待状态。
下面我在SQLyog释放掉写锁后,phpmyadmin这边就能读取数据了
InnoDB使用行锁定,BDB使用页锁定。对于这两种存储引擎,都可能存在死锁。这是因为,在SQL语句处理期间,InnoDB自动获得行锁定和BDB获得页锁定,而不是在事务启动时获得。
update语句默认比select语句优先权高。可以修改,在启动mysql的时候加上参数,用--low-priority-updates启动mysqld
在大流量、大数量的网站,往往瓶颈不在于具体的语言,其实.net、java、php等语言速度的差别是有,但是很小,忽略不计。往往瓶颈在于数据库。我是这样理解:
$conn->query("update where ....");
...php其他代码
//php需要等待数据库(比如mysql)给予返回结果,才能继续往下面执行代码,但里mysql被锁定了,一直没有执行完毕。所以卡死了,一直在等待中。这就是为什么语言不是瓶颈,瓶颈往往在数据库(数据量大的时候,数据库压力很大),这就是同步执行,需要等到上面代码执行完毕才能继续执行,以前听过阿里巴巴的分享,使用一种异步执行方案。并行加载数据,那么代码的执行耗时取决于最耗时的操作(因为所有操作都是并行开始运行)
其他测验办法:还可以开多个mysql命令行界面来测验。每个界面就是一个session。
(转载出处:http://www.cnblogs.com/wangtao_20/p/3463435.html)