求助,怎样锁定Sql中的某一条记录

宜兴SEO 2011-02-15 09:52:33
如题,在做一个Web系统,在同一个时间,同一条记录是只可以一个人在修改,怎样才能做到这一点,Sql中可以锁定记录吗?
...全文
337 13 打赏 收藏 转发到动态 举报
AI 作业
写回复
用AI写文章
13 条回复
切换为时间正序
请发表友善的回复…
发表回复
kenriy 2011-02-15
  • 打赏
  • 举报
回复
事务机制的实现
wang329382414 2011-02-15
  • 打赏
  • 举报
回复
slect a1 from table1 with(UPLOCK ) where
wang329382414 2011-02-15
  • 打赏
  • 举报
回复
slect a1 from table1 with(UPLOCK )
LingKen 2011-02-15
  • 打赏
  • 举报
回复
我晕,说了这么多话,楼主也解决不了问题的,不如给点代码
  • 打赏
  • 举报
回复
数据库技术有几个核心的机制,比如:磁盘块存取(包括预取技术)以及将多条记录组织在磁盘块中、各种索引技术(起码要使用B+树)、事务、SQL编译和执行、分布式。

这是数据库技术最起码的功能,也是为什么选择数据库而不是xml文件之类的东西的本质特征。任何一本数据库技术的教科书都会包括这些内容,告诉你如何设计一个数据库系统。
  • 打赏
  • 举报
回复
[Quote=引用 6 楼 qq66866111 的回复:]

最头痛的是,如果加字段,或者把正在修改的ID存如缓存的话,那如果那人没修改玩,直接把浏览器关了,那就悲剧了~
[/Quote]

数据库是个成熟的东西,不是来研究的东西。不是什么自己编写一个字段的问题。

嗯,找一本30年前的数据库技术教程,其中可能有至少六分之一的篇幅都是关于事务机制的实现的。
  • 打赏
  • 举报
回复
数据库事务会保持ACID特性,它可以避免并行的Update同一个记录。如果你没有在你的.net程序中显式地启用数据库事务,SQL Server也会自动为每一条sql语句启用一个事务。所以单纯技术上说,你不用担心什么“多个人Update”的问题。

但是从技术上不用担心,并不等于从业务逻辑上不用担心。会解决技术问题,不一定会解决业务问题。你所说的“在同一时间”我看不明白是什么概念?!假如你是说一个人修改了一个记录,然后坐在电脑前发呆,然后再按“确认键”,如果你说的是这一个长事务时间,那么数据库是不适合来做这类事务问题的,只有你的业务逻辑程序来保证。
宜兴SEO 2011-02-15
  • 打赏
  • 举报
回复
最头痛的是,如果加字段,或者把正在修改的ID存如缓存的话,那如果那人没修改玩,直接把浏览器关了,那就悲剧了~
wuyq11 2011-02-15
  • 打赏
  • 举报
回复
修改表中标识,表示正在使用
锁机制,维持几秒
peilianhai 2011-02-15
  • 打赏
  • 举报
回复
我理解应该是不止一个人都打开一修改页面,当更新时,做的验证

sql 可以设置一修改字段
人一,人二同时要修改
人一 修改完,同时 同步 修改时间字段

人二,更新时,判断,读取到的 修改时间,是否与数据库修改时间字段 相同,如果不同,提示有人更改过
相同,可以更新
MOTA 2011-02-15
  • 打赏
  • 举报
回复

在看论文的过程中突然出现了一个自己很陌生的术语——乐观并发控制,在网上展开了搜查,看了之后终于明白了其中的含义。乐观并发事务和悲观并发事务的区别如下:
悲观并发控制
一个锁定系统,可以阻止用户以影响其他用户的方式修改数据。如果用户执行的操作导致应用了某个锁,只有这个锁的所有者释放该锁,其他用户才能执行与该锁冲突的操作。这种方法之所以称为悲观并发控制,是因为它主要用于数据争用激烈的环境中,以及发生并发冲突时用锁保护数据的成本低于回滚事务的成本的环境中。
乐观并发控制
在乐观并发控制中,用户读取数据时不锁定数据。当一个用户更新数据时,系统将进行检查,查看该用户读取数据后其他用户是否又更改了该数据。如果其他用户更新了数据,将产生一个错误。一般情况下,收到错误信息的用户将回滚事务并重新开始。这种方法之所以称为乐观并发控制,是由于它主要在以下环境中使用:数据争用不大且偶尔回滚事务的成本低于读取数据时锁定数据的成本。
具体的区别与实例说明如下:

悲观并发控制:假设A和B需要在SCC(Source Code Control)上修改同一个文件,那么在A锁定这个文件并修改的过程中,B无法修改这个文件,他只能等待A解锁文件后,他才能修改。由此可见,悲观并发控制是强调控制在前,确保整个过程不会出现文件版本的冲突。这样做会使得系统效率损耗在加锁机制上,尤其是加锁机制需要用到低速的外部存储(比如FileLocking)时,然而这样做就降低了事务的并发性,尤其是事务之间本来就不存在冲突的情况下。例如在A修改数据的时候,B只能等待。

由此可见,悲观并发控制通过使用显式的加锁机制或者时间戳,对每一个事务进行增量同步校验。如果加锁机制的成本较高的话,悲观并发控制就会出现一些弊端。首先就是效率问题,尤其是使用低效率的外部存储系统实现加锁机制时,这样的问题会更加突出。其次,在不会出现冲突的事务处理(例如只读型事务)中,使用加锁机制就显得没有必要了,这样做只能增加系统负载。再次,这种方式降低了系统的并发性。

乐观并发控制:同样假设A和B需要在SCC上修改同一个文件,他们都将这个文件获取到自己的机器上,A修改完以后,就把文件上传到SCC上了,此时B也修改完了,当他也打算将文件上传时,系统会告知B,已经有人上传了,并出现一个错误。剩下的问题只能由B手动解决,例如B可以在SCC上将文件中更改的内容再次复制一遍。乐观并发控制使得系统效率损耗在事务的后期处理中,比如B必须手动的去修改他已经修改过的东西,然而这种控制方式在极少出现冲突的多事务处理中显得十分高效。

乐观并发控制将事务分为三个阶段:读取阶段、校验阶段以及写入阶段。在读取阶段,事务将数据写入本地缓冲(如上所述,A和B将文件都获取到自己的机器上),此时不会有任何校验操作;在校验阶段,系统会对所有的事务进行同步校验(比如在A或者B打算,但还没有,往SCC上写入更改后的文件时);在写入阶段,数据将被最终提交。在完成读取阶段以后,系统会对每个事务分派一个时间戳。

悲观并发控制中一个常见的问题就是死锁。例如A在修改文件T1,B在修改文件T2,他们分别锁定了这两个文件,假设T1和T2内容相关,B在修改T2的时候发现他还需要修改T1,可是T1却被A锁定;与此同时,A在修改T1的时候也发现了他还需要修改T2,可是T2又被B锁定了,这样就出现了死锁。当然,在实际操作中,这种情况可以由A和B协商解决,但是在错综复杂的多事务处理环境中,死锁将使得问题变得非常复杂。

这个是那个哥们说的东西

我做貌似是直接加个列 用来控制是否允许被修改。
宜兴SEO 2011-02-15
  • 打赏
  • 举报
回复
[Quote=引用 1 楼 q107770540 的回复:]
悲观式并发
[/Quote]怎么说?老大
q107770540 2011-02-15
  • 打赏
  • 举报
回复
悲观式并发
200多M 作者梁敬彬、梁敬弘 上篇 开启惊喜之门——带意识地学Oracle 第1章意识,少做事从学习开始 2 1.1 选择先学什么颇有学问 2 1.1.1 梁老师课堂爆笑开场 2 1.1.2 看似跑题的手机分类 4 1.1.3 学什么先了解做什么 5 1.2 善于规划分类才有效果 7 1.2.1 分类与角色密切相关 7 1.2.2 角色自我认识有讲究 9 1.3 明白学以致用方有意义 11 第2章震惊,体验物理体系之旅 13 2.1 必须提及的系列知识 13 2.2 物理体系从老余开店慢慢铺开 16 2.2.1 老余的三个小故事 16 2.2.1.1 顾客的尺寸 16 2.2.1.2 有效的调整 17 2.2.1.3 记录的习惯 18 2.2.2 体系结构原理初探 20 2.2.2.1 从一普通查询SQL说起20 2.2.2.2 老余故事终现用心良苦23 2.2.2.3 一起体会Oracle代价 27 2.2.3 体系结构原理再探 30 2.2.3.1 从一普通更新语句说起30 2.2.3.2 体系结构提交的探讨34 2.2.3.3 劳模的评选 38 2.2.3.4 回滚的研究 40 2.2.3.5 一致的查询 43 2.2.3.6 一致读的原理46 2.2.3.7 实践的体会 49 2.3 体系学习让SQL性能提升千倍 65 2.3.1 一起探索体系学习的意义 65 2.3.1.1 同学们不知所学何用 66 2.3.1.2 实际上大有用武之地 67 2.3.2 单车到飞船的经典之旅 70 2.3.2.1 未优化前,单车速度 70 2.3.2.2 绑定变量,摩托速度 72 2.3.2.3 静态改写,汽车速度 74 2.3.2.4 批量提交,动车速度 75 2.3.2.5 集合写法,飞机速度 77 2.3.2.6 直接路径,火箭速度 78 2.3.2.7 并行设置,飞船速度 79 2.3.3 精彩的总结与课程展望 80 2.3.3.1 最大的收获应该是思想80 2.3.3.2 老师的课程展望与规划81 第3章神奇,走进逻辑体系世界 84 3.1 长幼有序的逻辑体系 84 3.2 逻辑体系从老余养殖细细说起 85 3.2.1 农场之体系逻辑结构 85 3.2.2 农场之BLOCK漫谈89 3.2.3 农场之区与段 91 3.2.4 农场之表空间的分类 93 3.2.4.1 表空间与系统农场93 3.2.4.2 表空间与临时农场93 3.2.4.3 表空间与回滚农场94 3.2.5 逻辑结构之初次体会 94 3.2.5.1 逻辑结构之BLOCK 94 3.2.5.2 逻辑结构之TABLESPACE 95 3.2.5.3 逻辑结构之USER 97 3.2.5.4 逻辑结构之EXTENT 97 3.2.5.5 逻辑结构之SEGMENT 98 3.2.6 逻辑结构之二次体会 100 3.2.6.1 BLOCK的大小与调整 100 3.2.6.2 PCTFREE参数与调整 101 3.2.6.3 PCTFREE与生效范围 102 3.2.6.4 EXTENT尺寸与调整 103 3.2.7 逻辑结构之三次体会 104 3.2.7.1 已用与未用表空间情况104 3.2.7.2 表空间大小与自动扩展105 3.2.7.3 回滚表空间新建与切换109 3.2.7.4 临时表空间新建与切换111 3.2.7.5 临时表空间组及其妙用114 3.3 课程结束你给程序安上了翅膀 117 3.3.1 过度扩展与性能 117 3.3.2 PCTFREE与性能120 3.3.3 行迁移与优化 123 3.3.4 块的大小与应用 124 第4章祝贺,表的设计成就英雄 131 4.1 表的设计之五朵金花 131 4.2 表的特性从老余一家展开描述 132 4.2.1 老余一家各施所长 132 4.2.2 普通堆表不足之处 132 4.2.2.1 表更新日志开销较大 133 4.2.2.2 delete无法释放空间 136 4.2.2.3 表记录太大检索较慢 139 4.2.2.4 索引回表读开销很大 140 4.2.2.5 有序插入却难有序读出143 4.2.3 奇特的全局临时表 146 4.2.3.1 分析全局临时表的类型146 4.2.3.2 观察各类DML的REDO量 147 4.2.3.3 全局临时表两大重要特性 149 4.2.4 神通广大的分区表 153 4.2.4.1 分区表类型及原理155 4.2.4.2 分区表最实用的特性 165 4.2.4.3 分区索引类型简述176 4.2.4.4 分区表之相关陷阱177 4.2.5 有趣的索引组织表 184 4.2.6 簇表的介绍及应用 187 4.3 理解表设计的你成为项目组英雄 189 第5章惊叹,索引天地妙不可言 191 5.1 看似简单无趣的索引知识 191 5.2 索引探秘从小余缉凶拉开帷幕 192 5.2.1 BTREE索引的精彩世界 192 5.2.1.1 BTREE索引结构图展现192 5.2.1.2 到底是物理还是逻辑结构 194 5.2.1.3 索引结构三大重要特点198 5.2.1.4 插播小余缉凶精彩故事201 5.2.1.5 妙用三特征之高度较低203 5.2.1.6 巧用三特征之存储列值219 5.2.1.7 活用三特征之索引有序248 5.2.1.8 不可不说的主外键设计265 5.2.1.9 组合索引高效设计要领272 5.2.1.10变换角度看索引的危害289 5.2.1.11如何合理控制索引数量295 5.2.2 位图索引的玫瑰花之刺 297 5.2.2.1 统计条数奋勇夺冠297 5.2.2.2 即席查询一骑绝尘302 5.2.2.3 遭遇更新苦不堪言306 5.2.2.4 重复度低一败涂地309 5.2.2.5 了解结构真相大白311 5.2.3 小心函数索引步步陷阱 315 5.2.3.1 列运算让索引失去作用315 5.2.3.2 函数索引是这样应用的317 5.2.3.3 避免列运算的经典案例319 5.3 索引让一系列最熟悉的SQL飞起来了 325 第6章经典,表的连接学以致用 327 6.1 表的连接之江南三剑客 327 6.2 三大类型从小余跳舞一一道来 328 6.2.1 跳舞也能跳出连接类型 328 6.2.1.1 感觉怪异的嵌套循环 328 6.2.1.2 排序合并及哈希连接 329 6.2.2 各类连接访问次数差异 330 6.2.2.1 嵌套循环的表访问次数330 6.2.2.2 哈希连接的表访问次数337 6.2.2.3 排序合并的表访问次数340 6.2.3 各类连接驱动顺序区别 341 6.2.3.1 嵌套循环的表驱动顺序341 6.2.3.2 哈希连接的表驱动顺序343 6.2.3.3 排序合并的表驱动顺序345 6.2.4 各类连接排序情况分析 347 6.2.4.1 除嵌套循环都需排序 347 6.2.4.2 排序只需取部分字段 347 6.2.4.3 关于排序的经典案例 349 6.2.5 各类连接限制场景对比 350 6.2.5.1 哈希连接的限制 350 6.2.5.2 排序合并的限制 353 6.2.5.3 嵌套循环无限制 355 6.3 你动手装备的表连接威震三军 355 6.3.1 嵌套循环与索引 356 6.3.2 哈希连接与索引 362 6.3.3 排序合并与索引 363 下篇飞翔意识天空——思想与案例的分享 第7章搞定!不靠技术靠菜刀 368 7.1 SQL被一刀剁了 369 7.2 整个模块丢弃了 370 7.3 调用次数减少了 371 7.4 排序不再需要了 372 7.5 大表砍成小表了 373 7.6 排重操作消失了 373 7.7 插入阻碍小多了 374 7.8 迁移事情不做了 375 第8章升级!靠技术改隐形刀 377 8.1 大表等同小表了 378 8.2 大表切成小表了 379 8.3 索引变身小表了 380 8.4 删除动作不做了 380 8.5 清表角度变换了 381 8.6 提交次数缩减了 382 8.7 迁移越来越快了 384 8.8 SQL语句精简了 385 第9章提问,也是智慧的体现 391 9.1 描述要考虑周全 392 9.2 用词要尽量准确 393 9.3 说明要力求简洁 394 9.4 问过的避免再问 396 9.5 能搜能试不急问 396 第10章买鱼,居然买出方法论 398 10.1 小余买鱼系列故事 398 10.1.1 诊断与改进 398 10.1.2 需求与设计 401 10.1.3 资源的利用 403 10.1.4 真正的需求 404 10.2 买鱼买出了方法论 405 10.2.1 一套流程 405 10.2.2 两大法宝 407 10.3 方法论的应用案例 408 10.3.1 从我们的这一套流程说起 408 10.3.1.1 诊断 408 10.3.1.2 改进优化(首次优化) 409 10.3.1.3 需求与设计(再次优化) 410 10.3.1.4 资源利用(花絮) 412 10.3.2 案例映衬了经典两大法宝 412 第11章宝典,规范让你少做事 414 11.1 抓狂,为何事总忙不完 415 11.1.1 技术能力不足的新人们 415 11.1.2 不懂提问智慧的求助者 415 11.1.3 产生各种失误的粗心者 416 11.1.3.1 啊,小黄的DDL惹祸 416 11.1.3.2 惨,老师登错环境了 417 11.1.3.3 糟,小罗忘操作…… 417 11.1.4 解决问题缓慢的技术员 419 11.1.4.1 优化效率低下的小高 419 11.1.4.2 为何老师能快速解决 420 11.1.5 陷入种种困境的开发者 422 11.1.5.1 超长SQL使小郑烦恼 422 11.1.5.2 缺少注释让小叶沮丧 422 11.1.6 总是考虑不全的设计者 423 11.1.6.1 未提前规划的王工 423 11.1.6.2 不了解特性的刘工 424 11.2 淡定,规范少做无谓事 425 11.2.1 学习规范——促成新人快速成长 426 11.2.2 求助规范——引导求助不再迷糊 427 11.2.3 操作规范——协助粗心者不犯错 428 11.2.4 流程规范——保障问题快速解决 429 11.2.4.1 动态整体 429 11.2.4.2 动态局部 432 11.2.4.3 静态整体 439 11.2.4.4 静态局部 448 11.2.5 开发规范——让开发者驾轻就熟 451 11.2.5.1 SQL编写规范 452 11.2.5.2 PL/SQL编写规范 455 11.2.6 设计规范——助设计者运筹帷幄 457 11.2.6.1 表规范 458 11.2.6.2 索引规范 461 11.2.6.3 环境参数规范 467 11.2.6.4 命名规范 469

111,098

社区成员

发帖
与我相关
我的任务
社区描述
.NET技术 C#
社区管理员
  • C#
  • AIGC Browser
  • by_封爱
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告

让您成为最强悍的C#开发者

试试用AI创作助手写篇文章吧