事务学习惯于

 -----事务学习-----------
事务日志和数据文件放在不同的地方，
锁的特征：
1，粒度（行锁，页锁，护展盘区锁，表锁，数据库锁，键锁）
2，模式（共享s，更新u，排它x，意向共享is，意向排它ix，共享意向排它six）
注：更新锁可以理解为转为排它锁的共享锁，防止在其读取期间到写入期间其它事务对数据进行更新操作
    意向锁可以理解为一种警示的锁，提高性能，防止锁争用。针对锁的模式和粒度不同，分为很多种意向锁
3,持续期(锁的隔离模式)
注：隔离模式：
           1，READ UNCOMMITED（仅保证不会数据崩溃）
           2，READ COMMITTED（系统默认的类型，防止脏读）
           3，REPEATABLE READ（防止不可重复读）
           4，SERIALIZABLE（最高级别，一般用于银行等高事务要求的部门或企业，但会发生严重的锁争用）
锁的粒度转换由系统叫作锁管理器来自动管理。
4，锁的兼容性，双锁事务以上的并存性（这个问题比较复杂）
5,锁数量少有助于提高系统的并发性
6，锁的粒度小有助于提高系统的速度
7，查看锁的某些信息：
   如下：
       1，用企业管理器的管理节点下的当前活动：锁和进程（非常细）
       2，用SP_LOCK看当所有锁的信息
8，锁的隔离级别：
           1，READ UNCOMMITED（仅保证不会数据崩溃）
           2，READ COMMITTED（系统默认的类型，防止脏读）
           3，REPEATABLE READ（防止不可重复读）
           4，SERIALIZABLE（最高级别，一般用于银行等高事务要求的部门或企业，但会发生严重的锁争用）
9,用DBCC USEROPTIONS对当前的隔离级别进行验证
10,用锁定提示可以在查询和表级进行指定隔离级别
   作用:可以对锁定策略进行微调
   作用域:只会对一个查询中的表级进行控制
如下:READUNCOMMITED ==NOLOCK
     READCOMMITED 
     REPEATABLEREAD   持有共享和排它锁直至事务提交
     SERIALIZABLE     对表应用可串行化隔离,表持有共享锁直至事务提交
     READPAST         跳过被锁定的行,而不等待(举例:SELECT FIELDNAME  FROM TABLENAME WITH (READPAST,UPDLOCK)
     ROWLOCK          强制用行锁代替页锁和扩展盘区锁和表锁
     PAGLOCK          强制用页锁代替扩展盘区锁和表锁
     TABLOCK          自动把行锁和页锁及扩展盘区锁升到表锁
     NOLOCK           不用任何锁====READUNCOMMITED
     TABLOCKX         强制给表加上排它锁,防止其它事务用该表
     HOLDLOCK         保持共享锁直至提交(这个我有一些不理解)
     UPDLOCK          用更新锁代替共享锁,防止其它事务在该事务读取数据期间到写数据期间对锁事实上的数据进行写操作)
     XLOCK            对数据保持排它锁直至事务提交
11,以上从查询和连接的角度来控制锁,也可以从表的来控制锁,以索引为单位,
   如下:SP_INDEXOPTION 'INDEXNAME' ALLOWROWLOCKS OR ALLOWPAGELOCKS(禁用针对一个索引的行锁和页锁
        SP_HELP TABLENAME  得出关于此表锁信息(indexname
        再用SP_INDEXOPTION 'INDEXNAME','allowrowlocks','false'  ---禁用行锁
            SP_INDEXOPTION 'INDEXNAME','allowPAGELOCK’，’FALSE‘---禁用页锁
12，关于锁超时，作用控制当一个事务要加锁时，的等待加锁时间（以MS为单位）
     STE LOCKTIMEOUT 2000
13，关于锁的锁争用情况，可以通过事件探查器中的性能监视器来看锁的数量度
14，也可以针对一个命名资源来加锁：如应用程序锁
     例如：有些应用程序不可能同时打开多个实例，否则报错
    可以用系统存储过程：SP_GETAPPLOCK(有两个参数，一为：必须指定锁的模式，是I，U，X，IX，IS；二为指定对某命名资源进行锁定；
                       返回值是否得到了要的锁（返回数据类型：INT）
                      
   注：应用程序锁
                1，不会自动栓测死锁
                2，事务放锁与加锁的次数相同
15，锁的争用：T1和T2和互相要对方的锁定资源，发生死锁
    为了防止死锁，规定对事务的编制有一个顺序
    不需要的事务，不要写入程序
16，虽然锁管理器可以自动处理死锁，决定当发生死锁时，要牺牲那个锁
    事务自己可以自己决定自己的级别，以发生死锁时，自动成为牺牲品  SET DEADLOC_PRIOTITY LOW
17, 对于死锁，也要防止：采用两种策略
                                  1，乐观锁定：当用户对一个窗体操作时，认为不会有人试图修改同一数据
                                  2，悲观锁定，当用户对一数据操作，一定要加锁
                               第2种对于小型桌面数据库可以工作很好，但对于大型DBMS，不行了，性能会大幅下去
      所以最好使锁的数量最小化，用第1种方法
18，LOSE UPDATE
      含义：就是同时有两个用户对同一数据进行修改，一个用户对数据的修改被另一个用户的修改覆盖了。
    针对它有两种方法，1，设计数据库模式要表长，列短，这样一个行的列少了，LOSE UPDATE机会少。
                        UPDATE如果由前端应用程序生成，最后提交时，生成一个只针对修改列的UPDATE命令
                     2，在要修改的表中添加ROWVERSION（TIMESTAMP）列：