sql之事務和並發

1、Transaction（事務）是什么：

 事務是作為單一工作單元而執行的一系列操作。包括增刪查改。

2、事務的種類：

 事務分為顯示事務和隱式事務：

隱式事務：就是平常我們使用每一條sql 語句就是一個事務，只不過他們執行完成之后事務就跟着結束了。

顯示事務：就是需要我們來手寫了，這個時候就可以進行控制事務的開始和結束了。

--顯式事務（對事物可以進行控制）

--開始事務
begin transaction;
update [Sales.Shippers]
set companyname='順豐' where shipperid=5;

select * from [Sales.Shippers];

--結束事務：
--第一種：事務的回滾
rollback;

--第二種：事務的提交
commit;

 

3、事務很重要的四個屬性： 

 1、原子性：事務必須是原子工作單位。——在事務中修改數據，要么全都執行，要么全都不執行。在事務執行完成之前（調提交指令寫入到sql的事務日志之前），出現問題或重啟，sql server 會回滾所有的修改事務。 但是也有例外的錯誤不會回滾事務————例如：主鍵沖突和鎖超時等。  錯誤日志會 捕獲這些錯誤的指令，並記錄日志里面，然后執行一些操作（例如：回滾事務）

 

2、一致性：發生在同一進程的事物里面的 修改和 查詢是不會產生沖突的。保持訪問的數據的一致性。

 

3、隔離性：控制數據訪問的機制； 說明： 一個事務正在對一個表的數據正在修改， 還沒有執行完成；；這時另一個事務，想要查詢里面的數據，是不能查到的，必須等到 修改的事務執行完成。：sql server 采用的 “鎖”的機制，將正在修改的事務 處理的表的數據 鎖定。這樣是為了保證數據同步，數據的一致性。

 

4、持久性：  當一個事務的指令 已經提交到 事務日志里面，即使磁盤上的數據還沒有修改，這個時候數據庫的服務停止，在服務重啟的時候還會將事務日志里的指令執行(進行回復處理)。保證數據的持久性。

 

上面將基本的事務介紹了一下，下面開始介紹並發。所以必須要介紹就是事務的“鎖”。

4、事務中的鎖

 事務中都含有什么鎖呢？

最常用的鎖：排它鎖（獨占鎖）和共享鎖，還有其他的鎖，這里就不做介紹了，比如：更新鎖、架構鎖、意向鎖等。

 

5、排它鎖和共享鎖

 排它鎖：

當一個事務執行更新修改操作的時候會申請排它鎖，主要是在寫操作里面使用。需要注意的兩點：1、一個事務含有排它鎖，就不能含有其他任何鎖。2、一條數據只能被一個排它鎖鎖住，就不能再被其他排他鎖鎖定。

共享鎖：

 主要是在讀操作中使用，並且多個事務可以同時對一條數據使用共享鎖。

 

排它鎖和共享鎖最重要的區別：排它鎖是不能被控制他的處理方式和時間，但是共享鎖是可以控制其隔離級別來控制其處理的時間。

begin transaction;
update [Sales.Shippers] set companyname='順豐' where shipperid=5;
--事務還沒有查詢完成，為這條數據 加上一個 排它鎖。這時這條數據就不能被其他進程 訪問到

 

事務還沒有執行完成，再開一個線程，執行查詢操作

select * from [Sales.Shippers] where shipperid=5

 

因為讀操作默認使用的共享鎖，但是這個時候這條數據已經被其他線程的排它鎖鎖住，所以會造成阻塞，直到排它鎖釋放。

 

6、隔離級別 

 首先要先明白三點：

1、用於控制並發用戶如何讀寫數據的操做。

2、讀操作默認使用共享鎖；寫操作需要使用排它鎖。

3、讀操作能夠控制他的處理的方式，寫操作不能控制它的處理方式

 

隔離級別分為六種：

read uncommited（讀取未提交數據），read commited（讀取已提交數據）讀取的默認方式，repeatable read（可重復讀），serializable（可序列化），snapshot（快照），read commited snapshot（已經提交讀隔離）（后兩個是sql server 2005 里面 引入的）。隔離的強度依次遞增。

 

 1、read uncommitted:

select * from [Sales.Shippers] where shipperid=3;

 

 查詢結果：

在本線程內執行：

begin transaction;
update [Sales.Shippers] set companyname='圓通' where shipperid=3;

 

在另外一個線程內 使用 read uncommitted 隔離級別 查詢數據：

--設置讀操作的隔離級別
set transaction isolation level read uncommitted;
select * from [Sales.Shippers] where shipperid=3;

 查詢結果：

如果這個時候將那個事務回滾，那么這個時候  查詢到的數據就是“臟數據”。

總結：

read uncommitted：最低的隔離級別：查詢的時候不會請求共享鎖，所以不會和排它鎖產生沖突（不會等待排它鎖執行完），查詢效率非常高，速度飛快。但是缺點：會查到“臟數據”（排它鎖的事務已經將數據修改，還沒提交，這個時候查詢到的數據 是已經更改過的。如果事務回滾，就是“臟數據”）

優點：查詢效率非常高，速度非常快。

缺點：會產生“臟數據”

適用性：

適用於 像聊天軟件的 聊天記錄，會是軟件的運行速度非常快。 但是不適用於 商務軟件。尤其是銀行

 

2、read committed

 讀取的默認隔離級別就是read committed 和上面正好相反。如果上面情況，采用read committed 隔離級別查詢的話查到的就是還沒有更改之前的數據。

 所以在這里就不再演示。

3、repeatable read：

 查詢的時候會加上共享鎖，但是查詢完成之后，共享鎖就會被撤銷。比如一些購票系統，如果查到票了，當買的時候就沒有，這是不行的。所以要在查詢到數據之后做一些延遲共享鎖，進而阻塞排它鎖來修改。（如果查詢的事務沒有提交，不會釋放共享鎖，這個時候獨占鎖就不能訪問這條數據）

注意：1、repeatable 只會鎖定查詢的數據 ，而 其他行數據還可以進行 修改（更新、刪除）（下面那條語句共享鎖只會鎖定 shipperid為4 的行）

       2、其他進行插入數據，並且插入的數據滿足第一次開始事務時的 查詢的篩選條件的時候；第二次查詢的時候就會將新插入的數據 查詢出來。這就叫做“幻讀”（解決幻讀，需要更高級別的隔離，就是下面的serializable）

       

在查詢線程里面執行sql語句：

set transaction isolation level repeatable read;
begin transaction;
select * from [Sales.Shippers] where shipperid=4;

 

然后在 另外一個線程內執行修改語句：

update [Sales.Shippers] set companyname='shit' where shipperid=4;

 

這個時候會將更改的線程阻塞掉：

 

幻讀演示：

在線程1 內 輸入：

set transaction isolation level serializable;
begin transaction;
select * from [Sales.Shippers] where companyname='順豐'

 

結果：

 

在線程2 內 輸入 插入語句：

insert into [Sales.Shippers] (companyname,phone) values('順豐',112321211)

 

結果：

 

在  用 共享鎖 執行查詢語句：

select * from [Sales.Shippers] where companyname='順豐'

 

結果：

 

4、serializable（可序列化）

 更高級的 隔離。用戶解決“幻讀”（上面提到的）。就是使用上面的（repeatable read）  加上共享鎖 並不撤銷，如果鎖定的 一行數據，那么 其他的進程 還可以對 其他的數據進行操作，也可以 進行新增和刪除的操作。   所以如果想要在查詢的時候，不能對整張表進行任何操作，那么就要 將表的結構也 鎖定    （就需要使用 更強的 鎖定）

在查詢線程執行sql語句：

set transaction isolation level serializable;
begin transaction;
select * from [Sales.Shippers] where companyname='順豐'

 

 

那么在另外一個線程執行下面兩個語句，不論那一條語句都會阻塞住：

insert into [Sales.Shippers] (companyname,phone) values('順豐',112321211)  --因為插入的數據滿足 查詢的篩選的 條件條件了

 

 結果：

總結：

可序列話 隔離讀操作：用戶 解決 幻影數據（將標的數據和表的結構都鎖定）,是並發降低...隔離級別越高,並發越低,但是效率越低,所以不是要確定使用  最好不要使用

 

下面兩種隔離級別是在 sql server 2005才出現的，隔離級別更高：

5、snapshot（快照）

 為數據產生一個臨時數據庫，當sql server 數據更新之前將當前數據庫復制到 tempdb數據庫里面，查詢就是從tempdb數據庫中查詢，但是不能再 使用 snapshot 線程的事務內執行 修改操作，因為不能修改 舊版本數據庫（tempdb），會報錯。

snapshot隔離級別，讀操作 不適用 共享鎖，使用的是“行版本控制”，所以讀數據的性能效率很高，但是修改操作性能就降低的很多。

因為是將 數據庫  中的數據 復制到 tempdb 數據庫中，所以不會產生 幻讀。

--設置數據庫支持快照隔離級別：
alter database ssdemo set allow_snapshot_isolation on;--這個時候會產生一個臨時數據庫（寫操作的排它鎖鎖定的是 現實存在的數據庫，，讀操作的讀取的是 臨時數據庫）

 

 在一個線程中執行 更新操作，用排它鎖鎖定當前數據

begin transaction;
--使用 排它鎖（獨占鎖）X，鎖定 下面的那條數據
update [Sales.Shippers] set companyname='飛鳳' where shipperid=3;

 

這個時候在在另外一個線程中查詢這條數據（默認的隔離級別），就會將當前線程阻塞。

如果使用 snapshot 隔離級別查詢就不會阻塞。

set transaction isolation level snapshot;
--下面的就可以  從臨時數據庫中查詢到數據
begin transaction;
--沒有使用 共享鎖 ，使用的行版本控制，所以不管數據是否加了 獨占鎖，都可以到 tempdb中 讀取數據（如果數據修改了才到tempdb中讀取數據）
select * from [Sales.Shippers] where shipperid=3;--查詢到的 是還沒有完成更新之前的數據

 

但是同時也會帶來兩個問題：

1、當 另外一個事務  已經提交，但是這邊的查詢到數據還是沒有修改。因為 每次查詢到的快照是針對於 本次回話對應的那個 transaction 的，因為在這個事務里面是沒有修改的，所以查詢到的數據是沒有修改的。

2、（更新問題）因為 那邊的數據已經是 飛鳳公司了，但是這里還是   聯邦,所以,在這個事務里面是不能對表進行修改,因為訪問的是臨時數據庫,想要對 數據庫修改是不可能的（sql server 就會報錯，阻止修改） 

 

針對於上面兩個問題，所以下面 更高的隔離級別出現了 read committed snapshot：

6、read committed snapshot

 首先開啟數據庫的 read committed snapshot 隔離級別：

--設置 數據庫 為 讀取已經提交的快照 開啟
alter database ssdemo set read_committed_snapshot on;

 

在一個線程中執行：

begin transaction;
update [Sales.Shippers] set companyname='聯邦' where shipperid=3;

 

在另外一個線程中：

--不用顯示聲明使用  read committed snapshot 隔離級別，因為設置完 read_committed_snapshot 隔離級別啟動，默認就是 read commited snapshot 隔離級別
begin transaction;
select * from [Sales.Shippers] where shipperid=3;--查詢到是 已經提交之后的數據

update [Sales.Shippers] set companyname='xiaoxiao' where shipperid=3;

 

這個時候查詢到的數據是還沒有更改之前的，如果將 前面的那個回話提交，那么在查詢 查詢到的數據是 提交修改之后的數據。所以解決了上面的問題1.

如果在修改的話。也是在第一個 更新線程中的事務更新之后的數據進行執行修改的操作，不會報錯。