MySQL 51支持对MyISAM和MEMORY表进行表级锁定,对BDB表进行页级锁定,对InnoDB表进行行级锁定。
如果不能同时插入,为了在一个表中进行多次INSERT和SELECT *** 作,可以在临时表中插入行并且立即用临时表中的记录更新真正的表。
这可用下列代码做到:
mysql> LOCK TABLES real_table WRITE, insert_table WRITE;
mysql> INSERT INTO real_table SELECT FROM insert_table;
mysql> TRUNCATE TABLE insert_table;
mysql> UNLOCK TABLES;
oracle数据库 锁表和死锁的区别
死锁指的是a,b两个事务对同一对象进行dml或ddl *** 作(即修改表结构或者增删改数据),出现了相互等待被锁定的对象的情况,即类似于红绿灯十字路口红灯方向堵住路口,绿灯方向却红灯车辆挡在路口不能过去,这样无论红绿灯如何变化都无法通行。一般像oracle这样的dbms是有死锁检测的,然后把锁定对象抛出来按照预定规则处理或者让程序处理。 锁等待指的是a事务锁定了 *** 作对象,而b事务也要对其进行dml或ddl *** 作(即修改表结构或者增删改数据)时,需要等待a事务完成。这个和死锁不同,只要a事务完成后,b事务就可以正常进行了。类似于正常的红绿灯十字路口通行状态:红灯方向就是等待锁释放的b事务,绿灯方向就是锁定路口的a事务。待红绿灯互换,则a事务执行完毕,b事务也就可以正常执行啦。
MySQL锁表是什么意思?有什么用?什么情况下用?好处?缺点?
白话解说如下:
简单说,就是lock table,不让别人动
锁分共享锁和排它锁。
共享锁时,别人能读,不能改变量表数据
排它锁时,别人既不能读,也不能改表数据
根据以上特点,应该就知道何时使用锁了。不想让别人变更数据,对自己产生影响,就加锁。一定要在不用之后,进行锁释放,不然,应用系统会一直因为读取数据而报错。
好处就是,保证数据的原子性,完整性,一致性。 只有加锁者释放了锁,别人才能改变数据。
缺点就是,增加了系统开销,有可能产生锁等待,造成数据库运行异常。这都是不正常的使用锁带来的问题。
什么情况下造成数据库锁表? 如何解决?
zhidaobaidu/question/180766896
两个SQL的锁表问题
不同的数据库,多版本的实现机制不同,上述语句执行情况也就不一样,下面以oracle为例说明:
1insert/delete语句可以并发执行,不会锁等待
2并发insert不会锁等待
3并发update,如果不是 *** 作同一条记录,不会锁等待
=================================================
对真实存在的数据进行并发 *** 作才有可能发生写冲突,所以楼主供要把握住这点就可以判断是否会冲突了。
建议楼主构造简单数据,开两个客户端,在不同的隔离级下去模拟并发 *** 作,理论和实践相结合,你会理解的更透彻。
oracle 数据库 为什么锁表
简单地说,锁是为了保证数据的一致性,锁不止存在于oracle,其他数据库一样有,只不过机制上可能大相径庭。 至于什么样的 *** 作会锁表,其实锁的种类很多,你所说的锁表大概说的是行级锁——也就是事务锁吧
如何将数据库中被锁表解锁
在 *** 作数据库的时候,有时候会由于 *** 作不当引起数据库表被锁定,这么我们经常不知所措,不知怎么给这些表解锁,在pl/sql Developer工具的的菜单“tools”里面的“sessions”可以查询现在存在的会话,但是我们很难找到那个会话被锁定了,想找到所以被锁的会话就更难了,下面这叫查询语句可以查询出所以被锁的会话。如下:
SELECT snusername, mSID,snSERIAL#, mTYPE,
DECODE (mlmode,
0, 'None',
1, 'Null',
2, 'Row Share',
3, 'Row Excl',
4, 'Share',
5, 'S/Row Excl',
6, 'Exclusive',
lmode, LTRIM (TO_CHAR (lmode, '990'))
) lmode,
DECODE (mrequest,
0, 'None',
1, 'Null',
2, 'Row Share',
3, 'Row Excl',
4, 'Share',
5, 'S/Row Excl',
6, 'Exclusive',
request, LTRIM (TO_CHAR (mrequest, '990'))
) request,
mid1, mid2
FROM v$session sn, v$lock m
WHERE (snSID = mSID AND mrequest != 0) --存在锁请求,即被阻塞
OR ( snSID = mSID --不存在锁请求,但是锁定的对象被其他会话请求锁定
AND mrequest = 0
AND lmode != 4
AND (id1, id2) IN (
SELECT sid1, sid2
FROM v$lock s
WHERE request != 0 AND sid1 = mid1
AND sid2 = mid2)
)
ORDER BY id1, id2, mrequest;
通过以上查询知道了sid和 SERIAL#就可以开杀了
alter system kill session 'sid,SERIAL#';
怎么知道数据库表已经锁表了
通过查询结果中的object_id,可以查询到具体被锁的对象再给你看看我查到的一些关于锁的资料:锁有以下几种模式: 0:none 1:null 空 2:Row-S 行共享(RS):共享表锁 3:Row-X 行专用(RX):用于行的修改 4:Share 共享锁(S):阻止其他DML *** 作 5:S/Row-X 共享行专用(SRX):阻止其他事务 *** 作 6:exclusive 专用(X):独立访问使用数字越大锁级别越高, 影响的 *** 作越多。一般的查询语句如select from ;是小于2的锁, 有时会在v$locked_object出现。 select from for update; 是2的锁。当对话使用for update子串打开一个游标时,所有返回集中的数据行都将处于行级(Row-X)独占式锁定,其他对象只能查询这些数据行,不能进行update、delete或selectfor update *** 作。 insert / update / delete ; 是3的锁。没有mit之前插入同样的一条记录会没有反应, 因为后一个3的锁会一直等待上一个3的锁, 我们必须释放掉上一个才能继续工作。创建索引的时候也会产生3,4级别的锁。 locked_mode为2,3,4不影响DML(insert,delete,update,select) *** 作, 但DDL(alter,drop等) *** 作会提示ora-00054错误。有主外键约束时 update / delete ; 可能会产生4,5的锁。 DDL语句时是6的锁。以DBA角色, 查看当前数据库里锁的情况可以用如下SQL语句: select object_id,session_id,locked_mode from v$locked_object; select t2username,t2sid,t2serial#,t2logon_time from v$locked_object t1,v$session t2 where t1session_id=t2sid order by t2logon_time; 如果有长期出现的一列,可能是没有释放的锁。我们可以用下面SQL语句杀掉长期没有释放非正常的锁: alter system kill session 'sid,serial#'; 如果出现了锁的问题, 某个DML *** 作可能等待很久没有反应。当你采用的是直接连接数据库的方式,也不要用OS系统命令 $kill process_num 或者 $kill -9 process_num来终止用户连接,因为一个用户进程可能产生一个以上的锁, 杀OS进程并不能彻底清除锁的问题。
如何实现数据库锁表及解锁
锁表:
LOCK TABLES tablename WRITE;LOCK TABLES tablename READ;解锁
UNLOCK TABLES;
数据库中如何释锁表进程
锁表查询的代码有以下的形式:
select count() from v$locked_object;
select from v$locked_object;
查看哪个表被锁
select bowner,bobject_name,asession_id,alocked_mode from v$locked_object a,dba_objects b where bobject_id = aobject_id;查看是哪个session引起的
select busername,bsid,bserial#,logon_time from v$locked_object a,v$session b where asession_id = bsid order by blogon_time;杀掉对应进程
执行命令:alter system kill session'1025,41';
其中1025为sid,41为serial#
怎么知道数据库表已经锁表了
先回答你的问题:
select from v$locked_object;
可以获得被锁的对象的object_id及产生锁的会话sid。
通过查询结果中的object_id,可以查询到具体被锁的对象
再给你看看我查到的一些关于锁的资料:
锁有以下几种模式:
0:none
1:null 空
2:Row-S 行共享(RS):共享表锁
3:Row-X 行专用(RX):用于行的修改
4:Share 共享锁(S):阻止其他DML *** 作
5:S/Row-X 共享行专用(SRX):阻止其他事务 *** 作
6:exclusive 专用(X):独立访问使用
数字越大锁级别越高, 影响的 *** 作越多。
一般的查询语句如select from ;是小于2的锁, 有时会在v$locked_object出现。
select from for update; 是2的锁。
当对话使用for update子串打开一个游标时,
所有返回集中的数据行都将处于行级(Row-X)独占式锁定,
其他对象只能查询这些数据行,不能进行update、delete或selectfor update *** 作。
insert / update / delete ; 是3的锁。
没有mit之前插入同样的一条记录会没有反应,
因为后一个3的锁会一直等待上一个3的锁, 我们必须释放掉上一个才能继续工作。
创建索引的时候也会产生3,4级别的锁。
locked_mode为2,3,4不影响DML(insert,delete,update,select) *** 作,
但DDL(alter,drop等) *** 作会提示ora-00054错误。
有主外键约束时 update / delete ; 可能会产生4,5的锁。
DDL语句时是6的锁。
以DBA角色, 查看当前数据库里锁的情况可以用如下SQL语句:
select object_id,session_id,locked_mode from v$locked_object;
select t2username,t2sid,t2serial#,t2logon_time
from v$locked_object t1,v$session t2
where t1session_id=t2sid order by t2logon_time;
如果有长期出现的一列,可能是没有释放的锁。
我们可以用下面SQL语句杀掉长期没有释放非正常的锁:
alter system kill session 'sid,serial#';
如果出现了锁的问题, 某个DML *** 作可能等待很久没有反应。
当你采用的是直接连接数据库的方式,
也不要用OS系统命令 $kill process_num 或者 $kill -9 process_num来终止用户连接,
因为一个用户进程可能产生一个以上的锁, 杀OS进程并不能彻底清除锁的问题。
记得在数据库级别用alter system kill session 'sid,serial#';杀掉不正常的锁。
这里还讲了一些:
>>
for update 的作用是在查询的时候为行加上排它锁,当一个事务的 *** 作未完成时候,其他事务可以读取但是不能写入或更新。
它的典型使用场景是 高并发并且对于数据的准确性有很高要求 ,比如金钱、库存等,一般这种 *** 作都是很长一串并且开启事务的,假如现在要对库存进行 *** 作,在刚开始读的时候是1,然后马上另外一个进程将库存更新为0了,但事务还没结束,会一直用1进行后续的逻辑,就会有问题,所以需要用for upate 加锁防止出错。
行锁的具体实现算法有三种:record lock、gap lock以及next-key lock。
只在可重复读或以上隔离级别下的特定 *** 作才会取得 gap lock 或 next-key lock,在 Select、Update 和 Delete 时,除了基于唯一索引的查询之外,其它索引查询时都会获取 gap lock 或 next-key lock,即锁住其扫描的范围。主键索引也属于唯一索引,所以主键索引是不会使用 gap lock 或 next-key lock
for update 仅适用于InnoDB,并且必须开启事务,在begin与commit之间才生效。
select 语句默认不获取任何锁,所以是可以读被其它事务持有排它锁的数据的!
InnoDB 既实现了行锁,也实现了表锁。
当有明确指定的主键/索引时候,是行级锁,否则是表级锁
假设表 user,存在有id跟name字段,id是主键,有5条数据。
明确指定主键,并且有此记录,行级锁
无主键/索引,表级锁
主键/索引不明确,表级锁
明确指定主键/索引,若查无此记录,无锁
参考博文:
>
以上就是关于请教一下mysql 行锁命令是什么全部的内容,包括:请教一下mysql 行锁命令是什么、数据库锁表是什么意思、MySQL - for update 行锁 表锁等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)