update語句：
本例中由於看到的是update執行完的鎖情況，因此無法看到IU鎖，但其實針對要修改的數據頁和索引頁會先加IU鎖，記錄和鍵先加U鎖，然后再轉化為IX和X鎖。
如果想要看到IU鎖和U鎖，可以在update中使用索引列的過濾條件但不更新索引列來實現，這樣你可以通過sp_lock看到索引頁和索引鍵上的IU/U鎖。
Ps：好像with (uplock)也可以看到U鎖，這里提一下就懶得自己去測啦。
其上鎖情況為：
可以看到加鎖情況如下：
1.添加了表級IX鎖
2.針對數據頁3105添加了IX鎖，以便更新其中數據行
3.對數據頁3105中對應的數據行添加了X模式的KEY鎖
4.更新完數據后要更新包含ClinicID列的相關索引，我們先看一下涉及到這個列的索引有哪些：（可以看到確實是60號索引）
select * from sys.indexes where object_id=OBJECT_ID('RIS_REQUEST')
對索引頁50160、1458239添加了IX鎖，以便更新其中索引行
5.對以上2個索引頁內的索引行添加X模式KEY鎖，更新索引行完成。
這里有個疑問：我是按主鍵進行更新的，這意味着只涉及到一個數據行，索引也應該只有一行對應才對，為何會導致2個索引記錄的X模式KEY鎖出現？
只能去看50160、1458239這兩個頁的具體內容了，這里我把兩個頁的具體內容全部用dbcc page轉儲出來：
50160頁只截取了可能包含主鍵2012121218060024的部分：
1458239頁總共只有這么多行的記錄：
可以看到主鍵值為2012121218060024的索引就是在1458239索引頁的第2行，其對應的hash值也是sp_lock中看到的7be5a319785d，而另一個hash值fcee1248c8e6對應的索引行則沒有找到，這可以預見，因為ClinicID被更新后其HASH值必定發生變化。