史上最全的數(shù)據(jù)庫面試題，面試必刷！
來源：cnblogs.com/wenxiaofei/p/9853682.html
目錄：
基本概念
索引
事務(wù)
存儲引擎
優(yōu)化
數(shù)據(jù)庫鎖
其他
一、基本概念
1.主鍵、外鍵、超鍵、候選鍵
超鍵：在關(guān)系中能唯一標(biāo)識元組的屬性集稱為關(guān)系模式的超鍵。一個屬性可以為作為一個超鍵，多個屬性組合在一起也可以作為一個超鍵。超鍵包含候選鍵和主鍵。
候選鍵：是最小超鍵，即沒有冗余元素的超鍵。
主鍵：數(shù)據(jù)庫表中對儲存數(shù)據(jù)對象予以唯一和完整標(biāo)識的數(shù)據(jù)列或?qū)傩缘慕M合。一個數(shù)據(jù)列只能有一個主鍵，且主鍵的取值不能缺失，即不能為空值（Null）。
外鍵：在一個表中存在的另一個表的主鍵稱此表的外鍵。
2.為什么用自增列作為主鍵
如果我們定義了主鍵(PRIMARY KEY)，那么InnoDB會選擇主鍵作為聚集索引、
如果沒有顯式定義主鍵，則InnoDB會選擇第一個不包含有NULL值的唯一索引作為主鍵索引、
如果也沒有這樣的唯一索引，則InnoDB會選擇內(nèi)置6字節(jié)長的ROWID作為隱含的聚集索引(ROWID隨著行記錄的寫入而主鍵遞增，這個ROWID不像ORACLE的ROWID那樣可引用，是隱含的)。
數(shù)據(jù)記錄本身被存于主索引（一顆B+Tree）的葉子節(jié)點上。這就要求同一個葉子節(jié)點內(nèi)（大小為一個內(nèi)存頁或磁盤頁）的各條數(shù)據(jù)記錄按主鍵順序存放，因此每當(dāng)有一條新的記錄插入時，MySQL會根據(jù)其主鍵將其插入適當(dāng)?shù)墓?jié)點和位置，如果頁面達(dá)到裝載因子（InnoDB默認(rèn)為15/16），則開辟一個新的頁（節(jié)點）
如果表使用自增主鍵，那么每次插入新的記錄，記錄就會順序添加到當(dāng)前索引節(jié)點的后續(xù)位置，當(dāng)一頁寫滿，就會自動開辟一個新的頁
如果使用非自增主鍵（如果身份證號或?qū)W號等），由于每次插入主鍵的值近似于隨機，因此每次新記錄都要被插到現(xiàn)有索引頁的中間某個位置，此時MySQL不得不為了將新記錄插到合適位置而移動數(shù)據(jù)，甚至目標(biāo)頁面可能已經(jīng)被回寫到磁盤上而從緩存中清掉，此時又要從磁盤上讀回來，這增加了很多開銷，同時頻繁的移動、分頁操作造成了大量的碎片，得到了不夠緊湊的索引結(jié)構(gòu)，后續(xù)不得不通過OPTIMIZE TABLE來重建表并優(yōu)化填充頁面。
3.觸發(fā)器的作用？
觸發(fā)器是一種特殊的存儲過程，主要是通過事件來觸發(fā)而被執(zhí)行的。它可以強化約束，來維護數(shù)據(jù)的完整性和一致性，可以跟蹤數(shù)據(jù)庫內(nèi)的操作從而不允許未經(jīng)許可的更新和變化?？梢月?lián)級運算。如，某表上的觸發(fā)器上包含對另一個表的數(shù)據(jù)操作，而該操作又會導(dǎo)致該表觸發(fā)器被觸發(fā)。
4.什么是存儲過程？用什么來調(diào)用？
存儲過程是一個預(yù)編譯的SQL語句，優(yōu)點是允許模塊化的設(shè)計，就是說只需創(chuàng)建一次，以后在該程序中就可以調(diào)用多次。如果某次操作需要執(zhí)行多次SQL，使用存儲過程比單純SQL語句執(zhí)行要快。
調(diào)用：
1）可以用一個命令對象來調(diào)用存儲過程。
2）可以供外部程序調(diào)用，比如：java程序。
5.存儲過程的優(yōu)缺點？
優(yōu)點：
1）存儲過程是預(yù)編譯過的，執(zhí)行效率高。
2）存儲過程的代碼直接存放于數(shù)據(jù)庫中，通過存儲過程名直接調(diào)用，減少網(wǎng)絡(luò)通訊。
3）安全性高，執(zhí)行存儲過程需要有一定權(quán)限的用戶。
4）存儲過程可以重復(fù)使用，可減少數(shù)據(jù)庫開發(fā)人員的工作量。
缺點：
移植性差
6.存儲過程與函數(shù)的區(qū)別
7.什么叫視圖？游標(biāo)是什么？
視圖：
是一種虛擬的表，具有和物理表相同的功能?？梢詫σ晥D進行增，改，查，操作，試圖通常是有一個表或者多個表的行或列的子集。對視圖的修改會影響基本表。它使得我們獲取數(shù)據(jù)更容易，相比多表查詢。
游標(biāo)：
是對查詢出來的結(jié)果集作為一個單元來有效的處理。游標(biāo)可以定在該單元中的特定行，從結(jié)果集的當(dāng)前行檢索一行或多行?？梢詫Y(jié)果集當(dāng)前行做修改。一般不使用游標(biāo)，但是需要逐條處理數(shù)據(jù)的時候，游標(biāo)顯得十分重要。
8.視圖的優(yōu)缺點
優(yōu)點：
1對數(shù)據(jù)庫的訪問，因為視圖可以有選擇性的選取數(shù)據(jù)庫里的一部分。
2)用戶通過簡單的查詢可以從復(fù)雜查詢中得到結(jié)果。
3)維護數(shù)據(jù)的獨立性，試圖可從多個表檢索數(shù)據(jù)。
4)對于相同的數(shù)據(jù)可產(chǎn)生不同的視圖。
缺點：
性能：查詢視圖時，必須把視圖的查詢轉(zhuǎn)化成對基本表的查詢，如果這個視圖是由一個復(fù)雜的多表查詢所定義，那么，那么就無法更改數(shù)據(jù)
9.drop、truncate、 delete區(qū)別
最基本：
drop直接刪掉表。
truncate刪除表中數(shù)據(jù)，再插入時自增長id又從1開始。
delete刪除表中數(shù)據(jù)，可以加where字句。
（1） DELETE語句執(zhí)行刪除的過程是每次從表中刪除一行，并且同時將該行的刪除操作作為事務(wù)記錄在日志中保存以便進行進行回滾操作。TRUNCATE TABLE 則一次性地從表中刪除所有的數(shù)據(jù)并不把單獨的刪除操作記錄記入日志保存，刪除行是不能恢復(fù)的。并且在刪除的過程中不會激活與表有關(guān)的刪除觸發(fā)器。執(zhí)行速度快。
（2） 表和索引所占空間。當(dāng)表被TRUNCATE 后，這個表和索引所占用的空間會恢復(fù)到初始大小，而DELETE操作不會減少表或索引所占用的空間。drop語句將表所占用的空間全釋放掉。
（3） 一般而言，drop > truncate > delete
（4） 應(yīng)用范圍。TRUNCATE 只能對TABLE；DELETE可以是table和view
（5） TRUNCATE 和DELETE只刪除數(shù)據(jù)，而DROP則刪除整個表（結(jié)構(gòu)和數(shù)據(jù)）。
（6） truncate與不帶where的delete ：只刪除數(shù)據(jù)，而不刪除表的結(jié)構(gòu)（定義）drop語句將刪除表的結(jié)構(gòu)被依賴的約束（constrain),觸發(fā)器（trigger)索引（index);依賴于該表的存儲過程/函數(shù)將被保留，但其狀態(tài)會變?yōu)椋篿nvalid。
（7） delete語句為DML（data maintain Language),這個操作會被放到 rollback segment中,事務(wù)提交后才生效。如果有相應(yīng)的 tigger,執(zhí)行的時候?qū)⒈挥|發(fā)。
（8） truncate、drop是DLL（data define language),操作立即生效，原數(shù)據(jù)不放到 rollback segment中，不能回滾。
（9） 在沒有備份情況下，謹(jǐn)慎使用 drop 與 truncate。要刪除部分?jǐn)?shù)據(jù)行采用delete且注意結(jié)合where來約束影響范圍?；貪L段要足夠大。要刪除表用drop;若想保留表而將表中數(shù)據(jù)刪除，如果與事務(wù)無關(guān)，用truncate即可實現(xiàn)。如果和事務(wù)有關(guān)，或老師想觸發(fā)trigger,還是用delete。
（10） Truncate table 表名 速度快,而且效率高,因為:?truncate table 在功能上與不帶 WHERE 子句的 DELETE 語句相同：二者均刪除表中的全部行。但 TRUNCATE TABLE 比 DELETE 速度快，且使用的系統(tǒng)和事務(wù)日志資源少。DELETE 語句每次刪除一行，并在事務(wù)日志中為所刪除的每行記錄一項。TRUNCATE TABLE 通過釋放存儲表數(shù)據(jù)所用的數(shù)據(jù)頁來刪除數(shù)據(jù)，并且只在事務(wù)日志中記錄頁的釋放。
（11） TRUNCATE TABLE 刪除表中的所有行，但表結(jié)構(gòu)及其列、約束、索引等保持不變。新行標(biāo)識所用的計數(shù)值重置為該列的種子。如果想保留標(biāo)識計數(shù)值，請改用 DELETE。如果要刪除表定義及其數(shù)據(jù)，請使用 DROP TABLE 語句。
（12） 對于由 FOREIGN KEY 約束引用的表，不能使用 TRUNCATE TABLE，而應(yīng)使用不帶 WHERE 子句的 DELETE 語句。由于 TRUNCATE TABLE 不記錄在日志中，所以它不能激活觸發(fā)器。
10.什么是臨時表，臨時表什么時候刪除?
臨時表可以手動刪除：
DROP?TEMPORARY?TABLE?IF?EXISTS?temp_tb;
臨時表只在當(dāng)前連接可見，當(dāng)關(guān)閉連接時，MySQL會自動刪除表并釋放所有空間。因此在不同的連接中可以創(chuàng)建同名的臨時表，并且操作屬于本連接的臨時表。
創(chuàng)建臨時表的語法與創(chuàng)建表語法類似，不同之處是增加關(guān)鍵字TEMPORARY，
如：
CREATE?TEMPORARY?TABLE?tmp_table?(
NAME?VARCHAR?(10)?NOT?NULL,
time?date?NOT?NULL
);
select?*?from?tmp_table;
11.非關(guān)系型數(shù)據(jù)庫和關(guān)系型數(shù)據(jù)庫區(qū)別，優(yōu)勢比較?
非關(guān)系型數(shù)據(jù)庫的優(yōu)勢：
性能：NOSQL是基于鍵值對的，可以想象成表中的主鍵和值的對應(yīng)關(guān)系，而且不需要經(jīng)過SQL層的解析，所以性能非常高。
可擴展性：同樣也是因為基于鍵值對，數(shù)據(jù)之間沒有耦合性，所以非常容易水平擴展。
關(guān)系型數(shù)據(jù)庫的優(yōu)勢：
復(fù)雜查詢：可以用SQL語句方便的在一個表以及多個表之間做非常復(fù)雜的數(shù)據(jù)查詢。
事務(wù)支持：使得對于安全性能很高的數(shù)據(jù)訪問要求得以實現(xiàn)。
其他：
1.對于這兩類數(shù)據(jù)庫，對方的優(yōu)勢就是自己的弱勢，反之亦然。
2.NOSQL數(shù)據(jù)庫慢慢開始具備SQL數(shù)據(jù)庫的一些復(fù)雜查詢功能，比如MongoDB。
3.對于事務(wù)的支持也可以用一些系統(tǒng)級的原子操作來實現(xiàn)例如樂觀鎖之類的方法來曲線救國，比如Redis set nx。
12.數(shù)據(jù)庫范式，根據(jù)某個場景設(shè)計數(shù)據(jù)表?
第一范式:(確保每列保持原子性)所有字段值都是不可分解的原子值。
第一范式是最基本的范式。如果數(shù)據(jù)庫表中的所有字段值都是不可分解的原子值，就說明該數(shù)據(jù)庫表滿足了第一范式。
第一范式的合理遵循需要根據(jù)系統(tǒng)的實際需求來定。比如某些數(shù)據(jù)庫系統(tǒng)中需要用到“地址”這個屬性，本來直接將“地址”屬性設(shè)計成一個數(shù)據(jù)庫表的字段就行。但是如果系統(tǒng)經(jīng)常會訪問“地址”屬性中的“城市”部分，那么就非要將“地址”這個屬性重新拆分為省份、城市、詳細(xì)地址等多個部分進行存儲，這樣在對地址中某一部分操作的時候?qū)⒎浅７奖?。這樣設(shè)計才算滿足了數(shù)據(jù)庫的第一范式，如下表所示。
上表所示的用戶信息遵循了第一范式的要求，這樣在對用戶使用城市進行分類的時候就非常方便，也提高了數(shù)據(jù)庫的性能。
第二范式:(確保表中的每列都和主鍵相關(guān))在一個數(shù)據(jù)庫表中，一個表中只能保存一種數(shù)據(jù)，不可以把多種數(shù)據(jù)保存在同一張數(shù)據(jù)庫表中。
第二范式在第一范式的基礎(chǔ)之上更進一層。第二范式需要確保數(shù)據(jù)庫表中的每一列都和主鍵相關(guān)，而不能只與主鍵的某一部分相關(guān)（主要針對聯(lián)合主鍵而言）。也就是說在一個數(shù)據(jù)庫表中，一個表中只能保存一種數(shù)據(jù)，不可以把多種數(shù)據(jù)保存在同一張數(shù)據(jù)庫表中。
比如要設(shè)計一個訂單信息表，因為訂單中可能會有多種商品，所以要將訂單編號和商品編號作為數(shù)據(jù)庫表的聯(lián)合主鍵。
第三范式:(確保每列都和主鍵列直接相關(guān),而不是間接相關(guān)) 數(shù)據(jù)表中的每一列數(shù)據(jù)都和主鍵直接相關(guān)，而不能間接相關(guān)。
第三范式需要確保數(shù)據(jù)表中的每一列數(shù)據(jù)都和主鍵直接相關(guān)，而不能間接相關(guān)。
比如在設(shè)計一個訂單數(shù)據(jù)表的時候，可以將客戶編號作為一個外鍵和訂單表建立相應(yīng)的關(guān)系。而不可以在訂單表中添加關(guān)于客戶其它信息（比如姓名、所屬公司等）的字段。
BCNF:符合3NF，并且，主屬性不依賴于主屬性。
若關(guān)系模式屬于第二范式，且每個屬性都不傳遞依賴于鍵碼，則R屬于BC范式。
通常BC范式的條件有多種等價的表述：每個非平凡依賴的左邊必須包含鍵碼；每個決定因素必須包含鍵碼。
BC范式既檢查非主屬性，又檢查主屬性。當(dāng)只檢查非主屬性時，就成了第三范式。滿足BC范式的關(guān)系都必然滿足第三范式。
還可以這么說：若一個關(guān)系達(dá)到了第三范式，并且它只有一個候選碼，或者它的每個候選碼都是單屬性，則該關(guān)系自然達(dá)到BC范式。
一般，一個數(shù)據(jù)庫設(shè)計符合3NF或BCNF就可以了。
第四范式:要求把同一表內(nèi)的多對多關(guān)系刪除。
第五范式:從最終結(jié)構(gòu)重新建立原始結(jié)構(gòu)。
13.什么是 內(nèi)連接、外連接、交叉連接、笛卡爾積等?
內(nèi)連接: 只連接匹配的行
左外連接: 包含左邊表的全部行（不管右邊的表中是否存在與它們匹配的行），以及右邊表中全部匹配的行
右外連接: 包含右邊表的全部行（不管左邊的表中是否存在與它們匹配的行），以及左邊表中全部匹配的行
例如1：
SELECT?a.,b.?FROM?luntan?LEFT?JOIN?usertable?as?b?ON?a.username=b.username
例如2：
SELECT?a.,b.?FROM?city?as?a?FULL?OUTER?JOIN?user?as?b?ON?a.username=b.username全外連接: 包含左、右兩個表的全部行，不管另外一邊的表中是否存在與它們匹配的行。
交叉連接: 生成笛卡爾積－它不使用任何匹配或者選取條件，而是直接將一個數(shù)據(jù)源中的每個行與另一個數(shù)據(jù)源的每個行都一一匹配
例如：
SELECT?type,pub_name?FROM?titles?CROSS?JOIN?publishers?ORDER?BY?type注意：
很多公司都只是考察是否知道其概念，但是也有很多公司需要不僅僅知道概念，還需要動手寫sql,一般都是簡單的連接查詢，具體關(guān)于連接查詢的sql練習(xí)，參見以下鏈接：
https://www.nowcoder.com/ta/sql
https://leetcode-cn.com/problemset/database/
14.varchar和char的使用場景?
1.char的長度是不可變的，而varchar的長度是可變的。
定義一個char[10]和varchar[10]。
如果存進去的是‘csdn’,那么char所占的長度依然為10，除了字符‘csdn’外，后面跟六個空格，varchar就立馬把長度變?yōu)?了，取數(shù)據(jù)的時候，char類型的要用trim()去掉多余的空格，而varchar是不需要的。
2.char的存取速度還是要比varchar要快得多，因為其長度固定，方便程序的存儲與查找。
char也為此付出的是空間的代價，因為其長度固定，所以難免會有多余的空格占位符占據(jù)空間，可謂是以空間換取時間效率。
varchar是以空間效率為首位。
3.char的存儲方式是：對英文字符（ASCII）占用1個字節(jié)，對一個漢字占用兩個字節(jié)。
varchar的存儲方式是：對每個英文字符占用2個字節(jié)，漢字也占用2個字節(jié)。
4.兩者的存儲數(shù)據(jù)都非unicode的字符數(shù)據(jù)。
15.SQL語言分類
SQL語言共分為四大類：
數(shù)據(jù)查詢語言DQL
數(shù)據(jù)操縱語言DML
數(shù)據(jù)定義語言DDL
數(shù)據(jù)控制語言DCL。
1. 數(shù)據(jù)查詢語言DQL
數(shù)據(jù)查詢語言DQL基本結(jié)構(gòu)是由SELECT子句，F(xiàn)ROM子句，WHERE子句組成的查詢塊：
SELECT
FROM
WHERE
2 .數(shù)據(jù)操縱語言DML
數(shù)據(jù)操縱語言DML主要有三種形式：
1) 插入：INSERT
2) 更新：UPDATE
3) 刪除：DELETE
3. 數(shù)據(jù)定義語言DDL
數(shù)據(jù)定義語言DDL用來創(chuàng)建數(shù)據(jù)庫中的各種對象-----表、視圖、索引、同義詞、聚簇等如：
CREATE TABLE/VIEW/INDEX/SYN/CLUSTER
表 視圖 索引 同義詞 簇
DDL操作是隱性提交的！不能rollback
4. 數(shù)據(jù)控制語言DCL
數(shù)據(jù)控制語言DCL用來授予或回收訪問數(shù)據(jù)庫的某種特權(quán)，并控制數(shù)據(jù)庫操縱事務(wù)發(fā)生的時間及效果，對數(shù)據(jù)庫實行監(jiān)視等。如：
1) GRANT：授權(quán)。
2) ROLLBACK [WORK] TO [SAVEPOINT]：回退到某一點?；貪L---ROLLBACK；回滾命令使數(shù)據(jù)庫狀態(tài)回到上次最后提交的狀態(tài)。其格式為：
SQL>ROLLBACK;
3) COMMIT [WORK]：提交。
在數(shù)據(jù)庫的插入、刪除和修改操作時，只有當(dāng)事務(wù)在提交到數(shù)據(jù)庫時才算完成。在事務(wù)提交前，只有操作數(shù)據(jù)庫的這個人才能有權(quán)看到所做的事情，別人只有在最后提交完成后才可以看到。
提交數(shù)據(jù)有三種類型：顯式提交、隱式提交及自動提交。下面分別說明這三種類型。
(1) 顯式提交
用COMMIT命令直接完成的提交為顯式提交。其格式為：SQL>COMMIT；
(2) 隱式提交
用SQL命令間接完成的提交為隱式提交。這些命令是：
ALTER，AUDIT，COMMENT，CONNECT，CREATE，DISCONNECT，DROP，
EXIT，GRANT，NOAUDIT，QUIT，REVOKE，RENAME。
(3) 自動提交
若把AUTOCOMMIT設(shè)置為ON，則在插入、修改、刪除語句執(zhí)行后，
系統(tǒng)將自動進行提交，這就是自動提交。
其格式為：SQL>SET AUTOCOMMIT ON；
參考文章：
https://www.cnblogs.com/study-s/p/5287529.html
16.like %和-的區(qū)別
通配符的分類
%百分號通配符:表示任何字符出現(xiàn)任意次數(shù)(可以是0次).
_下劃線通配符:表示只能匹配單個字符,不能多也不能少,就是一個字符.
like操作符: LIKE作用是指示mysql后面的搜索模式是利用通配符而不是直接相等匹配進行比較.
注意: 如果在使用like操作符時,后面的沒有使用通用匹配符效果是和=一致的,SELECT * FROM products WHERE products.prod_name like '1000';只能匹配的結(jié)果為1000,而不能匹配像JetPack 1000這樣的結(jié)果.
%通配符使用: 匹配以"yves"開頭的記錄:(包括記錄"yves") SELECT FROM products WHERE products.prod_name like 'yves%';
匹配包含"yves"的記錄(包括記錄"yves") SELECT FROM products WHERE products.prod_name like '%yves%';
匹配以"yves"結(jié)尾的記錄(包括記錄"yves",不包括記錄"yves ",也就是yves后面有空格的記錄,這里需要注意) SELECT * FROM products WHERE products.prod_name like '%yves';
通配符使用: SELECT?FROM products WHERE products.prod_name like '_yves'; 匹配結(jié)果為: 像"yyves"這樣記錄. SELECT?FROM products WHERE products.prodname like 'yves'; 匹配結(jié)果為: 像"yvesHe"這樣的記錄.(一個下劃線只能匹配一個字符,不能多也不能少)
注意事項:
注意大小寫,在使用模糊匹配時,也就是匹配文本時,mysql是可能區(qū)分大小的,也可能是不區(qū)分大小寫的,這個結(jié)果是取決于用戶對MySQL的配置方式.如果是區(qū)分大小寫,那么像YvesHe這樣記錄是不能被"yves__"這樣的匹配條件匹配的.
注意尾部空格,"%yves"是不能匹配"heyves "這樣的記錄的.
注意NULL,%通配符可以匹配任意字符,但是不能匹配NULL,也就是說SELECT * FROM products WHERE products.prod_name like '%;是匹配不到products.prod_name為NULL的的記錄.
技巧與建議:
正如所見， MySQL的通配符很有用。但這種功能是有代價的：通配符搜索的處理一般要比前面討論的其他搜索所花時間更長。這里給出一些使用通配符要記住的技巧。
不要過度使用通配符。如果其他操作符能達(dá)到相同的目的，應(yīng)該 使用其他操作符。
在確實需要使用通配符時，除非絕對有必要，否則不要把它們用 在搜索模式的開始處。把通配符置于搜索模式的開始處，搜索起 來是最慢的。
仔細(xì)注意通配符的位置。如果放錯地方，可能不會返回想要的數(shù).
參考博文：
https://blog.csdn.net/u011479200/article/details/78513632
17.count(*)、count(1)、count(column)的區(qū)別
count(*)對行的數(shù)目進行計算,包含NULL
count(column)對特定的列的值具有的行數(shù)進行計算,不包含NULL值。
count()還有一種使用方式,count(1)這個用法和count(*)的結(jié)果是一樣的。
性能問題:
1.任何情況下SELECT COUNT(*) FROM tablename是最優(yōu)選擇;
2.盡量減少SELECT COUNT(*) FROM tablename WHERE COL = ‘value’ 這種查詢;
3.杜絕SELECT COUNT(COL) FROM tablename WHERE COL2 = ‘value’ 的出現(xiàn)。
如果表沒有主鍵,那么count(1)比count(*)快。
如果有主鍵,那么count(主鍵,聯(lián)合主鍵)比count(*)快。
如果表只有一個字段,count(*)最快。
count(1)跟count(主鍵)一樣,只掃描主鍵。count(*)跟count(非主鍵)一樣,掃描整個表。明顯前者更快一些。
18.最左前綴原則
多列索引：
ALTER?TABLE?people?ADD?INDEX?lname_fname_age?(lame,fname,age);為了提高搜索效率，我們需要考慮運用多列索引,由于索引文件以B－Tree格式保存，所以我們不用掃描任何記錄，即可得到最終結(jié)果。
注：在mysql中執(zhí)行查詢時，只能使用一個索引，如果我們在lname,fname,age上分別建索引,執(zhí)行查詢時，只能使用一個索引，mysql會選擇一個最嚴(yán)格(獲得結(jié)果集記錄數(shù)最少)的索引。
最左前綴原則：顧名思義，就是最左優(yōu)先，上例中我們創(chuàng)建了lname_fname_age多列索引,相當(dāng)于創(chuàng)建了(lname)單列索引，(lname,fname)組合索引以及(lname,fname,age)組合索引。
二、索引
1.什么是索引？
何為索引：
數(shù)據(jù)庫索引，是數(shù)據(jù)庫管理系統(tǒng)中一個排序的數(shù)據(jù)結(jié)構(gòu)，索引的實現(xiàn)通常使用B樹及其變種B+樹。
在數(shù)據(jù)之外，數(shù)據(jù)庫系統(tǒng)還維護著滿足特定查找算法的數(shù)據(jù)結(jié)構(gòu)，這些數(shù)據(jù)結(jié)構(gòu)以某種方式引用（指向）數(shù)據(jù)，這樣就可以在這些數(shù)據(jù)結(jié)構(gòu)上實現(xiàn)高級查找算法。這種數(shù)據(jù)結(jié)構(gòu)，就是索引。
2.索引的作用？它的優(yōu)點缺點是什么？
索引作用：
協(xié)助快速查詢、更新數(shù)據(jù)庫表中數(shù)據(jù)。
為表設(shè)置索引要付出代價的：
一是增加了數(shù)據(jù)庫的存儲空間
二是在插入和修改數(shù)據(jù)時要花費較多的時間(因為索引也要隨之變動)。
3.索引的優(yōu)缺點？
創(chuàng)建索引可以大大提高系統(tǒng)的性能（優(yōu)點）：
1.通過創(chuàng)建唯一性索引，可以保證數(shù)據(jù)庫表中每一行數(shù)據(jù)的唯一性。
2.可以大大加快數(shù)據(jù)的檢索速度，這也是創(chuàng)建索引的最主要的原因。
3.可以加速表和表之間的連接，特別是在實現(xiàn)數(shù)據(jù)的參考完整性方面特別有意義。
4.在使用分組和排序子句進行數(shù)據(jù)檢索時，同樣可以顯著減少查詢中分組和排序的時間。
5.通過使用索引，可以在查詢的過程中，使用優(yōu)化隱藏器，提高系統(tǒng)的性能。
增加索引也有許多不利的方面(缺點)：
1.創(chuàng)建索引和維護索引要耗費時間，這種時間隨著數(shù)據(jù)量的增加而增加。
2.索引需要占物理空間，除了數(shù)據(jù)表占數(shù)據(jù)空間之外，每一個索引還要占一定的物理空間，如果要建立聚簇索引，那么需要的空間就會更大。
3.當(dāng)對表中的數(shù)據(jù)進行增加、刪除和修改的時候，索引也要動態(tài)的維護，這樣就降低了數(shù)據(jù)的維護速度。
4.哪些列適合建立索引、哪些不適合建索引？
索引是建立在數(shù)據(jù)庫表中的某些列的上面。在創(chuàng)建索引的時候，應(yīng)該考慮在哪些列上可以創(chuàng)建索引，在哪些列上不能創(chuàng)建索引。
一般來說，應(yīng)該在這些列上創(chuàng)建索引：
（1）在經(jīng)常需要搜索的列上，可以加快搜索的速度；
（2）在作為主鍵的列上，強制該列的唯一性和組織表中數(shù)據(jù)的排列結(jié)構(gòu)；
（3）在經(jīng)常用在連接的列上，這些列主要是一些外鍵，可以加快連接的速度；
（4）在經(jīng)常需要根據(jù)范圍進行搜索的列上創(chuàng)建索引，因為索引已經(jīng)排序，其指定的范圍是連續(xù)的；
（5）在經(jīng)常需要排序的列上創(chuàng)建索引，因為索引已經(jīng)排序，這樣查詢可以利用索引的排序，加快排序查詢時間；
（6）在經(jīng)常使用在WHERE子句中的列上面創(chuàng)建索引，加快條件的判斷速度。
對于有些列不應(yīng)該創(chuàng)建索引：
（1）對于那些在查詢中很少使用或者參考的列不應(yīng)該創(chuàng)建索引。
這是因為，既然這些列很少使用到，因此有索引或者無索引，并不能提高查詢速度。相反，由于增加了索引，反而降低了系統(tǒng)的維護速度和增大了空間需求。
（2）對于那些只有很少數(shù)據(jù)值的列也不應(yīng)該增加索引。
這是因為，由于這些列的取值很少，例如人事表的性別列，在查詢的結(jié)果中，結(jié)果集的數(shù)據(jù)行占了表中數(shù)據(jù)行的很大比例，即需要在表中搜索的數(shù)據(jù)行的比例很大。增加索引，并不能明顯加快檢索速度。
（3）對于那些定義為text, image和bit數(shù)據(jù)類型的列不應(yīng)該增加索引。
這是因為，這些列的數(shù)據(jù)量要么相當(dāng)大，要么取值很少。
(4)當(dāng)修改性能遠(yuǎn)遠(yuǎn)大于檢索性能時，不應(yīng)該創(chuàng)建索引。
這是因為，修改性能和檢索性能是互相矛盾的。當(dāng)增加索引時，會提高檢索性能，但是會降低修改性能。當(dāng)減少索引時，會提高修改性能，降低檢索性能。因此，當(dāng)修改性能遠(yuǎn)遠(yuǎn)大于檢索性能時，不應(yīng)該創(chuàng)建索引。
5.什么樣的字段適合建索引
唯一、不為空、經(jīng)常被查詢的字段
6.MySQL B+Tree索引和Hash索引的區(qū)別?
Hash索引和B+樹索引的特點：
Hash索引結(jié)構(gòu)的特殊性，其檢索效率非常高，索引的檢索可以一次定位;
B+樹索引需要從根節(jié)點到枝節(jié)點，最后才能訪問到頁節(jié)點這樣多次的IO訪問;
為什么不都用Hash索引而使用B+樹索引？
Hash索引僅僅能滿足"=","IN"和""查詢，不能使用范圍查詢,因為經(jīng)過相應(yīng)的Hash算法處理之后的Hash值的大小關(guān)系，并不能保證和Hash運算前完全一樣；
Hash索引無法被用來避免數(shù)據(jù)的排序操作，因為Hash值的大小關(guān)系并不一定和Hash運算前的鍵值完全一樣；
Hash索引不能利用部分索引鍵查詢，對于組合索引，Hash索引在計算Hash值的時候是組合索引鍵合并后再一起計算Hash值，而不是單獨計算Hash值，所以通過組合索引的前面一個或幾個索引鍵進行查詢的時候，Hash索引也無法被利用；
Hash索引在任何時候都不能避免表掃描，由于不同索引鍵存在相同Hash值，所以即使取滿足某個Hash鍵值的數(shù)據(jù)的記錄條數(shù)，也無法從Hash索引中直接完成查詢，還是要回表查詢數(shù)據(jù)；
Hash索引遇到大量Hash值相等的情況后性能并不一定就會比B+樹索引高。
補充：
1.MySQL中，只有HEAP/MEMORY引擎才顯示支持Hash索引。
2.常用的InnoDB引擎中默認(rèn)使用的是B+樹索引，它會實時監(jiān)控表上索引的使用情況，如果認(rèn)為建立哈希索引可以提高查詢效率，則自動在內(nèi)存中的“自適應(yīng)哈希索引緩沖區(qū)”建立哈希索引（在InnoDB中默認(rèn)開啟自適應(yīng)哈希索引），通過觀察搜索模式，MySQL會利用index key的前綴建立哈希索引，如果一個表幾乎大部分都在緩沖池中，那么建立一個哈希索引能夠加快等值查詢。
B+樹索引和哈希索引的明顯區(qū)別是：
3.如果是等值查詢，那么哈希索引明顯有絕對優(yōu)勢，因為只需要經(jīng)過一次算法即可找到相應(yīng)的鍵值；當(dāng)然了，這個前提是，鍵值都是唯一的。如果鍵值不是唯一的，就需要先找到該鍵所在位置，然后再根據(jù)鏈表往后掃描，直到找到相應(yīng)的數(shù)據(jù)；
4.如果是范圍查詢檢索，這時候哈希索引就毫無用武之地了，因為原先是有序的鍵值，經(jīng)過哈希算法后，有可能變成不連續(xù)的了，就沒辦法再利用索引完成范圍查詢檢索；
同理，哈希索引沒辦法利用索引完成排序，以及l(fā)ike ‘xxx%’ 這樣的部分模糊查詢（這種部分模糊查詢，其實本質(zhì)上也是范圍查詢）；
5.哈希索引也不支持多列聯(lián)合索引的最左匹配規(guī)則；
6.B+樹索引的關(guān)鍵字檢索效率比較平均，不像B樹那樣波動幅度大，在有大量重復(fù)鍵值情況下，哈希索引的效率也是極低的，因為存在所謂的哈希碰撞問題。
7.在大多數(shù)場景下，都會有范圍查詢、排序、分組等查詢特征，用B+樹索引就可以了。
7.B樹和B+樹的區(qū)別
B樹，每個節(jié)點都存儲key和data，所有節(jié)點組成這棵樹，并且葉子節(jié)點指針為nul，葉子結(jié)點不包含任何關(guān)鍵字信息。
B+樹，所有的葉子結(jié)點中包含了全部關(guān)鍵字的信息，及指向含有這些關(guān)鍵字記錄的指針，且葉子結(jié)點本身依關(guān)鍵字的大小自小而大的順序鏈接，所有的非終端結(jié)點可以看成是索引部分，結(jié)點中僅含有其子樹根結(jié)點中最大（或最?。╆P(guān)鍵字。(而B 樹的非終節(jié)點也包含需要查找的有效信息)
8.為什么說B+比B樹更適合實際應(yīng)用中操作系統(tǒng)的文件索引和數(shù)據(jù)庫索引？
1.B+的磁盤讀寫代價更低
B+的內(nèi)部結(jié)點并沒有指向關(guān)鍵字具體信息的指針。因此其內(nèi)部結(jié)點相對B樹更小。如果把所有同一內(nèi)部結(jié)點的關(guān)鍵字存放在同一盤塊中，那么盤塊所能容納的關(guān)鍵字?jǐn)?shù)量也越多。一次性讀入內(nèi)存中的需要查找的關(guān)鍵字也就越多。相對來說IO讀寫次數(shù)也就降低了。
2.B+tree的查詢效率更加穩(wěn)定
由于非終結(jié)點并不是最終指向文件內(nèi)容的結(jié)點，而只是葉子結(jié)點中關(guān)鍵字的索引。所以任何關(guān)鍵字的查找必須走一條從根結(jié)點到葉子結(jié)點的路。所有關(guān)鍵字查詢的路徑長度相同，導(dǎo)致每一個數(shù)據(jù)的查詢效率相當(dāng)。
9.聚集索引和非聚集索引區(qū)別?
聚合索引(clustered index):
聚集索引表記錄的排列順序和索引的排列順序一致，所以查詢效率快，只要找到第一個索引值記錄，其余就連續(xù)性的記錄在物理也一樣連續(xù)存放。聚集索引對應(yīng)的缺點就是修改慢，因為為了保證表中記錄的物理和索引順序一致，在記錄插入的時候，會對數(shù)據(jù)頁重新排序。
聚集索引類似于新華字典中用拼音去查找漢字，拼音檢索表于書記順序都是按照a~z排列的，就像相同的邏輯順序于物理順序一樣，當(dāng)你需要查找a,ai兩個讀音的字，或是想一次尋找多個傻(sha)的同音字時，也許向后翻幾頁，或緊接著下一行就得到結(jié)果了。
非聚合索引(nonclustered index):
非聚集索引指定了表中記錄的邏輯順序，但是記錄的物理和索引不一定一致，兩種索引都采用B+樹結(jié)構(gòu)，非聚集索引的葉子層并不和實際數(shù)據(jù)頁相重疊，而采用葉子層包含一個指向表中的記錄在數(shù)據(jù)頁中的指針方式。非聚集索引層次多，不會造成數(shù)據(jù)重排。
非聚集索引類似在新華字典上通過偏旁部首來查詢漢字，檢索表也許是按照橫、豎、撇來排列的，但是由于正文中是a~z的拼音順序，所以就類似于邏輯地址于物理地址的不對應(yīng)。同時適用的情況就在于分組，大數(shù)目的不同值，頻繁更新的列中，這些情況即不適合聚集索引。
根本區(qū)別：
聚集索引和非聚集索引的根本區(qū)別是表記錄的排列順序和與索引的排列順序是否一致。
三、事務(wù)
1.什么是事務(wù)？
事務(wù)是對數(shù)據(jù)庫中一系列操作進行統(tǒng)一的回滾或者提交的操作，主要用來保證數(shù)據(jù)的完整性和一致性。
2.事務(wù)四大特性（ACID）原子性、一致性、隔離性、持久性?
原子性（Atomicity）:
原子性是指事務(wù)包含的所有操作要么全部成功，要么全部失敗回滾，因此事務(wù)的操作如果成功就必須要完全應(yīng)用到數(shù)據(jù)庫，如果操作失敗則不能對數(shù)據(jù)庫有任何影響。
一致性（Consistency）:
事務(wù)開始前和結(jié)束后，數(shù)據(jù)庫的完整性約束沒有被破壞。比如A向B轉(zhuǎn)賬，不可能A扣了錢，B卻沒收到。
隔離性（Isolation）:
隔離性是當(dāng)多個用戶并發(fā)訪問數(shù)據(jù)庫時，比如操作同一張表時，數(shù)據(jù)庫為每一個用戶開啟的事務(wù)，不能被其他事務(wù)的操作所干擾，多個并發(fā)事務(wù)之間要相互隔離。同一時間，只允許一個事務(wù)請求同一數(shù)據(jù)，不同的事務(wù)之間彼此沒有任何干擾。比如A正在從一張銀行卡中取錢，在A取錢的過程結(jié)束前，B不能向這張卡轉(zhuǎn)賬。
持久性（Durability）:
持久性是指一個事務(wù)一旦被提交了，那么對數(shù)據(jù)庫中的數(shù)據(jù)的改變就是永久性的，即便是在數(shù)據(jù)庫系統(tǒng)遇到故障的情況下也不會丟失提交事務(wù)的操作。
3.事務(wù)的并發(fā)?事務(wù)隔離級別，每個級別會引發(fā)什么問題，MySQL默認(rèn)是哪個級別?
從理論上來說, 事務(wù)應(yīng)該彼此完全隔離, 以避免并發(fā)事務(wù)所導(dǎo)致的問題，然而, 那樣會對性能產(chǎn)生極大的影響, 因為事務(wù)必須按順序運行， 在實際開發(fā)中, 為了提升性能, 事務(wù)會以較低的隔離級別運行， 事務(wù)的隔離級別可以通過隔離事務(wù)屬性指定。
事務(wù)的并發(fā)問題
1、臟讀：事務(wù)A讀取了事務(wù)B更新的數(shù)據(jù)，然后B回滾操作，那么A讀取到的數(shù)據(jù)是臟數(shù)據(jù)
2、不可重復(fù)讀：事務(wù) A 多次讀取同一數(shù)據(jù)，事務(wù) B 在事務(wù)A多次讀取的過程中，對數(shù)據(jù)作了更新并提交，導(dǎo)致事務(wù)A多次讀取同一數(shù)據(jù)時，結(jié)果因此本事務(wù)先后兩次讀到的數(shù)據(jù)結(jié)果會不一致。
3、幻讀：幻讀解決了不重復(fù)讀，保證了同一個事務(wù)里，查詢的結(jié)果都是事務(wù)開始時的狀態(tài)（一致性）。
例如：事務(wù)T1對一個表中所有的行的某個數(shù)據(jù)項做了從“1”修改為“2”的操作 這時事務(wù)T2又對這個表中插入了一行數(shù)據(jù)項，而這個數(shù)據(jù)項的數(shù)值還是為“1”并且提交給數(shù)據(jù)庫。而操作事務(wù)T1的用戶如果再查看剛剛修改的數(shù)據(jù)，會發(fā)現(xiàn)還有跟沒有修改一樣，其實這行是從事務(wù)T2中添加的，就好像產(chǎn)生幻覺一樣，這就是發(fā)生了幻讀。
小結(jié)：不可重復(fù)讀的和幻讀很容易混淆，不可重復(fù)讀側(cè)重于修改，幻讀側(cè)重于新增或刪除。解決不可重復(fù)讀的問題只需鎖住滿足條件的行，解決幻讀需要鎖表。
事務(wù)的隔離級別
讀未提交：另一個事務(wù)修改了數(shù)據(jù)，但尚未提交，而本事務(wù)中的SELECT會讀到這些未被提交的數(shù)據(jù)臟讀
不可重復(fù)讀：事務(wù) A 多次讀取同一數(shù)據(jù)，事務(wù) B 在事務(wù)A多次讀取的過程中，對數(shù)據(jù)作了更新并提交，導(dǎo)致事務(wù)A多次讀取同一數(shù)據(jù)時，結(jié)果因此本事務(wù)先后兩次讀到的數(shù)據(jù)結(jié)果會不一致。
可重復(fù)讀：在同一個事務(wù)里，SELECT的結(jié)果是事務(wù)開始時時間點的狀態(tài)，因此，同樣的SELECT操作讀到的結(jié)果會是一致的。但是，會有幻讀現(xiàn)象
串行化：最高的隔離級別，在這個隔離級別下，不會產(chǎn)生任何異常。并發(fā)的事務(wù)，就像事務(wù)是在一個個按照順序執(zhí)行一樣
特別注意：
MySQL默認(rèn)的事務(wù)隔離級別為repeatable-read
MySQL 支持 4 種事務(wù)隔離級別.
事務(wù)的隔離級別要得到底層數(shù)據(jù)庫引擎的支持, 而不是應(yīng)用程序或者框架的支持.
Oracle 支持的 2 種事務(wù)隔離級別：READ_COMMITED , SERIALIZABLE
SQL規(guī)范所規(guī)定的標(biāo)準(zhǔn)，不同的數(shù)據(jù)庫具體的實現(xiàn)可能會有些差異
MySQL中默認(rèn)事務(wù)隔離級別是“可重復(fù)讀”時并不會鎖住讀取到的行
事務(wù)隔離級別：未提交讀時，寫數(shù)據(jù)只會鎖住相應(yīng)的行。
事務(wù)隔離級別為：可重復(fù)讀時，寫數(shù)據(jù)會鎖住整張表。
事務(wù)隔離級別為：串行化時，讀寫數(shù)據(jù)都會鎖住整張表。
隔離級別越高，越能保證數(shù)據(jù)的完整性和一致性，但是對并發(fā)性能的影響也越大，魚和熊掌不可兼得啊。對于多數(shù)應(yīng)用程序，可以優(yōu)先考慮把數(shù)據(jù)庫系統(tǒng)的隔離級別設(shè)為Read Committed，它能夠避免臟讀取，而且具有較好的并發(fā)性能。盡管它會導(dǎo)致不可重復(fù)讀、幻讀這些并發(fā)問題，在可能出現(xiàn)這類問題的個別場合，可以由應(yīng)用程序采用悲觀鎖或樂觀鎖來控制。
4.事務(wù)傳播行為
1.PROPAGATION_REQUIRED：如果當(dāng)前沒有事務(wù)，就創(chuàng)建一個新事務(wù)，如果當(dāng)前存在事務(wù)，就加入該事務(wù)，該設(shè)置是最常用的設(shè)置。
2.PROPAGATION_SUPPORTS：支持當(dāng)前事務(wù)，如果當(dāng)前存在事務(wù)，就加入該事務(wù)，如果當(dāng)前不存在事務(wù)，就以非事務(wù)執(zhí)行。
3.PROPAGATION_MANDATORY：支持當(dāng)前事務(wù)，如果當(dāng)前存在事務(wù)，就加入該事務(wù)，如果當(dāng)前不存在事務(wù)，就拋出異常。
4.PROPAGATION_REQUIRES_NEW：創(chuàng)建新事務(wù)，無論當(dāng)前存不存在事務(wù)，都創(chuàng)建新事務(wù)。
5.PROPAGATION_NOT_SUPPORTED：以非事務(wù)方式執(zhí)行操作，如果當(dāng)前存在事務(wù)，就把當(dāng)前事務(wù)掛起。
6.PROPAGATION_NEVER：以非事務(wù)方式執(zhí)行，如果當(dāng)前存在事務(wù)，則拋出異常。
7.PROPAGATION_NESTED：如果當(dāng)前存在事務(wù)，則在嵌套事務(wù)內(nèi)執(zhí)行。如果當(dāng)前沒有事務(wù)，則執(zhí)行與PROPAGATION_REQUIRED類似的操作。
5.嵌套事務(wù)
什么是嵌套事務(wù)？
嵌套是子事務(wù)套在父事務(wù)中執(zhí)行，子事務(wù)是父事務(wù)的一部分，在進入子事務(wù)之前，父事務(wù)建立一個回滾點，叫save point，然后執(zhí)行子事務(wù)，這個子事務(wù)的執(zhí)行也算是父事務(wù)的一部分，然后子事務(wù)執(zhí)行結(jié)束，父事務(wù)繼續(xù)執(zhí)行。重點就在于那個save point?？磶讉€問題就明了了：
如果子事務(wù)回滾，會發(fā)生什么？
父事務(wù)會回滾到進入子事務(wù)前建立的save point，然后嘗試其他的事務(wù)或者其他的業(yè)務(wù)邏輯，父事務(wù)之前的操作不會受到影響，更不會自動回滾。
如果父事務(wù)回滾，會發(fā)生什么？
父事務(wù)回滾，子事務(wù)也會跟著回滾！為什么呢，因為父事務(wù)結(jié)束之前，子事務(wù)是不會提交的，我們說子事務(wù)是父事務(wù)的一部分，正是這個道理。那么：
事務(wù)的提交，是什么情況？
是父事務(wù)先提交，然后子事務(wù)提交，還是子事務(wù)先提交，父事務(wù)再提交？答案是第二種情況，還是那句話，子事務(wù)是父事務(wù)的一部分，由父事務(wù)統(tǒng)一提交。
參考文章：
https://blog.csdn.net/liangxw1/article/details/51197560
四、存儲引擎
1.MySQL常見的三種存儲引擎（InnoDB、MyISAM、MEMORY）的區(qū)別?
兩種存儲引擎的大致區(qū)別表現(xiàn)在：
1.InnoDB支持事務(wù)，MyISAM不支持， 這一點是非常之重要。事務(wù)是一種高級的處理方式，如在一些列增刪改中只要哪個出錯還可以回滾還原，而MyISAM就不可以了。
2.MyISAM適合查詢以及插入為主的應(yīng)用。
3.InnoDB適合頻繁修改以及涉及到安全性較高的應(yīng)用。
4.InnoDB支持外鍵，MyISAM不支持。
5.從MySQL5.5.5以后，InnoDB是默認(rèn)引擎。
6.InnoDB不支持FULLTEXT類型的索引。
7.InnoDB中不保存表的行數(shù)，如select count() from table時，InnoDB需要掃描一遍整個表來計算有多少行，但是MyISAM只要簡單的讀出保存好的行數(shù)即可。注意的是，當(dāng)count()語句包含where條件時MyISAM也需要掃描整個表。
8.對于自增長的字段，InnoDB中必須包含只有該字段的索引，但是在MyISAM表中可以和其他字段一起建立聯(lián)合索引。
9.DELETE FROM table時，InnoDB不會重新建立表，而是一行一行的 刪除，效率非常慢。MyISAM則會重建表。
10.InnoDB支持行鎖（某些情況下還是鎖整表，如 update table set a=1 where user like '%lee%'。
2.MySQL存儲引擎MyISAM與InnoDB如何選擇
MySQL有多種存儲引擎，每種存儲引擎有各自的優(yōu)缺點，可以擇優(yōu)選擇使用：MyISAM、InnoDB、MERGE、MEMORY(HEAP)、BDB(BerkeleyDB)、EXAMPLE、FEDERATED、ARCHIVE、CSV、BLACKHOLE。
雖然MySQL里的存儲引擎不只是MyISAM與InnoDB這兩個，但常用的就是兩個。
關(guān)于MySQL數(shù)據(jù)庫提供的兩種存儲引擎，MyISAM與InnoDB選擇使用：
INNODB會支持一些關(guān)系數(shù)據(jù)庫的高級功能，如事務(wù)功能和行級鎖，MyISAM不支持。
MyISAM的性能更優(yōu)，占用的存儲空間少，所以，選擇何種存儲引擎，視具體應(yīng)用而定。
如果你的應(yīng)用程序一定要使用事務(wù)，毫無疑問你要選擇INNODB引擎。但要注意，INNODB的行級鎖是有條件的。在where條件沒有使用主鍵時，照樣會鎖全表。比如DELETE FROM mytable這樣的刪除語句。
如果你的應(yīng)用程序?qū)Σ樵冃阅芤筝^高，就要使用MyISAM了。MyISAM索引和數(shù)據(jù)是分開的，而且其索引是壓縮的，可以更好地利用內(nèi)存。所以它的查詢性能明顯優(yōu)于INNODB。壓縮后的索引也能節(jié)約一些磁盤空間。MyISAM擁有全文索引的功能，這可以極大地優(yōu)化LIKE查詢的效率。
有人說MyISAM只能用于小型應(yīng)用，其實這只是一種偏見。如果數(shù)據(jù)量比較大，這是需要通過升級架構(gòu)來解決，比如分表分庫，而不是單純地依賴存儲引擎。
現(xiàn)在一般都是選用innodb了，主要是MyISAM的全表鎖，讀寫串行問題，并發(fā)效率鎖表，效率低，MyISAM對于讀寫密集型應(yīng)用一般是不會去選用的。
MEMORY存儲引擎
MEMORY是MySQL中一類特殊的存儲引擎。它使用存儲在內(nèi)存中的內(nèi)容來創(chuàng)建表，而且數(shù)據(jù)全部放在內(nèi)存中。這些特性與前面的兩個很不同。
每個基于MEMORY存儲引擎的表實際對應(yīng)一個磁盤文件。該文件的文件名與表名相同，類型為frm類型。該文件中只存儲表的結(jié)構(gòu)。而其數(shù)據(jù)文件，都是存儲在內(nèi)存中，這樣有利于數(shù)據(jù)的快速處理，提高整個表的效率。
值得注意的是，服務(wù)器需要有足夠的內(nèi)存來維持MEMORY存儲引擎的表的使用。如果不需要了，可以釋放內(nèi)存，甚至刪除不需要的表。
MEMORY默認(rèn)使用哈希索引。速度比使用B型樹索引快。當(dāng)然如果你想用B型樹索引，可以在創(chuàng)建索引時指定。
注意，MEMORY用到的很少，因為它是把數(shù)據(jù)存到內(nèi)存中，如果內(nèi)存出現(xiàn)異常就會影響數(shù)據(jù)。如果重啟或者關(guān)機，所有數(shù)據(jù)都會消失。因此，基于MEMORY的表的生命周期很短，一般是一次性的。
3.MySQL的MyISAM與InnoDB兩種存儲引擎在，事務(wù)、鎖級別，各自的適用場景?
事務(wù)處理上方面
MyISAM：強調(diào)的是性能，每次查詢具有原子性,其執(zhí)行數(shù)度比InnoDB類型更快，但是不提供事務(wù)支持。
InnoDB：提供事務(wù)支持事務(wù)，外部鍵等高級數(shù)據(jù)庫功能。具有事務(wù)(commit)、回滾(rollback)和崩潰修復(fù)能力(crash recovery capabilities)的事務(wù)安全(transaction-safe (ACID compliant))型表。
鎖級別
MyISAM：只支持表級鎖，用戶在操作MyISAM表時，select，update，delete，insert語句都會給表自動加鎖，如果加鎖以后的表滿足insert并發(fā)的情況下，可以在表的尾部插入新的數(shù)據(jù)。
InnoDB：支持事務(wù)和行級鎖，是innodb的最大特色。行鎖大幅度提高了多用戶并發(fā)操作的新能。但是InnoDB的行鎖，只是在WHERE的主鍵是有效的，非主鍵的WHERE都會鎖全表的。
關(guān)于存儲引擎MyISAM和InnoDB的其他參考資料如下：
http://blog.csdn.net/lc0817/article/details/52757194
https://www.cnblogs.com/kevingrace/p/5685355.html
五、優(yōu)化
1.查詢語句不同元素（where、jion、limit、group by、having等等）執(zhí)行先后順序?
1.查詢中用到的關(guān)鍵詞主要包含六個，并且他們的順序依次為 select--from--where--group by--having--order by
其中select和from是必須的，其他關(guān)鍵詞是可選的，這六個關(guān)鍵詞的執(zhí)行順序 與sql語句的書寫順序并不是一樣的，而是按照下面的順序來執(zhí)行
from:需要從哪個數(shù)據(jù)表檢索數(shù)據(jù)
where:過濾表中數(shù)據(jù)的條件
group by:如何將上面過濾出的數(shù)據(jù)分組
having:對上面已經(jīng)分組的數(shù)據(jù)進行過濾的條件
select:查看結(jié)果集中的哪個列，或列的計算結(jié)果
order by :按照什么樣的順序來查看返回的數(shù)據(jù)
2.from后面的表關(guān)聯(lián)，是自右向左解析 而where條件的解析順序是自下而上的。
也就是說，在寫SQL語句的時候，盡量把數(shù)據(jù)量小的表放在最右邊來進行關(guān)聯(lián)（用小表去匹配大表），而把能篩選出小量數(shù)據(jù)的條件放在where語句的最左邊 （用小表去匹配大表）
其他參考資源：
http://www.cnblogs.com/huminxxl/p/3149097.html
2.使用explain優(yōu)化sql和索引?
對于復(fù)雜、效率低的sql語句，我們通常是使用explain sql 來分析sql語句，這個語句可以打印出，語句的執(zhí)行。這樣方便我們分析，進行優(yōu)化
table：顯示這一行的數(shù)據(jù)是關(guān)于哪張表的
type：這是重要的列，顯示連接使用了何種類型。從最好到最差的連接類型為const、eq_reg、ref、range、index和ALL
all：full table scan ;MySQL將遍歷全表以找到匹配的行；
index: index scan; index 和 all的區(qū)別在于index類型只遍歷索引；
range：索引范圍掃描，對索引的掃描開始于某一點，返回匹配值的行，常見與between ，等查詢；
ref：非唯一性索引掃描，返回匹配某個單獨值的所有行，常見于使用非唯一索引即唯一索引的非唯一前綴進行查找；
eq_ref：唯一性索引掃描，對于每個索引鍵，表中只有一條記錄與之匹配，常用于主鍵或者唯一索引掃描；
const，system：當(dāng)MySQL對某查詢某部分進行優(yōu)化，并轉(zhuǎn)為一個常量時，使用這些訪問類型。如果將主鍵置于where列表中，MySQL就能將該查詢轉(zhuǎn)化為一個常量。
possible_keys：顯示可能應(yīng)用在這張表中的索引。如果為空，沒有可能的索引?？梢詾橄嚓P(guān)的域從WHERE語句中選擇一個合適的語句
key：實際使用的索引。如果為NULL，則沒有使用索引。很少的情況下，MySQL會選擇優(yōu)化不足的索引。這種情況下，可以在SELECT語句中使用USE INDEX（indexname）來強制使用一個索引或者用IGNORE INDEX（indexname）來強制MySQL忽略索引
key_len：使用的索引的長度。在不損失精確性的情況下，長度越短越好
ref：顯示索引的哪一列被使用了，如果可能的話，是一個常數(shù)
rows：MySQL認(rèn)為必須檢查的用來返回請求數(shù)據(jù)的行數(shù)
Extra：關(guān)于MySQL如何解析查詢的額外信息。
3.MySQL慢查詢怎么解決?
slow_query_log 慢查詢開啟狀態(tài)。
slow_query_log_file 慢查詢?nèi)罩敬娣诺奈恢茫ㄟ@個目錄需要MySQL的運行帳號的可寫權(quán)限，一般設(shè)置為MySQL的數(shù)據(jù)存放目錄）。
long_query_time 查詢超過多少秒才記錄。
六、數(shù)據(jù)庫鎖
1.mysql都有什么鎖，死鎖判定原理和具體場景，死鎖怎么解決?
MySQL有三種鎖的級別：頁級、表級、行級。
表級鎖：開銷小，加鎖快；不會出現(xiàn)死鎖；鎖定粒度大，發(fā)生鎖沖突的概率最高,并發(fā)度最低。
行級鎖：開銷大，加鎖慢；會出現(xiàn)死鎖；鎖定粒度最小，發(fā)生鎖沖突的概率最低,并發(fā)度也最高。
頁面鎖：開銷和加鎖時間界于表鎖和行鎖之間；會出現(xiàn)死鎖；鎖定粒度界于表鎖和行鎖之間，并發(fā)度一般
什么情況下會造成死鎖?
什么是死鎖？
死鎖: 是指兩個或兩個以上的進程在執(zhí)行過程中。因爭奪資源而造成的一種互相等待的現(xiàn)象,若無外力作用,它們都將無法推進下去。此時稱系統(tǒng)處于死鎖狀態(tài)或系統(tǒng)產(chǎn)生了死鎖,這些永遠(yuǎn)在互相等竺的進程稱為死鎖進程。
表級鎖不會產(chǎn)生死鎖.所以解決死鎖主要還是針對于最常用的InnoDB。
死鎖的關(guān)鍵在于：兩個(或以上)的Session加鎖的順序不一致。
那么對應(yīng)的解決死鎖問題的關(guān)鍵就是：讓不同的session加鎖有次序。
死鎖的解決辦法?
1.查出的線程殺死 kill
SELECT?trx_MySQL_thread_id?FROM?information_schema.INNODB_TRX;2.設(shè)置鎖的超時時間
Innodb 行鎖的等待時間，單位秒?？稍跁捈墑e設(shè)置，RDS 實例該參數(shù)的默認(rèn)值為 50（秒）。
生產(chǎn)環(huán)境不推薦使用過大的 innodb_lock_wait_timeout參數(shù)值
該參數(shù)支持在會話級別修改，方便應(yīng)用在會話級別單獨設(shè)置某些特殊操作的行鎖等待超時時間，如下：
set innodb_lock_wait_timeout=1000; —設(shè)置當(dāng)前會話 Innodb 行鎖等待超時時間，單位秒。
3.指定獲取鎖的順序
2.有哪些鎖（樂觀鎖悲觀鎖），select 時怎么加排它鎖?
悲觀鎖（Pessimistic Lock）:
悲觀鎖特點:先獲取鎖，再進行業(yè)務(wù)操作。
即“悲觀”的認(rèn)為獲取鎖是非常有可能失敗的，因此要先確保獲取鎖成功再進行業(yè)務(wù)操作。通常所說的“一鎖二查三更新”即指的是使用悲觀鎖。通常來講在數(shù)據(jù)庫上的悲觀鎖需要數(shù)據(jù)庫本身提供支持，即通過常用的select … for update操作來實現(xiàn)悲觀鎖。
當(dāng)數(shù)據(jù)庫執(zhí)行select for update時會獲取被select中的數(shù)據(jù)行的行鎖，因此其他并發(fā)執(zhí)行的select for update如果試圖選中同一行則會發(fā)生排斥（需要等待行鎖被釋放），因此達(dá)到鎖的效果。select for update獲取的行鎖會在當(dāng)前事務(wù)結(jié)束時自動釋放，因此必須在事務(wù)中使用。
補充：
不同的數(shù)據(jù)庫對select for update的實現(xiàn)和支持都是有所區(qū)別的，
oracle支持select for update no wait，表示如果拿不到鎖立刻報錯，而不是等待，MySQL就沒有no wait這個選項。
MySQL還有個問題是select for update語句執(zhí)行中所有掃描過的行都會被鎖上，這一點很容易造成問題。因此如果在MySQL中用悲觀鎖務(wù)必要確定走了索引，而不是全表掃描。
樂觀鎖（Optimistic Lock）:
1.樂觀鎖，也叫樂觀并發(fā)控制，它假設(shè)多用戶并發(fā)的事務(wù)在處理時不會彼此互相影響，各事務(wù)能夠在不產(chǎn)生鎖的情況下處理各自影響的那部分?jǐn)?shù)據(jù)。在提交數(shù)據(jù)更新之前，每個事務(wù)會先檢查在該事務(wù)讀取數(shù)據(jù)后，有沒有其他事務(wù)又修改了該數(shù)據(jù)。如果其他事務(wù)有更新的話，那么當(dāng)前正在提交的事務(wù)會進行回滾。
2.樂觀鎖的特點先進行業(yè)務(wù)操作，不到萬不得已不去拿鎖。即“樂觀”的認(rèn)為拿鎖多半是會成功的，因此在進行完業(yè)務(wù)操作需要實際更新數(shù)據(jù)的最后一步再去拿一下鎖就好。
樂觀鎖在數(shù)據(jù)庫上的實現(xiàn)完全是邏輯的，不需要數(shù)據(jù)庫提供特殊的支持。
3.一般的做法是在需要鎖的數(shù)據(jù)上增加一個版本號，或者時間戳，
實現(xiàn)方式舉例如下：
樂觀鎖（給表加一個版本號字段） 這個并不是樂觀鎖的定義，給表加版本號，是數(shù)據(jù)庫實現(xiàn)樂觀鎖的一種方式。
SELECT?data?AS?old_data,?version?AS?old_version?FROM?…;
//根據(jù)獲取的數(shù)據(jù)進行業(yè)務(wù)操作，得到new_data和new_version
UPDATE?SET?data?=?new_data,?version?=?new_version?WHERE?version?=?old_version
if?(updated?row?>?0)?{
//?樂觀鎖獲取成功，操作完成
}?else?{
//?樂觀鎖獲取失敗，回滾并重試
}
注意：
樂觀鎖在不發(fā)生取鎖失敗的情況下開銷比悲觀鎖小，但是一旦發(fā)生失敗回滾開銷則比較大，因此適合用在取鎖失敗概率比較小的場景，可以提升系統(tǒng)并發(fā)性能
樂觀鎖還適用于一些比較特殊的場景，例如在業(yè)務(wù)操作過程中無法和數(shù)據(jù)庫保持連接等悲觀鎖無法適用的地方。
總結(jié)：
悲觀鎖和樂觀鎖是數(shù)據(jù)庫用來保證數(shù)據(jù)并發(fā)安全防止更新丟失的兩種方法，例子在select … for update前加個事務(wù)就可以防止更新丟失。悲觀鎖和樂觀鎖大部分場景下差異不大，一些獨特場景下有一些差別，一般我們可以從如下幾個方面來判斷。
響應(yīng)速度：如果需要非常高的響應(yīng)速度，建議采用樂觀鎖方案，成功就執(zhí)行，不成功就失敗，不需要等待其他并發(fā)去釋放鎖。'
沖突頻率：如果沖突頻率非常高，建議采用悲觀鎖，保證成功率，如果沖突頻率大，樂觀鎖會需要多次重試才能成功，代價比較大。
重試代價：如果重試代價大，建議采用悲觀鎖。
七、其他
1.數(shù)據(jù)庫的主從復(fù)制
主從復(fù)制的幾種方式:
同步復(fù)制:
所謂的同步復(fù)制，意思是master的變化，必須等待slave-1,slave-2,…,slave-n完成后才能返回。這樣，顯然不可取，也不是MySQL復(fù)制的默認(rèn)設(shè)置。比如，在WEB前端頁面上，用戶增加了條記錄，需要等待很長時間。
異步復(fù)制:
如同AJAX請求一樣。master只需要完成自己的數(shù)據(jù)庫操作即可。至于slaves是否收到二進制日志，是否完成操作，不用關(guān)心,MySQL的默認(rèn)設(shè)置。
半同步復(fù)制:
master只保證slaves中的一個操作成功，就返回，其他slave不管。這個功能，是由google為MySQL引入的。
2.數(shù)據(jù)庫主從復(fù)制分析的 7 個問題?
問題1：master的寫操作，slaves被動的進行一樣的操作，保持?jǐn)?shù)據(jù)一致性，那么slave是否可以主動的進行寫操作？
假設(shè)slave可以主動的進行寫操作，slave又無法通知master，這樣就導(dǎo)致了master和slave數(shù)據(jù)不一致了。因此slave不應(yīng)該進行寫操作，至少是slave上涉及到復(fù)制的數(shù)據(jù)庫不可以寫。實際上，這里已經(jīng)揭示了讀寫分離的概念。
問題2：主從復(fù)制中，可以有N個slave,可是這些slave又不能進行寫操作，要他們干嘛？
實現(xiàn)數(shù)據(jù)備份：
類似于高可用的功能，一旦master掛了，可以讓slave頂上去，同時slave提升為master。
異地容災(zāi):
比如master在北京，地震掛了，那么在上海的slave還可以繼續(xù)。
主要用于實現(xiàn)scale out,分擔(dān)負(fù)載,可以將讀的任務(wù)分散到slaves上。
【很可能的情況是，一個系統(tǒng)的讀操作遠(yuǎn)遠(yuǎn)多于寫操作，因此寫操作發(fā)向master，讀操作發(fā)向slaves進行操作】
問題3：主從復(fù)制中有master,slave1,slave2,…等等這么多MySQL數(shù)據(jù)庫，那比如一個JAVA WEB應(yīng)用到底應(yīng)該連接哪個數(shù)據(jù)庫?
我們在應(yīng)用程序中可以這樣，insert/delete/update這些更新數(shù)據(jù)庫的操作，用connection(for master)進行操作，
select用connection(for slaves)進行操作。那我們的應(yīng)用程序還要完成怎么從slaves選擇一個來執(zhí)行select，例如使用簡單的輪循算法。
這樣的話，相當(dāng)于應(yīng)用程序完成了SQL語句的路由，而且與MySQL的主從復(fù)制架構(gòu)非常關(guān)聯(lián)，一旦master掛了，某些slave掛了，那么應(yīng)用程序就要修改了。能不能讓應(yīng)用程序與MySQL的主從復(fù)制架構(gòu)沒有什么太多關(guān)系呢？
找一個組件，application program只需要與它打交道，用它來完成MySQL的代理，實現(xiàn)SQL語句的路由。
MySQL proxy并不負(fù)責(zé)，怎么從眾多的slaves挑一個？可以交給另一個組件(比如haproxy)來完成。
這就是所謂的MySQL READ WRITE SPLITE，MySQL的讀寫分離。
問題4：如果MySQL proxy , direct , master他們中的某些掛了怎么辦？
總統(tǒng)一般都會弄個副總統(tǒng)，以防不測。同樣的，可以給這些關(guān)鍵的節(jié)點來個備份。
問題5：當(dāng)master的二進制日志每產(chǎn)生一個事件，都需要發(fā)往slave，如果我們有N個slave,那是發(fā)N次，還是只發(fā)一次？如果只發(fā)一次，發(fā)給了slave-1，那slave-2,slave-3,…它們怎么辦？
顯 然，應(yīng)該發(fā)N次。實際上，在MySQL master內(nèi)部，維護N個線程，每一個線程負(fù)責(zé)將二進制日志文件發(fā)往對應(yīng)的slave。master既要負(fù)責(zé)寫操作，還的維護N個線程，負(fù)擔(dān)會很重。
可以這樣，slave-1是master的從，slave-1又是slave-2,slave-3,…的主，同時slave-1不再負(fù)責(zé)select。slave-1將master的復(fù)制線程的負(fù)擔(dān)，轉(zhuǎn)移到自己的身上。這就是所謂的多級復(fù)制的概念。
問題6：當(dāng)一個select發(fā)往MySQL proxy，可能這次由slave-2響應(yīng)，下次由slave-3響應(yīng)，這樣的話，就無法利用查詢緩存了。
應(yīng)該找一個共享式的緩存，比如memcache來解決。將slave-2,slave-3,…這些查詢的結(jié)果都緩存至mamcache中。
問題7：隨著應(yīng)用的日益增長，讀操作很多，我們可以擴展slave，但是如果master滿足不了寫操作了，怎么辦呢？
scale on ?更好的服務(wù)器？沒有最好的，只有更好的，太貴了。。。
scale out ? 主從復(fù)制架構(gòu)已經(jīng)滿足不了。
可以分庫【垂直拆分】，分表【水平拆分】。
3.mysql 高并發(fā)環(huán)境解決方案?
MySQL 高并發(fā)環(huán)境解決方案：分庫 分表 分布式 增加二級緩存。。。。。
需求分析：互聯(lián)網(wǎng)單位 每天大量數(shù)據(jù)讀取，寫入，并發(fā)性高。
現(xiàn)有解決方式：水平分庫分表，由單點分布到多點數(shù)據(jù)庫中，從而降低單點數(shù)據(jù)庫壓力。
集群方案：解決DB宕機帶來的單點DB不能訪問問題。
讀寫分離策略：極大限度提高了應(yīng)用中Read數(shù)據(jù)的速度和并發(fā)量。無法解決高寫入壓力。
4.數(shù)據(jù)庫崩潰時事務(wù)的恢復(fù)機制（REDO日志和UNDO日志）?
來源：
https://www.cnblogs.com/Bozh/archive/2013/03/18/2966494.html
Undo Log:
Undo Log是為了實現(xiàn)事務(wù)的原子性，在MySQL數(shù)據(jù)庫InnoDB存儲引擎中，還用了Undo Log來實現(xiàn)多版本并發(fā)控制(簡稱：MVCC)。
事務(wù)的原子性(Atomicity)事務(wù)中的所有操作，要么全部完成，要么不做任何操作，不能只做部分操作。如果在執(zhí)行的過程中發(fā)生了錯誤，要回滾(Rollback)到事務(wù)開始前的狀態(tài)，就像這個事務(wù)從來沒有執(zhí)行過。
原理Undo Log的原理很簡單，為了滿足事務(wù)的原子性，在操作任何數(shù)據(jù)之前，首先將數(shù)據(jù)備份到一個地方（這個存儲數(shù)據(jù)備份的地方稱為UndoLog）。然后進行數(shù)據(jù)的修改。如果出現(xiàn)了錯誤或者用戶執(zhí)行了ROLLBACK語句，系統(tǒng)可以利用Undo Log中的備份將數(shù)據(jù)恢復(fù)到事務(wù)開始之前的狀態(tài)。
之所以能同時保證原子性和持久化，是因為以下特點：
更新數(shù)據(jù)前記錄Undo log。
為了保證持久性，必須將數(shù)據(jù)在事務(wù)提交前寫到磁盤。只要事務(wù)成功提交，數(shù)據(jù)必然已經(jīng)持久化。
Undo log必須先于數(shù)據(jù)持久化到磁盤。如果在G,H之間系統(tǒng)崩潰，undo log是完整的， 可以用來回滾事務(wù)。
如果在A-F之間系統(tǒng)崩潰,因為數(shù)據(jù)沒有持久化到磁盤。所以磁盤上的數(shù)據(jù)還是保持在事務(wù)開始前的狀態(tài)。
缺陷：
每個事務(wù)提交前將數(shù)據(jù)和Undo Log寫入磁盤，這樣會導(dǎo)致大量的磁盤IO，因此性能很低。
如果能夠?qū)?shù)據(jù)緩存一段時間，就能減少IO提高性能。但是這樣就會喪失事務(wù)的持久性。因此引入了另外一種機制來實現(xiàn)持久化，即Redo Log。
Redo Log:
原理和Undo Log相反，Redo Log記錄的是新數(shù)據(jù)的備份。在事務(wù)提交前，只要將Redo Log持久化即可，不需要將數(shù)據(jù)持久化。當(dāng)系統(tǒng)崩潰時，雖然數(shù)據(jù)沒有持久化，但是Redo Log已經(jīng)持久化。系統(tǒng)可以根據(jù)Redo Log的內(nèi)容，將所有數(shù)據(jù)恢復(fù)到最新的狀態(tài)。
——END——