訂閱
糾錯
加入自媒體

MySQL常見的存儲引擎InnoDB、MyISAM有何區(qū)別?

大家好,我是阿秀。

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

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

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

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

在任何一個(gè)關(guān)系數(shù)據(jù)庫中,第一范式(1NF)是對關(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í)體之間為一對多關(guān)系。在第一范式(1NF)中表的每一行只包含一個(gè)實(shí)例的信息。

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

第二范式

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

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

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

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

第三范式

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

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

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

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

(1)簡單歸納:

第一范式(1NF):字段不可分;  

第二范式(2NF):有主鍵,非主鍵字段依賴主鍵;  

第三范式(3NF):非主鍵字段不能相互依賴。

(2)解釋:

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

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

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

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

1)事務(wù):MyISAM不支持,InnoDB支持

2)鎖級別:MyISAM 表級鎖,InnoDB 行級鎖及外鍵約束

3)MyISAM存儲表的總行數(shù);InnoDB不存儲總行數(shù);

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

適用場景:

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

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

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

第一種回答

原子性:一個(gè)事務(wù)(transaction)中的所有操作,要么全部完成,要么全部不完成,不會結(jié)束在中間某個(gè)環(huán)節(jié)。。事務(wù)在執(zhí)行過程中發(fā)生錯誤,會被恢復(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í)對其數(shù)據(jù)進(jìn)行讀寫和修改的能力,隔離性可以防止多個(gè)事務(wù)并發(fā)執(zhí)行時(shí)由于交叉執(zhí)行而導(dǎo)致數(shù)據(jù)的不一致。事務(wù)隔離分為不同級別,包括讀未提交(Read uncommitted)、讀提交(read committed)、可重復(fù)讀(repeatable read)和串行化(Serializable)。持久性:事務(wù)處理結(jié)束后,對數(shù)據(jù)的修改就是永久的,即便系統(tǒng)故障也不會丟失。

第二種回答

原子性(Atomicity)

原子性是指事務(wù)包含的所有操作要么全部成功,要么全部失敗回滾,因此事務(wù)的操作如果成功就必須要完全應(yīng)用到數(shù)據(jù)庫,如果操作失敗則不能對數(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ù)請求同一數(shù)據(jù),不同的事務(wù)之間彼此沒有任何干擾。比如A正在從一張銀行卡中取錢,在A取錢的過程結(jié)束前,B不能向這張卡轉(zhuǎn)賬。關(guān)于事務(wù)的隔離性數(shù)據(jù)庫提供了多種隔離級別,稍后會介紹到。?

持久性(Durability)

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

30、SQL中的NOW()和CURRENT_DATE()兩個(gè)函數(shù)有什么區(qū)別?

NOW()命令用于顯示當(dāng)前年份,月份,日期,小時(shí),分鐘和秒。CURRENT_DATE()僅顯示當(dāng)前年份,月份和日期。

31、什么是聚合索引 ?

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

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

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

32、什么是非聚合索引?

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

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

很顯然,這些字并不是真正的分別位于"張"字的上下方,現(xiàn)在您看到的連續(xù)的"馳、張、弩"三字實(shí)際上就是他 們在非聚集索引中的排序,是字典正文中的字在非聚集索引中的映射。

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

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

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

非聚集索引和聚集索引的區(qū)別在于, 通過聚集索引可以查到需要查找的數(shù)據(jù), 而通過非聚集索引可以查到記錄對應(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ù)塊的指針。

1  2  3  下一頁>  
聲明: 本文由入駐維科號的作者撰寫,觀點(diǎn)僅代表作者本人,不代表OFweek立場。如有侵權(quán)或其他問題,請聯(lián)系舉報(bào)。

發(fā)表評論

0條評論,0人參與

請輸入評論內(nèi)容...

請輸入評論/評論長度6~500個(gè)字

您提交的評論過于頻繁,請輸入驗(yàn)證碼繼續(xù)

  • 看不清,點(diǎn)擊換一張  刷新

暫無評論

暫無評論

人工智能 獵頭職位 更多
掃碼關(guān)注公眾號
OFweek人工智能網(wǎng)
獲取更多精彩內(nèi)容
文章糾錯
x
*文字標(biāo)題:
*糾錯內(nèi)容:
聯(lián)系郵箱:
*驗(yàn) 證 碼:

粵公網(wǎng)安備 44030502002758號