一致和并發是對立的，需要根據應用，選擇權宜之計

數據不一致的現象
---事務內單SQL的情況---
1.臟讀-Dirty Read：本事務讀取了其它事務尚未提交的修改數據
例子：讀了不該讀的
1:00 x=1
1:01 A用戶 Update x=2（但未commit）
1:02 B用戶 Select x --> x=2
合理的情況是x仍然等于1

---事務內多SQL的情況（典型的如，先查再改）---
2.不可重復讀-Non Repeatable Read
例子1：自相矛盾
1:00 x=1 y=2
1:01 B用戶 Select x,y --> x=1 y=2
1:02 A用戶 Update x=2; Commit;
1:03 B用戶 Select x+y --> x+y=4
首先這個結果從單條SQL的角度看，是沒有問題的。但是，如果把B的兩次查詢看作一個整體（事務），那么合理的情況應該是
? x+y仍然等于3
? 或者B再進行一次事務，得出 x=2 y=2 x+y=4 的結果

例子2：更新丟失
1:00 x=1
1:01 B用戶 Select x --> x=1
1:02 A用戶 Select x --> x=1
1:03 A用戶 Update x=2; Commit;
1:04 B用戶 Update x=3; Commit;
同樣，從單條SQL來講，沒有任何問題。
但是從邏輯的合理性講，一般的更新操作都是先查再改，換言之
? A真正想做的是Update x from 1 to 2
? B真正想做的是Update x from 1 to 3
但最終卻造成了在B不知情的情況下，把B的初衷改為了Update x from 2 to 3

3.幻影讀-Phantom Read
例子：讀到了未來
1:00 X1=1 X2=2
1:01 B用戶 Select Xi --> X1=1 X2=2
1:02 A用戶 Insert X3=3; Commit;
1:03 B用戶 Select sum(Xi) --> re=6
其實道理和之前的不可重復讀相同，只不過是由Insert引起的罷了。
（甚至Delete也會引起類似的問題，但好像學術界并沒有對Delete進行討論）



Isolation Level
Read Uncommitted：1，2，3都會發生
? Oracle中嚴格禁止臟讀
? 在SQL Server 7.0中，是可以選擇該級別的
Read Committed：發生2，3（Oracle的默認級別）
Repeatable Read：發生3
Serializable：都不發生


Oracle的實現方式
Read Committed：默認就實現
Repeatable Read：
? 1. 悲觀鎖（select ... for update)，影響并發
? 2. 樂觀鎖（update where 所有字段都作為條件)，不影響并發
Serializable：
? alter session set isolation_level=serializable/read only