加锁的主要目的是为了防止并发操作时导致的数据不一致等问题，锁分为共享锁(s)、更新锁(u)、排他锁(x)，共享锁与更新只是单向兼容？传说中的单相思？
事务
事务能保证数据操作的原子性，要么内部操作都提交，要么都回退。事务内部某个地方出错时，可以回滚前面的操作，比如更新、删除等。
begin tran ---报错时回滚 if @@error<>0 rollback tran --执行完后提交 commit tran
共享锁
共享锁允许并发事务读取一个资源，资源上存在共享锁时，任何其他事务不能修改数据，但是允许同时读取。
holdlock 在表上保持共享锁，直到整个事务结束。
执行查询时会默认加上共享锁。
begin tran ee select * from aa(holdlock) waitfor delay '0:0:30' commit tran ee
begin tran rr select * from aa(holdlock) commit tran rr
上面的例子，都在表aa上加了共享锁，运行结果表明，即使第一个事务没有执行完，第二个事务仍然可以直接查询出结果。这就说明，共享锁是可以同时存在多个的，多个事务可以同时获取同一资源的共享锁。
排他锁
xlock 其他事务不能读也不能修改它锁定的资源。
执行更新时会自动添加排他锁。
共享锁与排他锁不能同时存在。
begin tran ee select * from aa(holdlock) waitfor delay '0:0:30' commit tran ee
begin tran rr update aa set tt='33' where dd='44' commit tran rr
第一个事务在执行完成之前，第二个事务的更新一直没有进行，直到第一个事务完成之后，第二个事务中执行的更新操作才能进行。这就表明，共享锁与排他锁时不能同时存在的。一旦一个事务获取到了一个资源的共享锁，那么只有等到共享锁释放之后，才能被其他事务获取排他锁。
更新锁
updlock 一次只有一个事务可以获得资源的更新锁，获取了更新锁意味着获取了从共享锁到排他锁的资格。但是不会影响其他的查询，只会阻止那些试图加更新锁的操作。同一时间在同一个资源上不能有两个更新锁，同时加共享锁时允许的。
共享锁与更新锁是兼容的，允许同时在一个资源上。
排他锁与更新锁是不兼容的，不能同时加在一个资源上。
begin tran rr select * from aa(updlock) waitfor delay '0:0:30' commit tran rr
begin tran ee select * from aa(holdlock) commit tran ee
以上代码测试结果表明，在资源上加了更新锁之后，还可以继续加共享锁，也就说并不影响查询。但是，看下面的例子。
begin tran ee select * from aa(holdlock) waitfor delay '0:0:30' commit tran ee
begin tran rr select * from aa(updlock) commit tran rr
上面的例子是先加共享锁，然后再加更新锁，测试结果表明，在第一个事务结束之前，第二个事务并不能获取到更新锁。所以，是不是可以说更新锁与共享锁的兼容是单向的。
begin tran ee select * from aa(updlock) waitfor delay '0:0:30' commit tran ee
begin tran rr select * from aa(updlock) commit tran rr
上面的测试结果表明，不能同时获取同一个资源的更新锁。
begin tran ee select * from aa(updlock) waitfor delay '0:0:30' commit tran ee
begin tran rr --select * from aa(xlock) update aa set tt='44' commit tran rr
上面测试表明，加了更新锁，就不能获得排他锁。