今天在看同事程序的時候，看到這種用法，順便學習下。
一：理論
1.功能
這個功能是上鎖。
上的是一個排它鎖,也就是說,其他的事務是可以讀取的。但是不能寫入或者更新。
二：實踐
1.創建表
2.提交一條記錄
3.將自動提交關閉
然后插入一條數據。
4.再啟動一個客戶端，進行查詢
會發現，這里的值被查詢出來還是10，因為沒有提交。
5.操作人員2發現數據不對，然后發起修改。
但由於會話1中對該行記錄的修改未提交，所以，排它鎖並沒有釋放，因而操作人員2發起的這個修改操作會等待，直至會話1釋放該鎖（提交或回滾）。
6.然后會話1進行提交，並查詢
這個時候，結果是對的。
7.提交會話2的修改
8.再次查詢結果
三：解決方式
1.解決方式
在我們試圖修改某個記錄時，先利用select ... from xxx where zzz for update;將該記錄加鎖。這樣，就可以確保我現在看到的值，一定不會再被其他人修改了。
2.會話1
3.會話2
4.等會話1commit了,看2界面
會將結果查詢出來。
5.再進行提交
這個時候，會在最新的基礎上進行新增。
與剛才的區別：
這個查詢的結果，是15，而剛才的查詢結果確是10.
因為這里有一段時間再等待，這個行記錄被鎖定。
四：需要注意的地方
1.是否根據主鍵決定是否鎖表
選中某一個行的時候,如果是通過主鍵id選中的。那么這個時候是行級鎖。 其他的行還是可以直接insert 或者update的。
如果是通過其他的方式選中行,或者選中的條件不明確包含主鍵。這個時候會鎖表。其他的事務對該表的任意一行記錄都無法進行插入或者更新操作。只能讀取。