之前寫過相關的文章，對髒讀，不可重複讀，幻讀都做了相當的研究，而今天在程式中又出現了這個問題，即當一條資料被update時，另乙個執行緒同時發起了讀的操作，這對於序列化級別的事務是不被允許的，正常情況下它應該被阻塞，當事務消失時，資料從新被讀取。
更新丟失
兩個事務都同時更新一行資料，乙個事務對資料的更新把另乙個事務對資料的更新覆蓋了。這是因為系統沒有執行任何的鎖操作，因此併發事務並沒有被隔離開來。
髒讀
乙個事務讀取到了另乙個事務未提交的資料操作結果。這是相當危險的，因為很可能所有的操作都被回滾。
不可重複讀
不可重複讀（non-repeatable reads）：乙個事務對同一行資料重複讀取兩次，但是卻得到了不同的結果。
包括以下情況：
（1） 虛讀：事務t1讀取某一資料後，事務t2對其做了修改，當事務t1再次讀該資料時得到與前一次不同的值。
（2） 幻讀（phantom reads）：事務在操作過程中進行兩次查詢，第二次查詢的結果包含了第一次查詢中未出現的資料或者缺少了第一次查詢**現的資料（這裡並不要求兩次查詢的sql語句相同）。這是因為在兩次查詢過程中有另外乙個事務插入資料造成的。
未授權讀取
也稱為讀未提交（read uncommitted）：允許髒讀取，但不允許更新丟失。如果乙個事務已經開始寫資料，則另外乙個事務則不允許同時進行寫操作，但允許其他事務讀此行資料。該隔離級別可以通過「排他寫鎖」實現。
授權讀取
也稱為讀提交（read committed）：允許
不可重複讀取，但不允許髒讀取。這可以通過「瞬間共享讀鎖」和「排他寫鎖」實現。讀取資料的事務允許其他事務繼續訪問該行資料，但是未提交的寫事務將會禁止其他事務訪問該行。
可重複讀取（repeatable read）
可重複讀取（repeatable read）：禁止
不可重複讀取和髒讀取，但是有時可能出現幻讀資料。這可以通過「共享讀鎖」和「排他寫鎖」實現。讀取資料的事務將會禁止寫事務（但允許讀事務），寫事務則禁止任何其他事務。
序列化（serializable）
序列化（serializable）：提供嚴格的事務隔離。它要求事務
序列化執行，事務只能乙個接著乙個地執行，不能併發執行。僅僅通過「行級鎖」是無法實現事務序列化的，必須通過其他機制保證新插入的資料不會被剛執行查詢操作的事務訪問到。
隔離級別越高，越能保證資料的完整性和一致性，但是對併發效能的影響也越大。對於多數應用程式，可以優先考慮把
資料庫系統的隔離級別設為read committed。它能夠避免髒讀取，而且具有較好的併發效能。儘管它會導致
不可重複讀、幻讀和第二類丟失更新這些併發問題，在可能出現這類問題的個別場合，可以由應用程式採用
悲觀鎖或
樂觀鎖來控制。
--network protocol: tcp/ip
set quoted_identifier on
set arithabort off
set numeric_roundabort off
set ansi_warnings on
set ansi_padding on
set ansi_nulls on
set concat_null_yields_null on
set cursor_close_on_commit off
set implicit_transactions off
setlanguage 簡體中文
setdateformat ymd
set datefirst 7
settransaction
isolation
level
serializable
感謝各位的閱讀！
知方可補不足 目錄
回到佔佔推薦部落格索引 知方可補不足系列主要是對原來的技術進行學習，研究，將之前不確定的東西進行驗證，將專案中正在用到的老技術進行總結。知方可補不足系列主要的範疇是資料庫方面 知方可補不足 說說吧！timestamp有什麼用？知方可補不足 sql巧用xml path來生成符合規則的查詢結果集 知方可...
知方可補不足 UPDLOCK更新鎖的使用
回到目錄 對於高併發的場合下，使用updlock可以有效的控制併發更新的問題，即當乙個執行緒在進行with updlock 並進行update時，另乙個執行緒將被阻塞，它會等第乙個執行緒更新結束後，才可以進行它裡面的操作，使用updlock有效的避免了併發更新而產生的資料錯誤的問題，如累加操作，第二...
知方可補不足 說說吧！timestamp有什麼用？
最近開發了乙個公安機關的分布式系統，在系統中要求若干個人同時可以對資料庫進行讀寫操作。這時出現了一些聯想問題 1 當多於1人的使用者對同一條記錄進行寫操作時，先寫入的使用者的資料必定會被後寫入的使用者的資料override掉，這個問題如何解決？2 希望看比某一條記錄更新的 在這條記錄修改後，才進行修...