數據庫面試題(基本概念、索引、事務)

一、基本概念

1.主鍵、外鍵

主鍵

數據庫表中對儲存數據對象予以唯一完整標識的數據列或屬性的組合。一個數據列只能有一個主鍵,且主鍵的取值不能缺失,即不能爲空值(Null)。

外鍵

在一個表中存在的另一個表的主鍵稱此表的外鍵。

2.觸發器

觸發器是保證數據完整性的一種方法,它是與表事件相關的特殊的存儲過程,它的執行不是由程序調用,也不是手工啓動,而是由事件來觸發,比如當對一個表進行操作( insert,delete, update)時就會激活它執行。觸發器經常用於加強數據的完整性約束和業務規則等。

觸發器有如下作用:

可在寫入數據表前,強制檢驗或轉換數據。
觸發器發生錯誤時,異動的結果會被撤銷。
部分數據庫管理系統可以針對數據定義語言(DDL)使用觸發器,稱爲DDL觸發器。
可依照特定的情況,替換異動的指令 (INSTEAD OF)。

3.存儲過程

存儲過程是一個預編譯的SQL語句,允許模塊化的設計,就是說只需創建一次,以後在該程序中就可以調用多次。如果某次操作需要執行多次SQL,使用存儲過程比單純SQL語句執行要快。

調用

1)可以用一個命令對象來調用存儲過程。
2)可以供外部程序調用,比如:java程序。

優點

1)存儲過程是預編譯過的,執行效率高。
2)存儲過程的代碼直接存放於數據庫中,通過存儲過程名直接調用,減少網絡通訊。
3)安全性高,執行存儲過程需要有一定權限的用戶。
4)存儲過程可以重複使用,可減少數據庫開發人員的工作量。

缺點

移植性差

4.視圖

是一種虛擬的表,具有和物理表相同的功能。可以對視圖進行增,改,查,操作,試圖通常是有一個表或者多個表的行或列的子集。對視圖的修改會影響基本表。它使得我們獲取數據更容易,相比多表查詢。

優點:

  1. 對數據庫的訪問,因爲視圖可以有選擇性的選取數據庫裏的一部分。
  2. 用戶通過簡單的查詢可以從複雜查詢中得到結果。
  3. 維護數據的獨立性,試圖可從多個表檢索數據。
  4. 對於相同的數據可產生不同的視圖。

缺點:

查詢視圖時,必須把視圖的查詢轉化成對基本表的查詢,如果這個視圖是由一個複雜的多表查詢所定義,那麼,那麼就無法更改數據.

5.drop、truncate、 delete區別

drop直接刪掉表。
truncate刪除表中數據,再插入時自增長id又從1開始。
delete刪除表中數據,可以加where字句。

(1) DELETE語句執行刪除的過程是每次從表中刪除一行,並且同時將該行的刪除操作作爲事務記錄在日誌中保存以便進行進行回滾操作。TRUNCATE TABLE 則一次性地從表中刪除所有的數據並不把單獨的刪除操作記錄記入日誌保存,刪除行是不能恢復的。並且在刪除的過程中不會激活與表有關的刪除觸發器。執行速度快。
(2) 表和索引所佔空間。當表被TRUNCATE 後,這個表和索引所佔用的空間會恢復到初始大小,而DELETE操作不會減少表或索引所佔用的空間。drop語句將表所佔用的空間全釋放掉。
(3) 一般而言,drop > truncate > delete
(4) 應用範圍。TRUNCATE 只能對TABLE;DELETE可以是table和view
(5) TRUNCATE 和DELETE只刪除數據,而DROP則刪除整個表(結構和數據)。
(6) truncate與不帶where的delete :只刪除數據,而不刪除表的結構(定義)drop語句將刪除表的結構被依賴的約束(constrain),觸發器(trigger)索引(index);依賴於該表的存儲過程/函數將被保留,但其狀態會變爲:invalid。
(7) delete語句爲DML(data maintain Language),這個操作會被放到 rollback segment中,事務提交後才生效。如果有相應的 tigger,執行的時候將被觸發。
(8) truncate、drop是DLL(data define language),操作立即生效,原數據不放到 rollback segment中,不能回滾。
(9) 在沒有備份情況下,謹慎使用 drop 與 truncate。要刪除部分數據行採用delete且注意結合where來約束影響範圍。回滾段要足夠大。要刪除表用drop;若想保留表而將表中數據刪除,如果於事務無關,用truncate即可實現。如果和事務有關,或老師想觸發trigger,還是用delete。
(10) Truncate table 表名 速度快,而且效率高,因爲:?truncate table 在功能上與不帶 WHERE 子句的 DELETE 語句相同:二者均刪除表中的全部行。但 TRUNCATE TABLE 比 DELETE 速度快,且使用的系統和事務日誌資源少。DELETE 語句每次刪除一行,並在事務日誌中爲所刪除的每行記錄一項。TRUNCATE TABLE 通過釋放存儲表數據所用的數據頁來刪除數據,並且只在事務日誌中記錄頁的釋放。
(11) TRUNCATE TABLE 刪除表中的所有行,但表結構及其列、約束、索引等保持不變。新行標識所用的計數值重置爲該列的種子。如果想保留標識計數值,請改用 DELETE。如果要刪除表定義及其數據,請使用 DROP TABLE 語句。
(12) 對於由 FOREIGN KEY 約束引用的表,不能使用 TRUNCATE TABLE,而應使用不帶 WHERE 子句的 DELETE 語句。由於 TRUNCATE TABLE 不記錄在日誌中,所以它不能激活觸發器。

6.非關係型數據庫和關係型數據庫

非關係型數據庫的優勢

性能:NOSQL是基於鍵值對的,可以想象成表中的主鍵和值的對應關係,而且不需要經過SQL層的解析,所以性能非常高。
可擴展性:同樣也是因爲基於鍵值對,數據之間沒有耦合性,所以非常容易水平擴展。

關係型數據庫的優勢

複雜查詢:可以用SQL語句方便的在一個表以及多個表之間做非常複雜的數據查詢。
事務支持:使得對於安全性能很高的數據訪問要求得以實現。

其他

1.對於這兩類數據庫,對方的優勢就是自己的弱勢,反之亦然。
2.NOSQL數據庫慢慢開始具備SQL數據庫的一些複雜查詢功能,比如MongoDB。
3.對於事務的支持也可以用一些系統級的原子操作來實現例如樂觀鎖之類的方法來曲線救國,比如Redis set nx。

7.數據庫範式,根據某個場景設計數據表?

第一範式

(確保每列保持原子性)所有字段值都是不可分解的原子值。

第一範式是最基本的範式。如果數據庫表中的所有字段值都是不可分解的原子值,就說明該數據庫表滿足了第一範式。
第一範式的合理遵循需要根據系統的實際需求來定。比如某些數據庫系統中需要用到“地址”這個屬性,本來直接將“地址”屬性設計成一個數據庫表的字段就行。但是如果系統經常會訪問“地址”屬性中的“城市”部分,那麼就非要將“地址”這個屬性重新拆分爲省份、城市、詳細地址等多個部分進行存儲,這樣在對地址中某一部分操作的時候將非常方便。這樣設計纔算滿足了數據庫的第一範式,如下表所示。
上表所示的用戶信息遵循了第一範式的要求,這樣在對用戶使用城市進行分類的時候就非常方便,也提高了數據庫的性能。

第二範式

(確保表中的每列都和主鍵相關)在一個數據庫表中,一個表中只能保存一種數據,不可以把多種數據保存在同一張數據庫表中。

第二範式在第一範式的基礎之上更進一層。第二範式需要確保數據庫表中的每一列都和主鍵相關,而不能只與主鍵的某一部分相關(主要針對聯合主鍵而言)。也就是說在一個數據庫表中,一個表中只能保存一種數據,不可以把多種數據保存在同一張數據庫表中。
比如要設計一個訂單信息表,因爲訂單中可能會有多種商品,所以要將訂單編號和商品編號作爲數據庫表的聯合主鍵。

第三範式

(確保每列都和主鍵列直接相關,而不是間接相關) 數據表中的每一列數據都和主鍵直接相關,而不能間接相關。

第三範式需要確保數據表中的每一列數據都和主鍵直接相關,而不能間接相關。
比如在設計一個訂單數據表的時候,可以將客戶編號作爲一個外鍵和訂單表建立相應的關係。而不可以在訂單表中添加關於客戶其它信息(比如姓名、所屬公司等)的字段。

BCNF

符合3NF,並且,主屬性不依賴於主屬性。

若關係模式屬於第二範式,且每個屬性都不傳遞依賴於鍵碼,則R屬於BC範式。
通常BC範式的條件有多種等價的表述:每個非平凡依賴的左邊必須包含鍵碼;每個決定因素必須包含鍵碼。
BC範式既檢查非主屬性,又檢查主屬性。當只檢查非主屬性時,就成了第三範式。滿足BC範式的關係都必然滿足第三範式。
還可以這麼說:若一個關係達到了第三範式,並且它只有一個候選碼,或者它的每個候選碼都是單屬性,則該關係自然達到BC範式。
一般,一個數據庫設計符合3NF或BCNF就可以了。

第四範式

要求把同一表內的多對多關係刪除。

第五範式

從最終結構重新建立原始結構。

8.連接

內連接

只連接匹配的行

左外連接

包含左邊表的全部行(不管右邊的表中是否存在與它們匹配的行),以及右邊表中全部匹配的行

右外連接

包含右邊表的全部行(不管左邊的表中是否存在與它們匹配的行),以及左邊表中全部匹配的行

全外連接

包含左、右兩個表的全部行,不管另外一邊的表中是否存在與它們匹配的行。

交叉連接

生成笛卡爾積-它不使用任何匹配或者選取條件,而是直接將一個數據源中的每個行與另一個數據源的每個行都一一匹配

9.varchar和char的使用場景

1.char的長度是不可變的,而varchar的長度是可變的。
定義一個char[10]和varchar[10]。
如果存進去的是‘csdn’,那麼char所佔的長度依然爲10,除了字符‘csdn’外,後面跟六個空格,varchar就立馬把長度變爲4了,取數據的時候,char類型的要用trim()去掉多餘的空格,而varchar是不需要的。

2.char的存取數度還是要比varchar要快得多,因爲其長度固定,方便程序的存儲與查找。
char也爲此付出的是空間的代價,因爲其長度固定,所以難免會有多餘的空格佔位符佔據空間,可謂是以空間換取時間效率。
varchar是以空間效率爲首位。

3.char的存儲方式是:對英文字符(ASCII)佔用1個字節,對一個漢字佔用兩個字節。
varchar的存儲方式是:對每個英文字符佔用2個字節,漢字也佔用2個字節。

4.兩者的存儲數據都非unicode的字符數據。

10.SQL語言分類

SQL語言共分爲四大類:

數據查詢語言DQL
數據操縱語言DML
數據定義語言DDL
數據控制語言DCL

  1. 數據查詢語言DQL

數據查詢語言DQL基本結構是由SELECT子句,FROM子句,WHERE子句組成的查詢塊:

SELECT
FROM
WHERE

2 .數據操縱語言DML

數據操縱語言DML主要有三種形式:

  1. 插入:INSERT
  2. 更新:UPDATE
  3. 刪除:DELETE
  1. 數據定義語言DDL

數據定義語言DDL用來創建數據庫中的各種對象-----表、視圖、索引、同義詞、聚簇等如:
CREATE TABLE/VIEW/INDEX/SYN/CLUSTER

表 視圖 索引 同義詞 簇

DDL操作是隱性提交的!不能rollback

  1. 數據控制語言DCL

數據控制語言DCL用來授予或回收訪問數據庫的某種特權,並控制數據庫操縱事務發生的時間及效果,對數據庫實行監視等。如:

  1. GRANT:授權。
  2. ROLLBACK [WORK] TO [SAVEPOINT]:回退到某一點。回滾—ROLLBACK;回滾命令使數據庫狀態回到上次最後提交的狀態。其格式爲:
    SQL>ROLLBACK;
  3. COMMIT [WORK]:提交。

在數據庫的插入、刪除和修改操作時,只有當事務在提交到數據
庫時纔算完成。在事務提交前,只有操作數據庫的這個人才能有權看
到所做的事情,別人只有在最後提交完成後纔可以看到。
提交數據有三種類型:顯式提交、隱式提交及自動提交。下面分
別說明這三種類型。

(1) 顯式提交
用COMMIT命令直接完成的提交爲顯式提交。其格式爲:
SQL>COMMIT;

(2) 隱式提交
用SQL命令間接完成的提交爲隱式提交。這些命令是:
ALTER,AUDIT,COMMENT,CONNECT,CREATE,DISCONNECT,DROP,
EXIT,GRANT,NOAUDIT,QUIT,REVOKE,RENAME。

(3) 自動提交
若把AUTOCOMMIT設置爲ON,則在插入、修改、刪除語句執行後,
系統將自動進行提交,這就是自動提交。其格式爲:
SQL>SET AUTOCOMMIT ON;

11.數據庫設計的六個階段

1.需求分析

分析用戶需求(數據、功能和性能需求)

2.概念結構設計

主要採用E-R模型設計

3.邏輯結構設計

通過將E-R圖轉換成表實現E-R模型到關係模型的轉換,進行關係規範化

4.數據庫物理設計

主要是爲所設計的數據庫選擇合適的存儲結構和存儲路徑

5.數據庫的實施

編程、測試和試運行

6.數據庫運行和維護

系統的運行和數據庫的日常維護

二、索引

1.什麼是索引

數據庫索引,是數據庫管理系統中一個排序的數據結構,索引的實現通常使用B樹及其變種B+樹。

在數據之外,數據庫系統還維護着滿足特定查找算法的數據結構,這些數據結構以某種方式引用(指向)數據,這樣就可以在這些數據結構上實現高級查找算法。這種數據結構,就是索引。

2.索引的作用

索引作用:

協助快速查詢、更新數據庫表中數據。

爲表設置索引要付出代價的:

一是增加了數據庫的存儲空間
二是在插入和修改數據時要花費較多的時間(因爲索引也要隨之變動)。

3.索引的優缺點

創建索引可以大大提高系統的性能(優點):

1.通過創建唯一性索引,可以保證數據庫表中每一行數據的唯一性。
2.可以大大加快數據的檢索速度,這也是創建索引的最主要的原因。
3.可以加速表和表之間的連接,特別是在實現數據的參考完整性方面特別有意義。
4.在使用分組和排序子句進行數據檢索時,同樣可以顯著減少查詢中分組和排序的時間。
5.通過使用索引,可以在查詢的過程中,使用優化隱藏器,提高系統的性能。

增加索引也有許多不利的方面(缺點):

1.創建索引和維護索引要耗費時間,這種時間隨着數據量的增加而增加。
2.索引需要佔物理空間,除了數據表佔數據空間之外,每一個索引還要佔一定的物理空間,如果要建立聚簇索引,那麼需要的空間就會更大。
3.當對錶中的數據進行增加、刪除和修改的時候,索引也要動態的維護,這樣就降低了數據的維護速度

4.哪些列適合建立索引、哪些不適合建索引?

索引是建立在數據庫表中的某些列的上面。在創建索引的時候,應該考慮在哪些列上可以創建索引,在哪些列上不能創建索引。

一般來說,應該在這些列上創建索引:

(1)在經常需要搜索的列上,可以加快搜索的速度;
(2)在作爲主鍵的列上,強制該列的唯一性和組織表中數據的排列結構;
(3)在經常用在連接的列上,這些列主要是一些外鍵,可以加快連接的速度;
(4)在經常需要根據範圍進行搜索的列上創建索引,因爲索引已經排序,其指定的範圍是連續的;
(5)在經常需要排序的列上創建索引,因爲索引已經排序,這樣查詢可以利用索引的排序,加快排序查詢時間;
(6)在經常使用在WHERE子句中的列上面創建索引,加快條件的判斷速度。

對於有些列不應該創建索引:

(1)對於那些在查詢中很少使用或者參考的列不應該創建索引。
這是因爲,既然這些列很少使用到,因此有索引或者無索引,並不能提高查詢速度。相反,由於增加了索引,反而降低了系統的維護速度和增大了空間需求。

(2)對於那些只有很少數據值的列也不應該增加索引。
這是因爲,由於這些列的取值很少,例如人事表的性別列,在查詢的結果中,結果集的數據行佔了表中數據行的很大比例,即需要在表中搜索的數據行的比例很大。增加索引,並不能明顯加快檢索速度。

(3)對於那些定義爲text, image和bit數據類型的列不應該增加索引。
這是因爲,這些列的數據量要麼相當大,要麼取值很少。

(4)當修改性能遠遠大於檢索性能時,不應該創建索引。
這是因爲,修改性能和檢索性能是互相矛盾的。當增加索引時,會提高檢索性能,但是會降低修改性能。當減少索引時,會提高修改性能,降低檢索性能。因此,當修改性能遠遠大於檢索性能時,不應該創建索引。

5.什麼樣的字段適合建索引

唯一、不爲空、經常被查詢的字段

6.MySQL B+Tree索引和Hash索引的區別?

Hash索引和B+樹索引的特點:

Hash索引結構的特殊性,其檢索效率非常高,索引的檢索可以一次定位;
B+樹索引需要從根節點到枝節點,最後才能訪問到頁節點這樣多次的IO訪問;

爲什麼不都用Hash索引而使用B+樹索引?

(1)Hash索引僅僅能滿足"=",“IN"和”"查詢,不能使用範圍查詢,因爲經過相應的Hash算法處理之後的Hash值的大小關係,並不能保證和Hash運算前完全一樣;
(2)Hash索引無法被用來避免數據的排序操作,因爲Hash值的大小關係並不一定和Hash運算前的鍵值完全一樣;
(3)Hash索引不能利用部分索引鍵查詢,對於組合索引,Hash索引在計算Hash值的時候是組合索引鍵合併後再一起計算Hash值,而不是單獨計算Hash值,所以通過組合索引的前面一個或幾個索引鍵進行查詢的時候,Hash索引也無法被利用;
(4)Hash索引在任何時候都不能避免表掃描,由於不同索引鍵存在相同Hash值,所以即使取滿足某個Hash鍵值的數據的記錄條數,也無法從Hash索引中直接完成查詢,還是要回表查詢數據;
(5)Hash索引遇到大量Hash值相等的情況後性能並不一定就會比B+樹索引高。

補充:

1.MySQL中,只有HEAP/MEMORY引擎才顯示支持Hash索引。
2.常用的InnoDB引擎中默認使用的是B+樹索引,它會實時監控表上索引的使用情況,如果認爲建立哈希索引可以提高查詢效率,則自動在內存中的“自適應哈希索引緩衝區”建立哈希索引(在InnoDB中默認開啓自適應哈希索引),通過觀察搜索模式,MySQL會利用index key的前綴建立哈希索引,如果一個表幾乎大部分都在緩衝池中,那麼建立一個哈希索引能夠加快等值查詢。
3.如果是等值查詢,那麼哈希索引明顯有絕對優勢,因爲只需要經過一次算法即可找到相應的鍵值;當然了,這個前提是,鍵值都是唯一的。如果鍵值不是唯一的,就需要先找到該鍵所在位置,然後再根據鏈表往後掃描,直到找到相應的數據;
4.如果是範圍查詢檢索,這時候哈希索引就毫無用武之地了,因爲原先是有序的鍵值,經過哈希算法後,有可能變成不連續的了,就沒辦法再利用索引完成範圍查詢檢索;
同理,哈希索引沒辦法利用索引完成排序,以及like ‘xxx%’ 這樣的部分模糊查詢(這種部分模糊查詢,其實本質上也是範圍查詢);
5.哈希索引也不支持多列聯合索引的最左匹配規則;
6.B+樹索引的關鍵字檢索效率比較平均,不像B樹那樣波動幅度大,在有大量重複鍵值情況下,哈希索引的效率也是極低的,因爲存在所謂的哈希碰撞問題。
7.在大多數場景下,都會有範圍查詢、排序、分組等查詢特徵,用B+樹索引就可以了。

7.B樹和B+樹的區別

B樹,每個節點都存儲key和data,所有節點組成這棵樹,並且葉子節點指針爲nul,葉子結點不包含任何關鍵字信息。

B+樹,所有的葉子結點中包含了全部關鍵字的信息,及指向含有這些關鍵字記錄的指針,且葉子結點本身依關鍵字的大小自小而大的順序鏈接,所有的非終端結點可以看成是索引部分,結點中僅含有其子樹根結點中最大(或最小)關鍵字。 (而B 樹的非終節點也包含需要查找的有效信息)

8.爲什麼說B+比B樹更適合實際應用中操作系統的文件索引和數據庫索引?

1.B+的磁盤讀寫代價更低

B+的內部結點並沒有指向關鍵字具體信息的指針。因此其內部結點相對B樹更小。如果把所有同一內部結點的關鍵字存放在同一盤塊中,那麼盤塊所能容納的關鍵字數量也越多。一次性讀入內存中的需要查找的關鍵字也就越多。相對來說IO讀寫次數也就降低了。

2.B+tree的查詢效率更加穩定

由於非終結點並不是最終指向文件內容的結點,而只是葉子結點中關鍵字的索引。所以任何關鍵字的查找必須走一條從根結點到葉子結點的路。所有關鍵字查詢的路徑長度相同,導致每一個數據的查詢效率相當。

9.聚集索引和非聚集索引區別?

聚合索引(clustered index):

聚集索引表記錄的排列順序和索引的排列順序一致,所以查詢效率快,只要找到第一個索引值記錄,其餘就連續性的記錄在物理也一樣連續存放。聚集索引對應的缺點就是修改慢,因爲爲了保證表中記錄的物理和索引順序一致,在記錄插入的時候,會對數據頁重新排序。
聚集索引類似於新華字典中用拼音去查找漢字,拼音檢索表於書記順序都是按照a~z排列的,就像相同的邏輯順序於物理順序一樣,當你需要查找a,ai兩個讀音的字,或是想一次尋找多個傻(sha)的同音字時,也許向後翻幾頁,或緊接着下一行就得到結果了。

非聚合索引(nonclustered index):

非聚集索引指定了表中記錄的邏輯順序,但是記錄的物理和索引不一定一致,兩種索引都採用B+樹結構,非聚集索引的葉子層並不和實際數據頁相重疊,而採用葉子層包含一個指向表中的記錄在數據頁中的指針方式。非聚集索引層次多,不會造成數據重排。
非聚集索引類似在新華字典上通過偏旁部首來查詢漢字,檢索表也許是按照橫、豎、撇來排列的,但是由於正文中是a~z的拼音順序,所以就類似於邏輯地址於物理地址的不對應。同時適用的情況就在於分組,大數目的不同值,頻繁更新的列中,這些情況即不適合聚集索引。

根本區別:

聚集索引和非聚集索引的根本區別是表記錄的排列順序和與索引的排列順序是否一致。

三、事務

1.什麼是事務?

事務是對數據庫中一系列讀/寫操作進行統一的回滾或者提交的操作,主要用來保證數據的完整性和一致性。
多個應用程序在併發訪問數據庫時,可以提供隔離。
事務提交給DBMS,確保全部執行成功並保存結果,否則:回滾至事務執行前,所有事物相互獨立,互不影響。

2.事務四大特性(ACID)原子性、一致性、隔離性、持久性

原子性(Atomicity):

原子性是指事務包含的所有操作要麼全部成功,要麼全部失敗回滾,因此事務的操作如果成功就必須要完全應用到數據庫,如果操作失敗則不能對數據庫有任何影響。

一致性(Consistency):

事務開始前和結束後,數據庫的完整性約束沒有被破壞。比如A向B轉賬,不可能A扣了錢,B卻沒收到。

隔離性(Isolation):

隔離性是當多個用戶併發訪問數據庫時,比如操作同一張表時,數據庫爲每一個用戶開啓的事務,不能被其他事務的操作所幹擾,多個併發事務之間要相互隔離。同一時間,只允許一個事務請求同一數據,不同的事務之間彼此沒有任何干擾。比如A正在從一張銀行卡中取錢,在A取錢的過程結束前,B不能向這張卡轉賬。

持久性(Durability):

持久性是指一個事務一旦被提交了,那麼對數據庫中的數據的改變就是永久性的,即便是在數據庫系統遇到故障的情況下也不會丟失提交事務的操作。

3.事務的併發問題

1、髒讀:事務A讀取了事務B更新的數據,然後B回滾操作,那麼A讀取到的數據是髒數據

2、不可重複讀:事務 A 多次讀取同一數據,事務 B 在事務A多次讀取的過程中,對數據作了更新並提交,導致事務A多次讀取同一數據時,結果因此本事務先後兩次讀到的數據結果會不一致。

3、幻讀:幻讀解決了不重複讀,保證了同一個事務裏,查詢的結果都是事務開始時的狀態(一致性)。

例如:事務T1對一個表中所有的行的某個數據項做了從“1”修改爲“2”的操作 這時事務T2又對這個表中插入了一行數據項,而這個數據項的數值還是爲“1”並且提交給數據庫。 而操作事務T1的用戶如果再查看剛剛修改的數據,會發現還有跟沒有修改一樣,其實這行是從事務T2中添加的,就好像產生幻覺一樣,這就是發生了幻讀。

4、更新丟失:同時更新一行數據,一個事務把另一個事務的更新覆蓋了。

小結:不可重複讀的和幻讀很容易混淆,不可重複讀側重於修改,幻讀側重於新增或刪除。解決不可重複讀的問題只需鎖住滿足條件的行,解決幻讀需要鎖表。

4.事務的隔離級別

讀未提交

另一個事務修改了數據,但尚未提交,而本事務中的SELECT會讀到這些未被提交的數據髒讀

允許髒讀,只處理更新丟失。事務A寫,另一事務不允許寫,但可讀。“排他寫鎖”

不可重複讀(讀提交)

事務 A 多次讀取同一數據,事務 B 在事務A多次讀取的過程中,對數據作了更新並提交,導致事務A多次讀取同一數據時,結果因此本事務先後兩次讀到的數據結果會不一致。

處理更新丟失、髒讀。事務A讀,允許其他事務訪問;事務A寫,不允許其他事務訪問。“瞬間共享讀鎖”、“排他寫鎖”

可重複讀

在同一個事務裏,SELECT的結果是事務開始時時間點的狀態,因此,同樣的SELECT操作讀到的結果會是一致的。但是,會有幻讀現象

處理更新丟失、髒讀和不可重複度。事務A讀,允許其他事務讀,不允許寫;事務A寫,不允許其他事務訪問。“共享讀鎖”、“排他寫鎖”

串行化

最高的隔離級別,在這個隔離級別下,不會產生任何異常。併發的事務,就像事務是在一個個按照順序執行一樣

提供嚴格的事務隔離。不能併發執行,鎖無法實現。

以上隔離級別,越高,越能保證完整性和一致性,但併發性會越低。一般首選讀提交

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章