SQL Server和Oracle数据锁定比较

核心提示： 下面用SQL Server随带的pubs示例数据库做一个简单示范，在Query Analyzer内打开两个窗口，SQL Server和Oracle数据锁定比较(2)，在第1个窗口中执行下列SQL操作语句，更新pubs数据库中某一图书的价格：use pubsgobegin tranupdat

下面用SQL Server随带的pubs示例数据库做一个简单示范。在Query Analyzer内打开两个窗口。在第1个窗口中执行下列SQL操作语句，更新pubs数据库中某一图书的价格：　　use pubs
　　go
　　begin tran
　　update titles
　　set price = price * 1.05
　　where
　　title_id = 'BU2075'

由于代码中并没有执行commit语句，所以数据变动操作实际上还没有最终完成。接下来，在另一个窗口里执行下列语句查询titles数据表：

　　select title_id,title,price
　　from titles
　　order by title_id.

你什么结果也得不到。窗口底部的小地球图标会转个不停。尽管我在先前的操作中仅仅更新了一行，但是，select语句的执行对象却恰好包含了其数据正被修改的一行。因此，上面的操作不会返回任何数据，除非回到第1个窗口提交交易或者回滚。

SQL Server的数据锁定方案可能会降低系统的性能和效率。数据被锁定的时间越长，或者锁定的数据量越大，其他数据访问用户就越可能不得不等待其查询语句的执行。因此，从程序员的角度来看，对SQL Server编程的时候应该尽量地把交易代码设计得既小又快。

在SQL Server的最近版本中，微软对SQL Server进行了某些修改，使其一次锁定的数据量大大减少，这是数据库设计中的一大重要改进。在6.5版及以前版本中，最少的数据锁定量是一页。哪怕你只在修改一行数据，而该行数据位于包含10行数据的一页上，则整页10行数据都会被锁定。显然，这么大的数据锁定量增加了其他数据访问连接不得不等待数据修正完成的概率。在SQL Server 7中，微软引入了行锁定技术，这样，目前的SQL Server只锁定实际正被改变的数据行。