事務四大特性（ACID）原子性、一致性、隔離性、永續性？

原子性（Atomicity）

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

一致性（Consistency）

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

隔離性（Isolation）

隔離性是當多個使用者併發訪問資料庫時，比如操作同一張表時，資料庫為每一個使用者開啟的事務，不能被其他事務的操作所幹擾，多個併發事務之間要相互隔離。

同一時間，只允許一個事務請求同一資料，不同的事務之間彼此沒有任何干擾。比如A正在從一張銀行卡中取錢，在A取錢的過程結束前，B不能向這張卡轉賬。

關於事務的隔離性資料庫提供了多種隔離級別，稍後會介紹到。　永續性（Durability）

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

事務的併發？事務隔離級別，每個級別會引發什麼問題，MySQL預設是哪個級別？

從理論上來說, 事務應該彼此完全隔離, 以避免併發事務所導致的問題，然而, 那樣會對效能產生極大的影響, 因為事務必須按順序執行，在實際開發中, 為了提升效能, 事務會以較低的隔離級別執行，事務的隔離級別可以通過隔離事務屬性指定。

事務的併發問題

1、髒讀：事務A讀取了事務B更新的資料，然後B回滾操作，那麼A讀取到的資料是髒資料

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

3、幻讀：幻讀解決了不重複讀，保證了同一個事務裡，查詢的結果都是事務開始時的狀態（一致性）。

例如：事務T1對一個表中所有的行的某個資料項做了從“1”修改為“2”的操作這時事務T2又對這個表中插入了一行資料項，而這個資料項的數值還是為“1”並且提交給資料庫。而操作事務T1的使用者如果再檢視剛剛修改的資料，會發現還有跟沒有修改一樣，其實這行是從事務T2中新增的，就好像產生幻覺一樣，這就是發生了幻讀。

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

事務的隔離級別

事務隔離級別	髒讀	不可重複讀	幻讀
讀未提交 read-uncommitted	是	是	是
不可重複讀 read-committed	否	是	是
可重複讀 repeatable-read	否	否	是
序列化 serializable	否	否	否

讀未提交：另一個事務修改了資料，但尚未提交，而本事務中的SELECT會讀到這些未被提交的資料髒讀
不可重複讀：事務 A 多次讀取同一資料，事務 B 在事務A多次讀取的過程中，對資料作了更新並提交，導致事務A多次讀取同一資料時，結果因此本事務先後兩次讀到的資料結果會不一致。
可重複讀：在同一個事務裡，SELECT的結果是事務開始時時間點的狀態，因此，同樣的SELECT操作讀到的結果會是一致的。但是，會有幻讀現象
序列化：最高的隔離級別，在這個隔離級別下，不會產生任何異常。併發的事務，就像事務是在一個個按照順序執行一樣

MySQL預設的事務隔離級別為repeatable-read

MySQL 支援 4 中事務隔離級別.
事務的隔離級別要得到底層資料庫引擎的支援, 而不是應用程式或者框架的支援.
Oracle 支援的 2 種事務隔離級別：READ_COMMITED , SERIALIZABLE

補充：

SQL規範所規定的標準，不同的資料庫具體的實現可能會有些差異
MySQL中預設事務隔離級別是“可重複讀”時並不會鎖住讀取到的行

事務隔離級別：未提交讀時，寫資料只會鎖住相應的行。
事務隔離級別為：可重複讀時，寫資料會鎖住整張表。
事務隔離級別為：序列化時，讀寫資料都會鎖住整張表。

隔離級別越高，越能保證資料的完整性和一致性，但是對併發效能的影響也越大，魚和熊掌不可兼得啊。對於多數應用程式，可以優先考慮把資料庫系統的隔離級別設為Read Committed，它能夠避免髒讀取，而且具有較好的併發效能。儘管它會導致不可重複讀、幻讀這些併發問題，在可能出現這類問題的個別場合，可以由應用程式採用悲觀鎖或樂觀鎖來控制。

MySQL常見的三種儲存引擎（InnoDB、MyISAM、MEMORY）的區別？

MySQL儲存引擎中的MyISAM和InnoDB區別詳解

MySQL儲存引擎之MyISAM和Innodb總結性梳理

MySQL儲存引擎MyISAM與InnoDB如何選擇

MySQL有多種儲存引擎，每種儲存引擎有各自的優缺點，可以擇優選擇使用：MyISAM、InnoDB、MERGE、MEMORY(HEAP)、BDB(BerkeleyDB)、EXAMPLE、FEDERATED、ARCHIVE、CSV、BLACKHOLE。

雖然MySQL裡的儲存引擎不只是MyISAM與InnoDB這兩個，但常用的就是兩個。

兩種儲存引擎的大致區別表現在：

InnoDB支援事務，MyISAM不支援，這一點是非常之重要。事務是一種高階的處理方式，如在一些列增刪改中只要哪個出錯還可以回滾還原，而MyISAM就不可以了。
MyISAM適合查詢以及插入為主的應用。
InnoDB適合頻繁修改以及涉及到安全性較高的應用。
InnoDB支援外來鍵，MyISAM不支援。
從MySQL5.5.5以後，InnoDB是預設引擎。
InnoDB不支援FULLTEXT型別的索引。
InnoDB中不儲存表的行數，如select count(*) from table時，InnoDB需要掃描一遍整個表來計算有多少行，但是MyISAM只要簡單的讀出儲存好的行數即可。注意的是，當count(*)語句包含where條件時MyISAM也需要掃描整個表。
對於自增長的欄位，InnoDB中必須包含只有該欄位的索引，但是在MyISAM表中可以和其他欄位一起建立聯合索引。
DELETE FROM table時，InnoDB不會重新建立表，而是一行一行的刪除，效率非常慢。MyISAM則會重建表。
InnoDB支援行鎖（某些情況下還是鎖整表，如 update table set a=1 where user like '%lee%'。

關於MySQL資料庫提供的兩種儲存引擎，MyISAM與InnoDB選擇使用：

INNODB會支援一些關係資料庫的高階功能，如事務功能和行級鎖，MyISAM不支援。
MyISAM的效能更優，佔用的儲存空間少，所以，選擇何種儲存引擎，視具體應用而定。
如果你的應用程式一定要使用事務，毫無疑問你要選擇INNODB引擎。但要注意，INNODB的行級鎖是有條件的。在where條件沒有使用主鍵時，照樣會鎖全表。比如DELETE FROM mytable這樣的刪除語句。
如果你的應用程式對查詢效能要求較高，就要使用MyISAM了。MyISAM索引和資料是分開的，而且其索引是壓縮的，可以更好地利用記憶體。所以它的查詢效能明顯優於INNODB。壓縮後的索引也能節約一些磁碟空間。MyISAM擁有全文索引的功能，這可以極大地優化LIKE查詢的效率。

有人說MyISAM只能用於小型應用，其實這只是一種偏見。如果資料量比較大，這是需要通過升級架構來解決，比如分表分庫，而不是單純地依賴儲存引擎。

現在一般都是選用innodb了，主要是MyISAM的全表鎖，讀寫序列問題，併發效率鎖表，效率低，MyISAM對於讀寫密集型應用一般是不會去選用的。

MEMORY儲存引擎

MEMORY是MySQL中一類特殊的儲存引擎。它使用儲存在記憶體中的內容來建立表，而且資料全部放在記憶體中。這些特性與前面的兩個很不同。

每個基於MEMORY儲存引擎的表實際對應一個磁碟檔案。該檔案的檔名與表名相同，型別為frm型別。該檔案中只儲存表的結構。而其資料檔案，都是儲存在記憶體中，這樣有利於資料的快速處理，提高整個表的效率。值得注意的是，伺服器需要有足夠的記憶體來維持MEMORY儲存引擎的表的使用。如果不需要了，可以釋放記憶體，甚至刪除不需要的表。

MEMORY預設使用雜湊索引。速度比使用B型樹索引快。當然如果你想用B型樹索引，可以在建立索引時指定。

注意，MEMORY用到的很少，因為它是把資料存到記憶體中，如果記憶體出現異常就會影響資料。如果重啟或者關機，所有資料都會消失。因此，基於MEMORY的表的生命週期很短，一般是一次性的。

MySQL的MyISAM與InnoDB兩種儲存引擎在，事務、鎖級別，各自的適用場景？

事務處理上方面

MyISAM：強調的是效能，每次查詢具有原子性,其執行數度比InnoDB型別更快，但是不提供事務支援。
InnoDB：提供事務支援事務，外部鍵等高階資料庫功能。具有事務(commit)、回滾(rollback)和崩潰修復能力(crash recovery capabilities)的事務安全(transaction-safe (ACID compliant))型表。

鎖級別

MyISAM：只支援表級鎖，使用者在操作MyISAM表時，select，update，delete，insert語句都會給表自動加鎖，如果加鎖以後的表滿足insert併發的情況下，可以在表的尾部插入新的資料。
InnoDB：支援事務和行級鎖，是innodb的最大特色。行鎖大幅度提高了多使用者併發操作的新能。但是InnoDB的行鎖，只是在WHERE的主鍵是有效的，非主鍵的WHERE都會鎖全表的。

查詢語句不同元素（where、jion、limit、group by、having等等）執行先後順序？

1.查詢中用到的關鍵詞主要包含六個，並且他們的順序依次為 select--from--where--group by--having--order by

其中select和from是必須的，其他關鍵詞是可選的，這六個關鍵詞的執行順序與sql語句的書寫順序並不是一樣的，而是按照下面的順序來執行

from:需要從哪個資料表檢索資料
where:過濾表中資料的條件
group by:如何將上面過濾出的資料分組
having:對上面已經分組的資料進行過濾的條件
select:檢視結果集中的哪個列，或列的計算結果
order by :按照什麼樣的順序來檢視返回的資料

2.from後面的表關聯，是自右向左解析而where條件的解析順序是自下而上的。

也就是說，在寫SQL文的時候，儘量把資料量小的表放在最右邊來進行關聯（用小表去匹配大表），而把能篩選出小量資料的條件放在where語句的最左邊（用小表去匹配大表）

什麼是臨時表，臨時表什麼時候刪除？

時表可以手動刪除：

DROP TEMPORARY TABLE IF EXISTS temp_tb;

臨時表只在當前連線可見，當關閉連線時，MySQL會自動刪除表並釋放所有空間。因此在不同的連線中可以建立同名的臨時表，並且操作屬於本連線的臨時表。

建立臨時表的語法與建立表語法類似，不同之處是增加關鍵字TEMPORARY，如：

CREATE TEMPORARY TABLE tmp_table (
	NAME VARCHAR (10) NOT NULL,
	time date NOT NULL
);

select * from tmp_table;

MySQL B+Tree索引和Hash索引的區別？

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

那為什麼大家不都用Hash索引而還要使用B+樹索引呢？

Hash索引

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

B+Tree索引

MySQL中，只有HEAP/MEMORY引擎才顯示支援Hash索引。

常用的InnoDB引擎中預設使用的是B+樹索引，它會實時監控表上索引的使用情況，如果認為建立雜湊索引可以提高查詢效率，則自動在記憶體中的“自適應雜湊索引緩衝區”建立雜湊索引（在InnoDB中預設開啟自適應雜湊索引），通過觀察搜尋模式，MySQL會利用index key的字首建立雜湊索引，如果一個表幾乎大部分都在緩衝池中，那麼建立一個雜湊索引能夠加快等值查詢。

B+樹索引和雜湊索引的明顯區別是：

如果是等值查詢，那麼雜湊索引明顯有絕對優勢，因為只需要經過一次演算法即可找到相應的鍵值；當然了，這個前提是，鍵值都是唯一的。如果鍵值不是唯一的，就需要先找到該鍵所在位置，然後再根據連結串列往後掃描，直到找到相應的資料；

如果是範圍查詢檢索，這時候雜湊索引就毫無用武之地了，因為原先是有序的鍵值，經過雜湊演算法後，有可能變成不連續的了，就沒辦法再利用索引完成範圍查詢檢索；

同理，雜湊索引沒辦法利用索引完成排序，以及like ‘xxx%’ 這樣的部分模糊查詢（這種部分模糊查詢，其實本質上也是範圍查詢）；

雜湊索引也不支援多列聯合索引的最左匹配規則；

B+樹索引的關鍵字檢索效率比較平均，不像B樹那樣波動幅度大，在有大量重複鍵值情況下，雜湊索引的效率也是極低的，因為存在所謂的雜湊碰撞問題。

在大多數場景下，都會有範圍查詢、排序、分組等查詢特徵，用B+樹索引就可以了。

sql查詢語句確定建立哪種型別的索引，如何優化查詢

效能優化過程中，選擇在哪個列上建立索引是最重要的步驟之一，可以考慮使用索引的主要有兩種型別的列：在where子句中出現的列，在join子句中出現的列。
考慮列中值的分佈，索引的列的基數越大，索引的效果越好。
使用短索引，如果對字串列進行索引，應該指定一個字首長度，可節省大量索引空間，提升查詢速度。
利用最左字首,顧名思義，就是最左優先，在多列索引，有體現:(ALTER TABLE people ADD INDEX lname_fname_age (lame,fname,age);)，所謂最左字首原則就是先要看第一列，在第一列滿足的條件下再看左邊第二列，以此類推
不要過度建索引，只保持所需的索引。每個額外的索引都要佔用額外的磁碟空間，並降低寫操作的效能。
在修改表的內容時，索引必須進行更新，有時可能需要重構，因此，索引越多，所花的時間越長。
MySQL只對一下操作符才使用索引：<,<=,=,>,>=,between,in
以及某些時候的like(不以萬用字元%或_開頭的情形)。

聚集索引和非聚集索引區別？

聚合索引(clustered index) / 非聚合索引(nonclustered index)

根本區別

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

聚集索引

聚集索引表記錄的排列順序和索引的排列順序一致，所以查詢效率快，只要找到第一個索引值記錄，其餘就連續性的記錄在物理也一樣連續存放。聚集索引對應的缺點就是修改慢，因為為了保證表中記錄的物理和索引順序一致，在記錄插入的時候，會對資料頁重新排序。

聚集索引類似於新華字典中用拼音去查詢漢字，拼音檢索表於書記順序都是按照a~z排列的，就像相同的邏輯順序於物理順序一樣，當你需要查詢a,ai兩個讀音的字，或是想一次尋找多個傻(sha)的同音字時，也許向後翻幾頁，或緊接著下一行就得到結果了。

非聚集索引

非聚集索引制定了表中記錄的邏輯順序，但是記錄的物理和索引不一定一致，兩種索引都採用B+樹結構，非聚集索引的葉子層並不和實際資料頁相重疊，而採用葉子層包含一個指向表中的記錄在資料頁中的指標方式。非聚集索引層次多，不會造成資料重排。

非聚集索引類似在新華字典上通過偏旁部首來查詢漢字，檢索表也許是按照橫、豎、撇來排列的，但是由於正文中是a~z的拼音順序，所以就類似於邏輯地址於物理地址的不對應。同時適用的情況就在於分組，大數目的不同值，頻繁更新的列中，這些情況即不適合聚集索引。

有哪些鎖（樂觀鎖悲觀鎖），select 時怎麼加排它鎖？

悲觀鎖（Pessimistic Lock）

悲觀鎖的特點是先獲取鎖，再進行業務操作，即“悲觀”的認為獲取鎖是非常有可能失敗的，因此要先確保獲取鎖成功再進行業務操作。通常所說的“一鎖二查三更新”即指的是使用悲觀鎖。通常來講在資料庫上的悲觀鎖需要資料庫本身提供支援，即通過常用的select … for update操作來實現悲觀鎖。當資料庫執行select for update時會獲取被select中的資料行的行鎖，因此其他併發執行的select for update如果試圖選中同一行則會發生排斥（需要等待行鎖被釋放），因此達到鎖的效果。select for update獲取的行鎖會在當前事務結束時自動釋放，因此必須在事務中使用。

這裡需要注意的一點是不同的資料庫對select for update的實現和支援都是有所區別的，例如oracle支援select for update no wait，表示如果拿不到鎖立刻報錯，而不是等待，MySQL就沒有no wait這個選項。另外MySQL還有個問題是select for update語句執行中所有掃描過的行都會被鎖上，這一點很容易造成問題。因此如果在MySQL中用悲觀鎖務必要確定走了索引，而不是全表掃描。

樂觀鎖（Optimistic Lock）

樂觀鎖，也叫樂觀併發控制，它假設多使用者併發的事務在處理時不會彼此互相影響，各事務能夠在不產生鎖的情況下處理各自影響的那部分資料。在提交資料更新之前，每個事務會先檢查在該事務讀取資料後，有沒有其他事務又修改了該資料。如果其他事務有更新的話，那麼當前正在提交的事務會進行回滾。

樂觀鎖的特點先進行業務操作，不到萬不得已不去拿鎖。即“樂觀”的認為拿鎖多半是會成功的，因此在進行完業務操作需要實際更新資料的最後一步再去拿一下鎖就好。

樂觀鎖在資料庫上的實現完全是邏輯的，不需要資料庫提供特殊的支援。一般的做法是在需要鎖的資料上增加一個版本號，或者時間戳，然後按照如下方式實現：

樂觀鎖（給表加一個版本號欄位）這個並不是樂觀鎖的定義，給表加版本號，是資料庫實現樂觀鎖的一種方式。

1. SELECT data AS old_data, version AS old_version FROM …;
2. 根據獲取的資料進行業務操作，得到new_data和new_version
3. UPDATE SET data = new_data, version = new_version WHERE version = old_version
if (updated row > 0) {
    // 樂觀鎖獲取成功，操作完成
} else {
    // 樂觀鎖獲取失敗，回滾並重試
}

樂觀鎖在不發生取鎖失敗的情況下開銷比悲觀鎖小，但是一旦發生失敗回滾開銷則比較大，因此適合用在取鎖失敗概率比較小的場景，可以提升系統併發效能

樂觀鎖還適用於一些比較特殊的場景，例如在業務操作過程中無法和資料庫保持連線等悲觀鎖無法適用的地方。

總結

悲觀鎖和樂觀鎖是資料庫用來保證資料併發安全防止更新丟失的兩種方法，例子在select ... for update前加個事務就可以防止更新丟失。悲觀鎖和樂觀鎖大部分場景下差異不大，一些獨特場景下有一些差別，一般我們可以從如下幾個方面來判斷。

響應速度：如果需要非常高的響應速度，建議採用樂觀鎖方案，成功就執行，不成功就失敗，不需要等待其他併發去釋放鎖。
衝突頻率：如果衝突頻率非常高，建議採用悲觀鎖，保證成功率，如果衝突頻率大，樂觀鎖會需要多次重試才能成功，代價比較大。
重試代價：如果重試代價大，建議採用悲觀鎖。

非關係型資料庫和關係型資料庫區別，優勢比較？

非關係型資料庫的優勢：

1. 效能

NOSQL是基於鍵值對的，可以想象成表中的主鍵和值的對應關係，而且不需要經過SQL層的解析，所以效能非常高。

2. 可擴充套件性

同樣也是因為基於鍵值對，資料之間沒有耦合性，所以非常容易水平擴充套件。

關係型資料庫的優勢：

1. 複雜查詢

可以用SQL語句方便的在一個表以及多個表之間做非常複雜的資料查詢。

2. 事務支援

使得對於安全效能很高的資料訪問要求得以實現。

總結

對於這兩類資料庫，對方的優勢就是自己的弱勢，反之亦然。

NOSQL資料庫慢慢開始具備SQL資料庫的一些複雜查詢功能，比如MongoDB。

對於事務的支援也可以用一些系統級的原子操作來實現例如樂觀鎖之類的方法來曲線救國，比如Redis set nx。

資料庫三正規化，根據某個場景設計資料表？

所有欄位值都是不可分解的原子值。
在一個數據庫表中，一個表中只能儲存一種資料，不可以把多種資料儲存在同一張資料庫表中。
資料表中的每一列資料都和主鍵直接相關，而不能間接相關。

第一正規化(確保每列保持原子性)

第一正規化是最基本的正規化。如果資料庫表中的所有欄位值都是不可分解的原子值，就說明該資料庫表滿足了第一正規化。

第一正規化的合理遵循需要根據系統的實際需求來定。比如某些資料庫系統中需要用到“地址”這個屬性，本來直接將“地址”屬性設計成一個數據庫表的欄位就行。但是如果系統經常會訪問“地址”屬性中的“城市”部分，那麼就非要將“地址”這個屬性重新拆分為省份、城市、詳細地址等多個部分進行儲存，這樣在對地址中某一部分操作的時候將非常方便。這樣設計才算滿足了資料庫的第一正規化，如下表所示。

上表所示的使用者資訊遵循了第一正規化的要求，這樣在對使用者使用城市進行分類的時候就非常方便，也提高了資料庫的效能。

第二正規化(確保表中的每列都和主鍵相關)

第二正規化在第一正規化的基礎之上更進一層。第二正規化需要確保資料庫表中的每一列都和主鍵相關，而不能只與主鍵的某一部分相關（主要針對聯合主鍵而言）。也就是說在一個數據庫表中，一個表中只能儲存一種資料，不可以把多種資料儲存在同一張資料庫表中。

比如要設計一個訂單資訊表，因為訂單中可能會有多種商品，所以要將訂單編號和商品編號作為資料庫表的聯合主鍵。

第三正規化(確保每列都和主鍵列直接相關,而不是間接相關)

第三正規化需要確保資料表中的每一列資料都和主鍵直接相關，而不能間接相關。

比如在設計一個訂單資料表的時候，可以將客戶編號作為一個外來鍵和訂單表建立相應的關係。而不可以在訂單表中新增關於客戶其它資訊（比如姓名、所屬公司等）的欄位。

資料庫的讀寫分離、主從複製，主從複製分析的 7 個問題？

主從複製的幾種方式

同步複製

所謂的同步複製，意思是master的變化，必須等待slave-1,slave-2,...,slave-n完成後才能返回。這樣，顯然不可取，也不是MySQL複製的預設設定。比如，在WEB前端頁面上，使用者增加了條記錄，需要等待很長時間。

非同步複製

20個數據庫常見面試題講解