当前位置：首页 » 编程语言 » sql语言执行加锁
扩展阅读
提分平台的账号密码是什么 2023-08-31 22:07:10
webinf下怎么引入js 2023-08-31 21:54:13
堡垒机怎么打开web 2023-08-31 21:54:11

sql语言执行加锁

发布时间: 2023-03-05 06:02:40

㈠ 用sql语句，怎么解决mysql数据库死锁

MySQL死锁问题的相关知识是本文我们主要要介绍的内容，接下来我们就来一一介绍这部分内容，希望能够对您有所帮助。
1、MySQL常用存储引擎的锁机制
MyISAM和MEMORY采用表级锁(table-level locking)
BDB采用页面锁(page-level locking)或表级锁，默认为页面锁
InnoDB支持行级锁(row-level locking)和表级锁，默认为行级锁
2、各种锁特点
表级锁：开销小，加锁快;不会出现死锁;锁定粒度大，发生锁冲突的概率最高，并发度最低
行级锁：开销大，加锁慢;会出现死锁;锁定粒度最小，发生锁冲突的概率最低，并发度也最高
页面锁：开销和加锁时间界于表锁和行锁之间;会出现死锁;锁定粒度界于表锁和行锁之间，并发度一般
3、各种锁的适用场景
表级锁更适合于以查询为主，只有少量按索引条件更新数据的应用，如Web应用
行级锁则更适合于有大量按索引条件并发更新数据，同时又有并发查询的应用，如一些在线事务处理系统
4、死锁
是指两个或两个以上的进程在执行过程中，因争夺资源而造成的一种互相等待的现象，若无外力作用，它们都将无法推进下去。
表级锁不会产生死锁。所以解决死锁主要还是针对于最常用的InnoDB。
5、死锁举例分析
在MySQL中，行级锁并不是直接锁记录，而是锁索引。索引分为主键索引和非主键索引两种，如果一条sql语句操作了主键索引，MySQL就会锁定这条主键索引;如果一条语句操作了非主键索引，MySQL会先锁定该非主键索引，再锁定相关的主键索引。
在UPDATE、DELETE操作时，MySQL不仅锁定WHERE条件扫描过的所有索引记录，而且会锁定相邻的键值，即所谓的next-key locking。
例如，一个表db。tab_test，结构如下：
id：主键;
state：状态;
time：时间;
索引：idx_1(state，time)
出现死锁日志如下：
?***(1) TRANSACTION:
?TRANSACTION 0 677833455, ACTIVE 0 sec, process no 11393, OSthread id 278546 starting index read
?mysql tables in use 1, locked 1
?LOCK WAIT 3 lock struct(s), heap size 320
?MySQL thread id 83, query id 162348740 dcnet03 dcnet Searching rows for update
?update tab_test set state=1064,time=now() where state=1061 and time < date_sub(now(), INTERVAL 30 minute) (任务1的sql语句)
?***(1) WAITING FOR THIS LOCK TO BE GRANTED: (任务1等待的索引记录)
?RECORD LOCKS space id 0 page no 849384 n bits 208 index `PRIMARY` of table `db/tab_test` trx id 0 677833455 _mode X locks rec but not gap waiting
?Record lock, heap no 92 PHYSICAL RECORD: n_fields 11; compact format; info bits 0
?0: len 8; hex 800000000097629c; asc b ;; 1: len 6; hex 00002866eaee; asc (f ;; 2: len 7; hex 00000d40040110; asc @ ;; 3: len 8; hex 80000000000050b2; asc P ;; 4: len 8; hex 800000000000502a; asc P*;; 5: len 8; hex 8000000000005426; asc T&;; 6: len 8; hex 800012412c66d29c; asc A,f ;; 7: len 23; hex 8616e642e706870; asc xxx.com/;; 8: len 8; hex 800000000000042b; asc +;; 9: len 4; hex 474bfa2b; asc GK +;; 10: len 8; hex 8000000000004e24; asc N$;;
?*** (2) TRANSACTION:
?TRANSACTION 0 677833454, ACTIVE 0 sec, process no 11397, OS thread id 344086 updating or deleting, thread declared inside InnoDB 499
?mysql tables in use 1, locked 1
?3 lock struct(s), heap size 320, undo log entries 1
?MySQL thread id 84, query id 162348739 dcnet03 dcnet Updating update tab_test set state=1067,time=now () where id in (9921180) (任务2的sql语句)
?*** (2) HOLDS THE LOCK(S): (任务2已获得的锁)
?RECORD LOCKS space id 0 page no 849384 n bits 208 index `PRIMARY` of table `db/tab_test` trx id 0 677833454 lock_mode X locks rec but not gap
?Record lock, heap no 92 PHYSICAL RECORD: n_fields 11; compact format; info bits 0
?0: len 8; hex 800000000097629c; asc b ;; 1: len 6; hex 00002866eaee; asc (f ;; 2: len 7; hex 00000d40040110; asc @ ;; 3: len 8; hex 80000000000050b2; asc P ;; 4: len 8; hex 800000000000502a; asc P*;; 5: len 8; hex 8000000000005426; asc T&;; 6: len 8; hex 800012412c66d29c; asc A,f ;; 7: len 23; hex 8616e642e706870; asc uploadfire.com/hand.php;; 8: len 8; hex 800000000000042b; asc +;; 9: len 4; hex 474bfa2b; asc GK +;; 10: len 8; hex 8000000000004e24; asc N$;;
?*** (2) WAITING FOR THIS LOCK TO BE GRANTED: (任务2等待的锁)
?RECORD LOCKS space id 0 page no 843102 n bits 600 index `idx_1` of table `db/tab_test` trx id 0 677833454 lock_mode X locks rec but not gap waiting
?Record lock, heap no 395 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
?0: len 8; hex 8000000000000425; asc %;; 1: len 8; hex 800012412c66d29c; asc A,f ;; 2: len 8; hex 800000000097629c; asc b ;;
?*** WE ROLL BACK TRANSACTION (1)
?(回滚了任务1，以解除死锁)
原因分析：
当“update tab_test set state=1064,time=now() where state=1061 and time < date_sub(now(), INTERVAL 30 minute)”执行时，MySQL会使用idx_1索引，因此首先锁定相关的索引记录，因为idx_1是非主键索引，为执行该语句，MySQL还会锁定主键索引。
假设“update tab_test set state=1067,time=now () where id in (9921180)”几乎同时执行时，本语句首先锁定主键索引，由于需要更新state的值，所以还需要锁定idx_1的某些索引记录。
这样第一条语句锁定了idx_1的记录，等待主键索引，而第二条语句则锁定了主键索引记录，而等待idx_1的记录，这样死锁就产生了。
6、解决办法
拆分第一条sql，先查出符合条件的主键值，再按照主键更新记录：
?select id from tab_test where state=1061 and time < date_sub(now(), INTERVAL 30 minute);
?update tab_test state=1064,time=now() where id in(......);

㈡ SQL Server表锁定原理以及如何解除锁定

1. 数据库表锁定原理

1.1 目前的C/S,B/S结构都是多用户访问数据库,每个时间点会有成千上万个user来访问DB,其中也会同时存取同一份数据,会造成数据的不一致性或者读脏数据.

SELECT
request_session_idasSpid,
Coalesce(s.name+'.'+o.name+isnull('.'+i.name,''),
s2.name+'.'+o2.name,
db.name)ASObject,
l.resource_typeasType,
request_modeasMode,
request_statusasStatus
FROMsys.dm_tran_locksl
LEFTJOINsys.partitionsp
ONl.resource_associated_entity_id=p.hobt_id
LEFTJOINsys.indexesi
ONp.object_id=i.object_id
ANDp.index_id=i.index_id
LEFTJOINsys.objectso
ONp.object_id=o.object_id
LEFTJOINsys.schemass
ONo.schema_id=s.schema_id
LEFTJOINsys.objectso2
ONl.resource_associated_entity_id=o2.object_id
LEFTJOINsys.schemass2
ONo2.schema_id=s2.schema_id
LEFTJOINsys.databasesdb
ONl.resource_database_id=db.database_id
WHEREresource_database_id=DB_ID()
ORDERBYSpid,Object,CASEl.resource_type
When'database'Then1
when'object'then2
when'page'then3
when'key'then4
Else5end

㈢ 怎样写sql语句可以加上行级排它锁

看你需要加哪种类型的锁：
HOLDLOCK 将共享锁保留到事务完成，而不是在相应的表、行或数据页不再需要时就立即释放锁。HOLDLOCK 等同于 SERIALIZABLE。
NOLOCK 不要发出共享锁，并且不要提供排它锁。当此选项生效时，可能会读取未提交的事务或一组在读取中间回滚的页面。有可能发生脏读。仅应用于 SELECT 语句。
PAGLOCK 在通常使用单个表锁的地方采用页锁。
READCOMMITTED 用与运行在提交读隔离级别的事务相同的锁语义执行扫描。默认情况下，SQL Server 2000 在此隔离级别上操作。
READPAST 跳过锁定行。此选项导致事务跳过由其它事务锁定的行（这些行平常会显示在结果集内），而不是阻塞该事务，使其等待其它事务释放在这些行上的锁。 READPAST 锁提示仅适用于运行在提交读隔离级别的事务，并且只在行级锁之后读取。仅适用于 SELECT 语句。
READUNCOMMITTED 等同于 NOLOCK。
REPEATABLEREAD 用与运行在可重复读隔离级别的事务相同的锁语义执行扫描。
ROWLOCK 使用行级锁，而不使用粒度更粗的页级锁和表级锁。
SERIALIZABLE 用与运行在可串行读隔离级别的事务相同的锁语义执行扫描。等同于 HOLDLOCK。
TABLOCK 使用表锁代替粒度更细的行级锁或页级锁。在语句结束前，SQL Server 一直持有该锁。但是，如果同时指定 HOLDLOCK，那么在事务结束之前，锁将被一直持有。
TABLOCKX 使用表的排它锁。该锁可以防止其它事务读取或更新表，并在语句或事务结束前一直持有。
UPDLOCK 读取表时使用更新锁，而不使用共享锁，并将锁一直保留到语句或事务的结束。UPDLOCK 的优点是允许您读取数据（不阻塞其它事务）并在以后更新数据，同时确保自从上次读取数据后数据没有被更改。
XLOCK 使用排它锁并一直保持到由语句处理的所有数据上的事务结束时。可以使用 PAGLOCK 或 TABLOCK 指定该锁，这种情况下排它锁适用于适当级别的粒度。

㈣ 用SQL如何给DB2表加锁和解锁

在DB2的命令行中输入：
update monitor switches using lock on table on
然后打开另一个DB2命令窗口执行我的那个被吊死的Update语句。
然后在第一个DB2命令窗口执行： [@more@]get snapshot for locks on Database_Name(你的数据库的名字)> locks.TXT

然后，可以看到第一个DB2的窗口有一个信息输出，把这些信息输出到TXT中，大致如下：

应用程序句柄 = 36
应用程序标识 = AC100C47.IC05.00F6C6095828
序号 = 0246
应用程序名 = java.exe
CONNECT 授权标识 = DB2ADMIN
应用程序状态 = UOW 正在等待
状态更改时间 = 未收集
应用程序代码页 = 1208
挂起的锁定 = 0
总计等待时间（毫秒） = 0

应用程序句柄 = 43
应用程序标识 = *LOCAL.DB2.060512054331
序号 = 2273
应用程序名 = java.exe
CONNECT 授权标识 = DB2ADMIN
应用程序状态 = 联合请求暂挂
状态更改时间 = 未收集
应用程序代码页 = 1208
挂起的锁定 = 6
总计等待时间（毫秒） = 0

锁定列表
锁定名称 = 0x031F9052000000000000000055
锁定属性 = 0x00000000
发行版标志 = 0x40000000
锁定计数 = 255
挂起计数 = 0
锁定对象名 = 0
对象类型 = 内部
方式 = S

锁定名称 = 0x26800000000000000000000044
锁定属性 = 0x00000000
发行版标志 = 0x40000000
锁定计数 = 1
挂起计数 = 0
锁定对象名 = 0
对象类型 = 内部
方式 = S

锁定名称 = 0x020006000F1700000000000052
锁定属性 = 0x00000000
发行版标志 = 0x00000001
锁定计数 = 1
挂起计数 = 0
锁定对象名 = 5903
对象类型 = 行
表空间名 = USERSPACE1
表模式 = DB2ADMIN
表名 = C_USER
方式 = NS

锁定名称 = 0x01000000010000000500BC0056
锁定属性 = 0x00000000
发行版标志 = 0x40000000
锁定计数 = 1
挂起计数 = 0
锁定对象名 = 0
对象类型 = 内部变化锁定
方式 = S

锁定名称 = 0x535953534E333030FD965C0641
锁定属性 = 0x00000000
发行版标志 = 0x40000000
锁定计数 = 1
挂起计数 = 0
锁定对象名 = 0
对象类型 = 内部方案锁定
方式 = S

锁定名称 = 0x02000600000000000000000054
锁定属性 = 0x00000000
发行版标志 = 0x00000001
锁定计数 = 1
挂起计数 = 0
锁定对象名 = 6
对象类型 = 表
表空间名 = USERSPACE1
表模式 = DB2ADMIN
表名 = C_USER
方式 = IS

应用程序句柄 = 557
应用程序标识 = *LOCAL.DB2.060512053913
序号 = 1254
应用程序名 = java.exe
CONNECT 授权标识 = DB2ADMIN
应用程序状态 = 联合请求暂挂
状态更改时间 = 未收集
应用程序代码页 = 1208
挂起的锁定 = 6
总计等待时间（毫秒） = 0

锁定列表
锁定名称 = 0x031F9052000000000000000055
锁定属性 = 0x00000000
发行版标志 = 0x40000000
锁定计数 = 255
挂起计数 = 0
锁定对象名 = 0
对象类型 = 内部
方式 = S

锁定名称 = 0x26800000000000000000000044
锁定属性 = 0x00000000
发行版标志 = 0x40000000
锁定计数 = 1
挂起计数 = 0
锁定对象名 = 0
对象类型 = 内部
方式 = S

锁定名称 = 0x02000600071D00000000000052
锁定属性 = 0x00000000
发行版标志 = 0x00000001
锁定计数 = 1
挂起计数 = 0
锁定对象名 = 7431
对象类型 = 行
表空间名 = USERSPACE1
表模式 = DB2ADMIN
表名 = C_USER
方式 = NS

锁定名称 = 0x01000000010000000500BC0056
锁定属性 = 0x00000000
发行版标志 = 0x40000000
锁定计数 = 1
挂起计数 = 0
锁定对象名 = 0
对象类型 = 内部变化锁定
方式 = S

锁定名称 = 0x535953534E333030FD965C0641
锁定属性 = 0x00000000
发行版标志 = 0x40000000
锁定计数 = 1
挂起计数 = 0
锁定对象名 = 0
对象类型 = 内部方案锁定
方式 = S

锁定名称 = 0x02000600000000000000000054
锁定属性 = 0x00000000
发行版标志 = 0x00000001
锁定计数 = 1
挂起计数 = 0
锁定对象名 = 6
对象类型 = 表
表空间名 = USERSPACE1
表模式 = DB2ADMIN
表名 = C_USER
方式 = IS

其中应用程序句柄43和557的状态都是死锁了，猜测是这2个应用争用DB2的表，造成死锁，根据日志提示，在DB2的命令窗口输入：
force application (43)
force application (557)
提示这个操作是异步的，我执行list applicaions，结果进程中还有那2个进程，那2个进程可能是在执行比较大的操作，需要耐心等待，如何还不行，则使用下面的命令来强制所有的应用都停止，然后重启DB2：
force application all
terminate
db2stop force
db2start
如果DB2在Window上，则可以使用“控制中心”->实例->右键“应用程序”，可以看到当前的锁定情况，并且可以强行关闭某个进程，也可以显示“锁定链”。

㈤ sql 怎样加行锁

updatetable_namewith(rowlock)setcolumn_name=new_valuewhereyour_condition

㈥ SQL 存储过程如何加锁

create or replace procere testp is
LN number;
jcr_lockhandle varchar2(128);
begin

DBMS_LOCK.allocate_unique('Lock', jcr_lockhandle);--针对当前session加锁
LOOP
LN := DBMS_LOCK.request ( jcr_lockhandle, TIMEOUT => 0);
IF LN NOT IN (0, 4)--判断是否被别session锁住
THEN
DBMS_OUTPUT.put_line ('Already run...');
DBMS_LOCK.sleep (2);--已经被人锁住，休眠2秒
ELSE
EXIT;--没有锁，退出轮询
END IF;
END LOOP;

dbms_output.put_line('1'); ----你要加锁的业务逻辑哦

LN := DBMS_LOCK.release ( jcr_lockhandle);--释放资源

end ;

㈦ DB2中如何使用sql语句进行表锁

写sql语句的时候 在后面加上一个 for update 你在去执行 增加 删除的操作 这样子表就会容易锁住啦。

㈧ mysql读数据时怎么加写锁

加锁情况与死锁原因分析


为方便大家复现，完整表结构和数据如下：

CREATE TABLE `t3` (
`c1` int(11) NOT NULL AUTO_INCREMENT,
`c2` int(11) DEFAULT NULL,
PRIMARY KEY (`c1`),
UNIQUE KEY `c2` (`c2`)
) ENGINE=InnoDB

insert into t3 values(1,1),(15,15),(20,20);


在 session1 执行 commit 的瞬间，我们会看到 session2、session3 的其中一个报死锁。这个死锁是这样产生的：

  • 1.session1 执行 delete 会在唯一索引 c2 的 c2 = 15 这一记录上加 X lock（也就是在MySQL 内部观测到的：X Lock but not gap）；

  • 2.session2 和 session3 在执行 insert 的时候，由于唯一约束检测发生唯一冲突，会加 S Next-Key Lock，即对 (1,15] 这个区间加锁包括间隙，并且被 seesion1 的 X Lock 阻塞，进入等待；

  • 3.session1 在执行 commit 后，会释放 X Lock，session2 和 session3 都获得 S Next-Key Lock；

  • 4.session2 和 session3 继续执行插入操作，这个时候 INSERT INTENTION LOCK（插入意向锁）出现了，并且由于插入意向锁会被 gap 锁阻塞，所以 session2 和 session3 互相等待，造成死锁。

    • 死锁日志如下：

    INSERT INTENTION LOCK

    在之前的死锁分析第四点，如果不分析插入意向锁，也是会造成死锁的，因为插入最终还是要对记录加 X Lock 的，session2 和 session3 还是会互相阻塞互相等待。

    但是插入意向锁是客观存在的，我们可以在官方手册中查到，不可忽略：

  • Prior to inserting the row, a type of gap lock called an insert intention gap lock is set. This lock signals the intent to insert in such a way that multiple transactions inserting into the same index gap need not wait for each other if they are not inserting at the same position within the gap.

    • 插入意向锁其实是一种特殊的 gap lock，但是它不会阻塞其他锁。假设存在值为 4 和 7 的索引记录，尝试插入值 5 和 6 的两个事务在获取插入行上的排它锁之前使用插入意向锁锁定间隙，即在（4，7）上加 gap lock，但是这两个事务不会互相冲突等待。

    当插入一条记录时，会去检查当前插入位置的下一条记录上是否存在锁对象，如果下一条记录上存在锁对象，就需要判断该锁对象是否锁住了 gap。如果 gap 被锁住了，则插入意向锁与之冲突，进入等待状态（插入意向锁之间并不互斥）。总结一下这把锁的属性：

  • 1. 它不会阻塞其他任何锁；

  • 2. 它本身仅会被 gap lock 阻塞。

    • 在学习 MySQL 过程中，一般只有在它被阻塞的时候才能观察到，所以这也是它常常被忽略的原因吧...

    GAP LOCK

    在此例中，另外一个重要的点就是 gap lock，通常情况下我们说到 gap lock 都只会联想到 REPEATABLE-READ 隔离级别利用其解决幻读。但实际上在 READ-COMMITTED 隔离级别，也会存在 gap lock ，只发生在：唯一约束检查到有唯一冲突的时候，会加 S Next-key Lock，即对记录以及与和上一条记录之间的间隙加共享锁。

    通过下面这个例子就能验证：

    这里 session1 插入数据遇到唯一冲突，虽然报错，但是对 (15,20] 加的 S Next-Key Lock 并不会马上释放，所以 session2 被阻塞。另外一种情况就是本文开始的例子，当 session2 插入遇到唯一冲突但是因为被 X Lock 阻塞，并不会立刻报错 “Duplicate key”，但是依然要等待获取 S Next-Key Lock 。

    有个困惑很久的疑问：出现唯一冲突需要加 S Next-Key Lock 是事实，但是加锁的意义是什么？还是说是通过 S Next-Key Lock 来实现的唯一约束检查，但是这样意味着在插入没有遇到唯一冲突的时候，这个锁会立刻释放，这不符合二阶段锁原则。这点希望能与大家一起讨论得到好的解释。

    如果是在 REPEATABLE-READ，除以上所说的唯一约束冲突外，gap lock 的存在是这样的：

    普通索引（非唯一索引）的S/X Lock，都带 gap 属性，会锁住记录以及前1条记录到后1条记录的左闭右开区间，比如有[4,6,8]记录，delete 6，则会锁住[4,8）整个区间。

    对于 gap lock，相信 DBA 们的心情是一样一样的，所以我的建议是：

  • 1. 在绝大部分的业务场景下，都可以把 MySQL 的隔离界别设置为 READ-COMMITTED；

  • 2. 在业务方便控制字段值唯一的情况下，尽量减少表中唯一索引的数量。

    • 锁冲突矩阵

    前面我们说的 GAP LOCK 其实是锁的属性，另外我们知道 InnoDB 常规锁模式有：S 和 X，即共享锁和排他锁。锁模式和锁属性是可以随意组合的，组合之后的冲突矩阵如下，这对我们分析死锁很有帮助：

阅读全文

与sql语言执行加锁相关的内容

本站内容整理源于互联网，如有问题请联系解决。
Copyright design: www.gotrillian.com since 2022