mssql中使用的一些常用又特殊的语句
2012-10-27 14:33:50 来源:WEB开发网1:乐观锁:完全依靠数据库来管理锁的工作。
2:悲观锁:程序员自己管理数据或对象上的锁处理。
一般程序员一看到什么锁之类,觉的特别复杂,对专业的DBA当然是入门级知识了。可喜的是程序员不用去设置,控制这些锁,SQLServer通过设置事务的隔离级别自动管理锁的设置和控制。锁管理器通过查询分析器分析待执行的sql语句,来判断语句将会访问哪些资源,进行什么操作,然后结合设定的隔离级别自动分配管理需要用到的锁。
2>:行版本控制:当启用了基于行版本控制的隔离级别时,数据库引擎 将维护修改的每一行的版本。应用程序可以指定事务使用行版本查看事务或查询开始时存在的数据,而不是使用锁保护所有读取。通过使用行版本控制,读取操作阻止其他事务的可能性将大大降低。也就是相当于针对所有的表在查询时都会加上nolock,同样会产生脏读的现象,但差别在于在一个统一管理的地方。说到了基于行版本控制的隔离级别,这里有必要说下隔离级别的概念。
隔离级别的用处:控制锁的应用,即什么场景应用什么样的锁机制。
最终目的:解决并发处理带来的种种问题。
隔离级别的分类:
1:未提交读,隔离事务的最低级别,只能保证不读取物理上损坏的数据;
2:已提交读,数据库引擎的默认级;
3:可重复读;
4:可序列化;隔离事务的最高级别,事务之间完全隔离。
小结:NOLOCK 语句执行时不发出共享锁,允许脏读 ,等于 READ UNCOMMITTED事务隔离级别 。nolock确实在查询时能提高速度,但它并不是没有缺点的,起码它会引起脏读。
nolock的使用场景(个人观点):
1:数据量特别大的表,牺牲数据安全性来提升性能是可以考虑的;
2:允许出现脏读现象的业务逻辑,反之一些数据完整性要求比较严格的场景就不合适了,像金融方面等。
3:数据不经常修改的表,这样会省于锁定表的时间来大大加快查询速度。
综上所述,如果在项目中的每个查询的表后面都加nolock,这种做法并不科学,起码特别费时间,不如行版本控制来的直接有效。而且会存在不可预期的技术问题。应该有选择性的挑选最适合的表来放弃共享锁的使用。
最后说下nolock和with(nolock)的几个小区别:
1:SQL05中的同义词,只支持with(nolock);
2:with(nolock)的写法非常容易再指定索引。
跨服务器查询语句时 不能用with (nolock) 只能用nolock
同一个服务器查询时 则with (nolock)和nolock都可以用
比如
SQL code
select * from [IP].a.dbo.table1 with (nolock) 这样会提示用错误select * from a.dbo.table1 with (nolock) 这样就可以
5.@@ERROR:
如果前一个 Transact-SQL 语句执行没有错误,则返回 0。
如果前一个语句遇到错误,则返回错误号。如果错误是 sys.messages 目录视图中的错误之一,则 @@ERROR 将包含 sys.messages.message_id 列中表示该错误的值。可以在 sys.messages 中查看与 @@ERROR 错误号相关的文本信息。
由于 @@ERROR 在每一条语句执行后被清除并且重置,因此应在语句验证后立即查看它,或将其保存到一个局部变量中以备以后查看。
使用 TRY...CATCH 构造来处理错误。TRY...CATCH 构造也支持其他返回的错误信息多于 @@ERROR 的系统函数(ERROR_LINE、ERROR_MESSAGE、ERROR_PROCEDURE、ERROR_SEVERITY 和 ERROR_STATE)。TRY...CATCH 也支持 ERROR_NUMBER 函数,但不限制该函数在语句产生错误后立即在语句中返回错误号。
6.@@IDENTITY:
在一条 INSERT、SELECT INTO 或大容量复制语句完成后,@@IDENTITY 中包含语句生成的最后一个标识值。如果语句未影响任何包含标识列的表,则 @@IDENTITY 返回 NULL。如果插入了多个行,生成了多个标识值,则 @@IDENTITY 将返回最后生成的标识值。如果语句触发了一个或多个触发器,该触发器又执行了生成标识值的插入操作,那么,在语句执行后立即调用 @@IDENTITY 将返回触发器生成的最后一个标识值。如果对包含标识列的表执行插入操作后触发了触发器,并且触发器对另一个没有标识列的表执行了插入操作,则 @@IDENTITY 将返回第一次插入的标识值。出现 INSERT 或 SELECT INTO 语句失败或大容量复制失败,或者事务被回滚的情况时,@@IDENTITY 值不会恢复为以前的设置。
更多精彩
赞助商链接