大家好，我是阿秀。

我來更新了，本期是 MySQL 第二期，至此 MySQL 部分就全部更新完畢了，下一彈就是 Redis 篇了。

上一篇文章中，小伙伴建議將資料按照更細(xì)粒度去整理一番，我覺得是非常不錯(cuò)的建議。目前正在整理中，等全部整理完畢就會(huì)更新第四版的 PDF 版本了，第三版的 PDF 直接回復(fù)關(guān)鍵字 「PDF」 就可以下載了。

話不多說，那我們就開始本期內(nèi)容吧。

26、數(shù)據(jù)庫三大范式精講第一范式

在任何一個(gè)關(guān)系數(shù)據(jù)庫中，第一范式（1NF）是對(duì)關(guān)系模式的基本要求，不滿足第一范式（1NF）的數(shù)據(jù)庫就不是關(guān)系數(shù)據(jù)庫。所謂第一范式（1NF）是指數(shù)據(jù)庫表的每一列都是不可分割的基本數(shù)據(jù)項(xiàng)，同一列中不能有多個(gè)值，即實(shí)體中的某個(gè)屬性不能有多個(gè)值或者不能有重復(fù)的屬性。

如果出現(xiàn)重復(fù)的屬性，就可能需要定義一個(gè)新的實(shí)體，新的實(shí)體由重復(fù)的屬性構(gòu)成，新實(shí)體與原實(shí)體之間為一對(duì)多關(guān)系。在第一范式（1NF）中表的每一行只包含一個(gè)實(shí)例的信息。

簡而言之，第一范式就是無重復(fù)的列。

第二范式

第二范式（2NF）是在第一范式（1NF）的基礎(chǔ)上建立起來的，即滿足第二范式（2NF）必須先滿足第一范式（1NF）。第二范式（2NF）要求數(shù)據(jù)庫表中的每個(gè)實(shí)例或行必須可以被惟一地區(qū)分。

為實(shí)現(xiàn)區(qū)分通常需要為表加上一個(gè)列，以存儲(chǔ)各個(gè)實(shí)例的惟一標(biāo)識(shí)。這個(gè)惟一屬性列被稱為主關(guān)鍵字或主鍵、主碼。第二范式（2NF）要求實(shí)體的屬性完全依賴于主關(guān)鍵字。

所謂完全依賴是指不能存在僅依賴主關(guān)鍵字一部分的屬性，如果存在，那么這個(gè)屬性和主關(guān)鍵字的這一部分應(yīng)該分離出來形成一個(gè)新的實(shí)體，新實(shí)體與原實(shí)體之間是一對(duì)多的關(guān)系。為實(shí)現(xiàn)區(qū)分通常需要為表加上一個(gè)列，以存儲(chǔ)各個(gè)實(shí)例的惟一標(biāo)識(shí)。

簡而言之，第二范式就是非主屬性非部分依賴于主關(guān)鍵字。

第三范式

滿足第三范式（3NF）必須先滿足第二范式（2NF）。簡而言之，第三范式（3NF）要求一個(gè)數(shù)據(jù)庫表中不包含已在其它表中已包含的非主關(guān)鍵字信息。

例如，存在一個(gè)部門信息表，其中每個(gè)部門有部門編號(hào)（dept＿id）、部門名稱、部門簡介等信息。那么在員工信息表中列出部門編號(hào)后就不能再將部門名稱、部門簡介等與部門有關(guān)的信息再加入員工信息表中。如果不存在部門信息表，則根據(jù)第三范式（3NF）也應(yīng)該構(gòu)建它，否則就會(huì)有大量的數(shù)據(jù)冗余。

簡而言之，第三范式就是屬性不依賴于其它非主屬性。

27、數(shù)據(jù)庫三大范式精要總結(jié)

（1）簡單歸納：

第一范式（1NF）：字段不可分；　　

第二范式（2NF）：有主鍵，非主鍵字段依賴主鍵；　　

第三范式（3NF）：非主鍵字段不能相互依賴。

（2）解釋：

1NF：原子性。字段不可再分，否則就不是關(guān)系數(shù)據(jù)庫；；　　

2NF：唯一性 。一個(gè)表只說明一個(gè)事物；　　

3NF：每列都與主鍵有直接關(guān)系，不存在傳遞依賴。

28、MySQL常見的存儲(chǔ)引擎InnoDB、MyISAM的區(qū)別？適用場(chǎng)景分別是？

1）事務(wù)：MyISAM不支持，InnoDB支持

2）鎖級(jí)別：MyISAM 表級(jí)鎖，InnoDB 行級(jí)鎖及外鍵約束

3）MyISAM存儲(chǔ)表的總行數(shù)；InnoDB不存儲(chǔ)總行數(shù)；

4）MyISAM采用非聚集索引，B＋樹葉子存儲(chǔ)指向數(shù)據(jù)文件的指針。InnoDB主鍵索引采用聚集索引，B＋樹葉子存儲(chǔ)數(shù)據(jù)

適用場(chǎng)景：

MyISAM適合：插入不頻繁，查詢非常頻繁，如果執(zhí)行大量的SELECT，MyISAM是更好的選擇， 沒有事務(wù)。

InnoDB適合：可靠性要求比較高，或者要求事務(wù)；表更新和查詢都相當(dāng)?shù)念l繁， 大量的INSERT或UPDATE

29、事務(wù)四大特性（ACID）原子性、一致性、隔離性、持久性？

第一種回答

原子性：一個(gè)事務(wù)（transaction）中的所有操作，要么全部完成，要么全部不完成，不會(huì)結(jié)束在中間某個(gè)環(huán)節(jié)。。事務(wù)在執(zhí)行過程中發(fā)生錯(cuò)誤，會(huì)被恢復(fù)（Rollback）到事務(wù)開始前的狀態(tài)，就像這個(gè)事務(wù)從來沒有執(zhí)行過一樣。一致性：在事務(wù)開始之前和事務(wù)結(jié)束以后，數(shù)據(jù)庫的完整性沒有被破壞。這表示寫入的資料必須完全符合所有的預(yù)設(shè)規(guī)則，這包含資料的精確度、串聯(lián)性以及后續(xù)數(shù)據(jù)庫可以自發(fā)性地完成預(yù)定的工作。隔離性：數(shù)據(jù)庫允許多個(gè)并發(fā)事務(wù)同時(shí)對(duì)其數(shù)據(jù)進(jìn)行讀寫和修改的能力，隔離性可以防止多個(gè)事務(wù)并發(fā)執(zhí)行時(shí)由于交叉執(zhí)行而導(dǎo)致數(shù)據(jù)的不一致。事務(wù)隔離分為不同級(jí)別，包括讀未提交（Read uncommitted）、讀提交（read committed）、可重復(fù)讀（repeatable read）和串行化（Serializable）。持久性：事務(wù)處理結(jié)束后，對(duì)數(shù)據(jù)的修改就是永久的，即便系統(tǒng)故障也不會(huì)丟失。

第二種回答

原子性（Atomicity）

原子性是指事務(wù)包含的所有操作要么全部成功，要么全部失敗回滾，因此事務(wù)的操作如果成功就必須要完全應(yīng)用到數(shù)據(jù)庫，如果操作失敗則不能對(duì)數(shù)據(jù)庫有任何影響。

一致性（Consistency）

事務(wù)開始前和結(jié)束后，數(shù)據(jù)庫的完整性約束沒有被破壞。比如A向B轉(zhuǎn)賬，不可能A扣了錢，B卻沒收到。

隔離性（Isolation）

隔離性是當(dāng)多個(gè)用戶并發(fā)訪問數(shù)據(jù)庫時(shí)，比如操作同一張表時(shí)，數(shù)據(jù)庫為每一個(gè)用戶開啟的事務(wù)，不能被其他事務(wù)的操作所干擾，多個(gè)并發(fā)事務(wù)之間要相互隔離。

同一時(shí)間，只允許一個(gè)事務(wù)請(qǐng)求同一數(shù)據(jù)，不同的事務(wù)之間彼此沒有任何干擾。比如A正在從一張銀行卡中取錢，在A取錢的過程結(jié)束前，B不能向這張卡轉(zhuǎn)賬。關(guān)于事務(wù)的隔離性數(shù)據(jù)庫提供了多種隔離級(jí)別，稍后會(huì)介紹到。?

持久性（Durability）

持久性是指一個(gè)事務(wù)一旦被提交了，那么對(duì)數(shù)據(jù)庫中的數(shù)據(jù)的改變就是永久性的，即便是在數(shù)據(jù)庫系統(tǒng)遇到故障的情況下也不會(huì)丟失提交事務(wù)的操作。

30、SQL中的NOW（）和CURRENT＿DATE（）兩個(gè)函數(shù)有什么區(qū)別？

NOW（）命令用于顯示當(dāng)前年份，月份，日期，小時(shí)，分鐘和秒。CURRENT＿DATE（）僅顯示當(dāng)前年份，月份和日期。

31、什么是聚合索引 ？

聚簇索引就是按照拼音查詢，非聚簇索引就是按照偏旁等來進(jìn)行查詢。

其實(shí)，我們的漢語字典的正文本身就是一個(gè)聚集索引。比如，我們要查＂安＂字，就會(huì)很自然地翻開字典的前幾頁，因?yàn)椋�安＂的拼音是＂an＂，而按照拼音排序 漢字的字典是以英文字母＂a＂開頭并以＂z＂結(jié)尾的，那么＂安＂字就自然地排在字典的前部。如果您翻完了所有以＂a＂開頭的部分仍然找不到這個(gè)字，那么就 說明您的字典中沒有這個(gè)字；同樣的，如果查＂張＂字，那您也會(huì)將您的字典翻到最后部分，因?yàn)椋�張＂的拼音是＂zhang＂。也就是說，字典的正文部分本身 就是一個(gè)目錄，您不需要再去查其他目錄來找到您需要找的內(nèi)容。

我們把這種正文內(nèi)容本身就是一種按照一定規(guī)則排列的目錄稱為＂聚集索引＂

32、什么是非聚合索引？

如果您認(rèn)識(shí)某個(gè)字，您可以快速地從自動(dòng)中查到這個(gè)字。但您也可能會(huì)遇到您不認(rèn)識(shí)的字，不知道它的發(fā)音，這時(shí)候，您就不能按照剛才的方法找到您要查的字，而 需要去根據(jù)＂偏旁部首＂查到您要找的字，然后根據(jù)這個(gè)字后的頁碼直接翻到某頁來找到您要找的字。

但您結(jié)合＂部首目錄＂和＂檢字表＂而查到的字的排序并不是 真正的正文的排序方法，比如您查＂張＂字，我們可以看到在查部首之后的檢字表中＂張＂的頁碼是672頁，檢字表中＂張＂的上面是＂馳＂字，但頁碼卻是63 頁，＂張＂的下面是＂弩＂字，頁面是390頁。

很顯然，這些字并不是真正的分別位于＂張＂字的上下方，現(xiàn)在您看到的連續(xù)的＂馳、張、弩＂三字實(shí)際上就是他 們?cè)诜蔷奂�索引中的排序，是字典正文中的字在非聚集索引中的映射�?/p>

我們可以通過這種方式來找到您所需要的字，但它需要兩個(gè)過程，先找到目錄中的結(jié)果，然后 再翻到您所需要的頁碼。

我們把這種目錄純粹是目錄，正文純粹是正文的排序方式稱為＂非聚集索引＂。

33、聚集索引與非聚集索引的區(qū)別是什么？

非聚集索引和聚集索引的區(qū)別在于， 通過聚集索引可以查到需要查找的數(shù)據(jù)， 而通過非聚集索引可以查到記錄對(duì)應(yīng)的主鍵值 ， 再使用主鍵的值通過聚集索引查找到需要的數(shù)據(jù)。聚集索引和非聚集索引的根本區(qū)別是表記錄的排列順序和與索引的排列順序是否一致。

聚集索引（Innodb）的葉節(jié)點(diǎn)就是數(shù)據(jù)節(jié)點(diǎn)，而非聚集索引（MyisAM）的葉節(jié)點(diǎn)仍然是索引節(jié)點(diǎn)，只不過其包含一個(gè)指向?qū)��?yīng)數(shù)據(jù)塊的指針。