SQL锁表解决并发性

在数据库开发过程中,不得不考虑并发性的问题,因为很有可能当别人正在更新表中记录时,你又从该表中读数据,那你读出来的数据有可能就不是你希望得到的数据。可以说有些数据同时只能有一个事物去更新,否则最终显示给用户的数据不是数据库中现存的数据。锁表就限制不同的事物在同一时间内不允许同时操作一张表,实例很简单,可以用select来锁定整张表,那别人就不可能更新或是读取表的记录。
select
* from dbo.Employee with(holdlock);
with关键字来设置锁表的方式。下面是with括号内关键字的书名:  
NOLOCK(不加锁) 
此选项被选中时,SQL
Server 在读取或修改数据时不加任何锁。 在这种情况下,用户有可能读取到未完成事务(Uncommited Transaction)或回滚(Roll
Back)中的数据, 即所谓的“脏数据”。
HOLDLOCK(保持锁) 
此选项被选中时,SQL Server
会将此共享锁保持至整个事务结束,而不会在途中释放。
UPDLOCK(修改锁) 
此选项被选中时,SQL Server
在读取数据时使用修改锁来代替共享锁,并将此锁保持至整个事务或命令结束。使用此选项能够保证多个进程能同时读取数据但只有该进程能修改数据。
TABLOCK(表锁) 
此选项被选中时,SQL
Server 将在整个表上置共享锁直至该命令结束。
这个选项保证其他进程只能读取而不能修改数据。
PAGLOCK(页锁) 
此选项为默认选项, 当被选中时,SQL Server
使用共享页锁。
TABLOCKX(排它表锁) 
此选项被选中时,SQL Server
将在整个表上置排它锁直至该命令或事务结束。这将防止其他进程读取或修改表中的数据。
 
HOLDLOCK
持有共享锁,直到整个事务完成,应该在被锁对象不需要时立即释放,等于SERIALIZABLE事务隔离级别 
NOLOCK
语句执行时不发出共享锁,允许脏读 ,等于 READ UNCOMMITTED事务隔离级别 
PAGLOCK
在使用一个表锁的地方用多个页锁 
READPAST 让sql server跳过任何锁定行,执行事务,适用于READ
UNCOMMITTED事务隔离级别只跳过RID锁,不跳过页,区域和表锁 
ROWLOCK 强制使用行锁 
TABLOCKX
强制使用独占表级锁,这个锁在事务期间阻止任何其他事务使用这个表 
UPLOCK 强制在读表时使用更新而不用共享锁

 
呵呵,上面的够研究一会的了,我常用的就是holdlock和tablockx,holdlock是锁定一张表,但是别的事物还是可以读取的,但不能更新和插入。对于tabllockx,在事物未提交前,连读取都是阻塞的,直到另一事物提交后才可以读取,这样就保证了数据的一致性。不过锁表需要包含在事物内,否则锁表是不起作用的。附件当中有示例可以下载。

SQL锁表解决并发性,布布扣,bubuko.com

时间: 2024-10-12 13:00:23

SQL锁表解决并发性的相关文章

PHP.37-扩展-锁机制解决并发-MySQL锁、PHP文件锁

锁机制适用于高并发场景:高并发订单.秒杀-- apache压力测试 Mysql锁详解 语法 加锁:LOCK TABLE 表名1 READ|WRITE, 表名2 READ|WRITE .................. 解锁:UNLOCK TABLES Read:读锁|共享锁 : 所有的客户端只能读这个表不能写这个表 Write:写锁|排它锁: 所有当前锁定客户端可以操作这个表,其他客户端只能阻塞 注意:在锁表的过程中只能操作被锁定的表,如果要操作其他表,必须把所有要操作的表都锁定起来!! PH

数据库被锁表解决锁表语句

步骤一:查询被锁表 SELECT request_session_id spid,OBJECT_NAME(resource_associated_entity_id)tableName FROM sys.dm_tran_locks WHERE resource_type='OBJECT ' 步骤二:结束锁表进程kill 52 原文地址:https://www.cnblogs.com/paulcode/p/11557893.html

SQL锁行 解决多台服务器发送统一请求并发问题

锁行信息SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED 存储过程:SET Transaction Isolation Level Read语法的四种情况 这几天一直在弄存储过程,现在在这里跟大伙共享下资料: SET Transaction Isolation Level Read UNCOMMITTED 使用这句东东呢可以分为四种情况,现在就在这里逐一介绍: 第一种情况: READ   COMMITTED 这句的作用是: 指定在读取数据时控制共享

77. sqlserver 锁表解决方式

select request_session_id spid, OBJECT_NAME(resource_associated_entity_id) tableName from sys.dm_tran_locks where resource_type='OBJECT ' kill 84

【巨杉数据库SequoiaDB】巨杉 Tech | 并发性与锁机制解析与实践

01 概述 数据库是一个多用户使用的共享资源.当多个用户并发地存取数据时,在数据库中就会产生多个事务同时存取同一数据的情况.若对并发操作不加控制就可能会读取和存储不正确的数据,破坏数据库的一致性.加锁是实现数据库并发控制的一个非常重要的技术.当事务在对某个数据对象进行操作前,先向系统发出请求,对其加锁.加锁后事务就对该数据对象有了一定的控制,在该事务释放锁之前,其他的事务不能对此数据对象进行更新操作. OLTP 场景下通常要求具有很高的并发性.并发事务实际上取决于资源的使用状况,原则上应尽量减少

多用户操作一个数据表时的并发性操作

事务处理(多用户同时操作一条信息时是用-并发) 在c/s或多层中,如果两个用户同时打开一条记录,修改后提交会产生更新冲突: 据说办法有二:1.打开同时锁定表的记录 2.浦获错误,撤消其中一个用户的修改,但是很少见到具体实现的代码:请大家告诉具体的代码怎么写: 1.打开时如何锁定一条记录? 2.如何扑获更新错误?在delphi中调试时会报“该记录读出后已经被再次修改”,而在运行时如何判定错误为更新冲突?因为更新时其他的错误如输入不合法等也可能报错,如何把更新冲突和其他的分开? ==========

利用锁机制解决商品表和库存表并发问题

锁机制 问题:当一个脚本被一个客户端访问都正常,但当多个客户端同时并发访问时,这个脚本的结果会出现不正确,这个问题需要使用锁机制来解决.在我们这个网站中需要用到锁的地方就是高并发下定单时减少商品库存量时. 比如例子1: 有一个A 表里面一个ID数字: 现在写一个脚本操作这个A表,每次访问把ID减少: 这个脚使用AB模拟10个用户并发访问时会发现减少的数量并不是10: . 例子2:在高并发下定单时如果要减少库存量,那么库存就会出问题: 加锁之前: 加锁之后: 现在有两种锁机制:MYSQL中的表锁和

乐观锁与悲观锁——解决并发问题(转)

引言 为什么需要锁(并发控制)? 在多用户环境中,在同一时间可能会有多个用户更新相同的记录,这会产生冲突.这就是著名的并发性问题. 典型的冲突有: 丢失更新:一个事务的更新覆盖了其它事务的更新结果,就是所谓的更新丢失.例如:用户A把值从6改为2,用户B把值从2改为6,则用户A丢失了他的更新. 脏读:当一个事务读取其它完成一半事务的记录时,就会发生脏读取.例如:用户A,B看到的值都是6,用户B把值改为2,用户A读到的值仍为6. 为了解决这些并发带来的问题. 我们需要引入并发控制机制. 并发控制机制

乐观锁与悲观锁——解决并发问题

悲观锁(Pessimistic Lock), 顾名思义,就是很悲观,每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁,这样别人想拿这个数据就会block直到它拿到锁.传统的关系型数据库里边就用到了很多这种锁机制,比如行锁,表锁等,读锁,写锁等,都是在做操作之前先上锁. 乐观锁(Optimistic Lock), 顾名思义,就是很乐观,每次去拿数据的时候都认为别人不会修改,所以不会上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据,可以使用版本号等机制.乐观锁适用于