国产色诱美女免费视频|欧美精彩狠狠色丁香婷婷|91黑人|日本黄色小视频|欧美一级黄色视频在这里免费观看

IT培訓(xùn)-高端面授IT培訓(xùn)機(jī)構(gòu)
云和教育:云和數(shù)據(jù)集團(tuán)高端IT職業(yè)教育品牌
  • 國(guó)家級(jí)
    全民數(shù)字素養(yǎng)與技能培訓(xùn)基地
  • 河南省
    第一批產(chǎn)教融合型企業(yè)建設(shè)培育單位
  • 鄭州市
    數(shù)字技能人才(碼農(nóng))培養(yǎng)評(píng)價(jià)聯(lián)盟
  • 國(guó)家級(jí)
    全民數(shù)字素養(yǎng)與技能培訓(xùn)基地
  • 河南省
    第一批產(chǎn)教融合型企業(yè)建設(shè)培育單位
  • 鄭州市
    數(shù)字技能人才(碼農(nóng))培養(yǎng)評(píng)價(jià)聯(lián)盟

Java面試培訓(xùn)-企業(yè)常問(wèn)的數(shù)據(jù)庫(kù)方面問(wèn)題

  • 發(fā)布時(shí)間:
    2018-07-11
  • 版權(quán)所有:
    云和教育
  • 分享:

今天給大家講下Java面試培訓(xùn)-企業(yè)常問(wèn)的數(shù)據(jù)庫(kù)方面問(wèn)題:為什么用自增列作為主鍵

如果我們定義了主鍵(PRIMARY KEY),那么InnoDB會(huì)選擇主鍵作為聚集索引、如果沒(méi)有顯式定義主鍵,則InnoDB會(huì)選擇第一個(gè)不包含有NULL值的唯一索引作為主鍵索引、如果也沒(méi)有這樣的唯一索引,則InnoDB會(huì)選擇內(nèi)置6字節(jié)長(zhǎng)的ROWID作為隱含的聚集索引(ROWID隨著行記錄的寫入而主鍵遞增,這個(gè)ROWID不像ORACLE的ROWID那樣可引用,是隱含的)。

數(shù)據(jù)記錄本身被存于主索引(一顆B+Tree)的葉子節(jié)點(diǎn)上。這就要求同一個(gè)葉子節(jié)點(diǎn)內(nèi)(大小為一個(gè)內(nèi)存頁(yè)或磁盤頁(yè))的各條數(shù)據(jù)記錄按主鍵順序存放,因此每當(dāng)有一條新的記錄插入時(shí),MySQL會(huì)根據(jù)其主鍵將其插入適當(dāng)?shù)墓?jié)點(diǎn)和位置,如果頁(yè)面達(dá)到裝載因子(InnoDB默認(rèn)為15/16),則開辟一個(gè)新的頁(yè)(節(jié)點(diǎn))

如果表使用自增主鍵,那么每次插入新的記錄,記錄就會(huì)順序添加到當(dāng)前索引節(jié)點(diǎn)的后續(xù)位置,當(dāng)一頁(yè)寫滿,就會(huì)自動(dòng)開辟一個(gè)新的頁(yè)

如果使用非自增主鍵(如果身份證號(hào)或?qū)W號(hào)等),由于每次插入主鍵的值近似于隨機(jī),因此每次新紀(jì)錄都要被插到現(xiàn)有索引頁(yè)得中間某個(gè)位置,此時(shí)MySQL不得不為了將新記錄插到合適位置而移動(dòng)數(shù)據(jù),甚至目標(biāo)頁(yè)面可能已經(jīng)被回寫到磁盤上而從緩存中清掉,此時(shí)又要從磁盤上讀回來(lái),這增加了很多開銷,同時(shí)頻繁的移動(dòng)、分頁(yè)操作造成了大量的碎片,得到了不夠緊湊的索引結(jié)構(gòu),后續(xù)不得不通過(guò)OPTIMIZE TABLE來(lái)重建表并優(yōu)化填充頁(yè)面。

為什么使用數(shù)據(jù)索引能提高效率

數(shù)據(jù)索引的存儲(chǔ)是有序的

在有序的情況下,通過(guò)索引查詢一個(gè)數(shù)據(jù)是無(wú)需遍歷索引記錄的

極端情況下,數(shù)據(jù)索引的查詢效率為二分法查詢效率,趨近于 log2(N)

B+樹索引和哈希索引的區(qū)別

B+樹是一個(gè)平衡的多叉樹,從根節(jié)點(diǎn)到每個(gè)葉子節(jié)點(diǎn)的高度差值不超過(guò)1,而且同層級(jí)的節(jié)點(diǎn)間有指針相互鏈接,是有序的

微信圖片_20180711104934.jpg

哈希索引就是采用一定的哈希算法,把鍵值換算成新的哈希值,檢索時(shí)不需要類似B+樹那樣從根節(jié)點(diǎn)到葉子節(jié)點(diǎn)逐級(jí)查找,只需一次哈希算法即可,是無(wú)序的

微信圖片_20180711104938.jpg

哈希索引的優(yōu)勢(shì):

等值查詢。哈希索引具有絕對(duì)優(yōu)勢(shì)(前提是:沒(méi)有大量重復(fù)鍵值,如果大量重復(fù)鍵值時(shí),哈希索引的效率很低,因?yàn)榇嬖谒^的哈希碰撞問(wèn)題。)

哈希索引不適用的場(chǎng)景:

不支持范圍查詢

不支持索引完成排序

不支持聯(lián)合索引的最左前綴匹配規(guī)則

通常,B+樹索引結(jié)構(gòu)適用于絕大多數(shù)場(chǎng)景,像下面這種場(chǎng)景用哈希索引才更有優(yōu)勢(shì):

在HEAP表中,如果存儲(chǔ)的數(shù)據(jù)重復(fù)度很低(也就是說(shuō)基數(shù)很大),對(duì)該列數(shù)據(jù)以等值查詢?yōu)橹鳎瑳](méi)有范圍查詢、沒(méi)有排序的時(shí)候,特別適合采用哈希索引,例如這種SQL:

select id,name from table where name=’李明’; — 僅等值查詢

而常用的InnoDB引擎中默認(rèn)使用的是B+樹索引,它會(huì)實(shí)時(shí)監(jiān)控表上索引的使用情況,如果認(rèn)為建立哈希索引可以提高查詢效率,則自動(dòng)在內(nèi)存中的“自適應(yīng)哈希索引緩沖區(qū)”建立哈希索引(在InnoDB中默認(rèn)開啟自適應(yīng)哈希索引),通過(guò)觀察搜索模式,MySQL會(huì)利用index key的前綴建立哈希索引,如果一個(gè)表幾乎大部分都在緩沖池中,那么建立一個(gè)哈希索引能夠加快等值查詢。

注意:在某些工作負(fù)載下,通過(guò)哈希索引查找?guī)?lái)的性能提升遠(yuǎn)大于額外的監(jiān)控索引搜索情況和保持這個(gè)哈希表結(jié)構(gòu)所帶來(lái)的開銷。但某些時(shí)候,在負(fù)載高的情況下,自適應(yīng)哈希索引中添加的read/write鎖也會(huì)帶來(lái)競(jìng)爭(zhēng),比如高并發(fā)的join操作。like操作和%的通配符操作也不適用于自適應(yīng)哈希索引,可能要關(guān)閉自適應(yīng)哈希索引。

B樹和B+樹的區(qū)別

B樹,每個(gè)節(jié)點(diǎn)都存儲(chǔ)key和data,所有節(jié)點(diǎn)組成這棵樹,并且葉子節(jié)點(diǎn)指針為nul,葉子結(jié)點(diǎn)不包含任何關(guān)鍵字信息。

微信圖片_20180711104945.jpg

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

微信圖片_20180711104949.jpg

為什么說(shuō)B+比B樹更適合實(shí)際應(yīng)用中操作系統(tǒng)的文件索引和數(shù)據(jù)庫(kù)索引?

B+的磁盤讀寫代價(jià)更低B+的內(nèi)部結(jié)點(diǎn)并沒(méi)有指向關(guān)鍵字具體信息的指針。因此其內(nèi)部結(jié)點(diǎn)相對(duì)B樹更小。如果把所有同一內(nèi)部結(jié)點(diǎn)的關(guān)鍵字存放在同一盤塊中,那么盤塊所能容納的關(guān)鍵字?jǐn)?shù)量也越多。一次性讀入內(nèi)存中的需要查找的關(guān)鍵字也就越多。相對(duì)來(lái)說(shuō)IO讀寫次數(shù)也就降低了。

B+-tree的查詢效率更加穩(wěn)定由于非終結(jié)點(diǎn)并不是最終指向文件內(nèi)容的結(jié)點(diǎn),而只是葉子結(jié)點(diǎn)中關(guān)鍵字的索引。所以任何關(guān)鍵字的查找必須走一條從根結(jié)點(diǎn)到葉子結(jié)點(diǎn)的路。所有關(guān)鍵字查詢的路徑長(zhǎng)度相同,導(dǎo)致每一個(gè)數(shù)據(jù)的查詢效率相當(dāng)。

MySQL聯(lián)合索引

聯(lián)合索引是兩個(gè)或更多個(gè)列上的索引。對(duì)于聯(lián)合索引:Mysql從左到右的使用索引中的字段,一個(gè)查詢可以只使用索引中的一部份,但只能是最左側(cè)部分。例如索引是key index (a,b,c). 可以支持a ? 、 ? ?a,b ? 、 ?a,b,c 3種組合進(jìn)行查找,但不支持 b,c進(jìn)行查找 .當(dāng)最左側(cè)字段是常量引用時(shí),索引就十分有效。

利用索引中的附加列,您可以縮小搜索的范圍,但使用一個(gè)具有兩列的索引 不同于使用兩個(gè)單獨(dú)的索引。復(fù)合索引的結(jié)構(gòu)與電話簿類似,人名由姓和名構(gòu)成,電話簿首先按姓氏對(duì)進(jìn)行排序,然后按名字對(duì)有相同姓氏的人進(jìn)行排序。如果您知 道姓,電話簿將非常有用;如果您知道姓和名,電話簿則更為有用,但如果您只知道名不姓,電話簿將沒(méi)有用處。

什么情況下應(yīng)不建或少建索引

表記錄太少

經(jīng)常插入、刪除、修改的表

數(shù)據(jù)重復(fù)且分布平均的表字段,假如一個(gè)表有10萬(wàn)行記錄,有一個(gè)字段A只有T和F兩種值,且每個(gè)值的分布概率大約為50%,那么對(duì)這種表A字段建索引一般不會(huì)提高數(shù)據(jù)庫(kù)的查詢速度。

經(jīng)常和主字段一塊查詢但主字段索引值比較多的表字段

MySQL分區(qū)

一. 什么是表分區(qū)?

表分區(qū),是指根據(jù)一定規(guī)則,將數(shù)據(jù)庫(kù)中的一張表分解成多個(gè)更小的,容易管理的部分。從邏輯上看,只有一張表,但是底層卻是由多個(gè)物理分區(qū)組成。

二. 表分區(qū)與分表的區(qū)別

分表:指的是通過(guò)一定規(guī)則,將一張表分解成多張不同的表。比如將用戶訂單記錄根據(jù)時(shí)間成多個(gè)表。

分表與分區(qū)的區(qū)別在于:分區(qū)從邏輯上來(lái)講只有一張表,而分表則是將一張表分解成多張表。

三. 表分區(qū)有什么好處?

分區(qū)表的數(shù)據(jù)可以分布在不同的物理設(shè)備上,從而高效地利用多個(gè)硬件設(shè)備。 2. 和單個(gè)磁盤或者文件系統(tǒng)相比,可以存儲(chǔ)更多數(shù)據(jù)

優(yōu)化查詢。在where語(yǔ)句中包含分區(qū)條件時(shí),可以只掃描一個(gè)或多個(gè)分區(qū)表來(lái)提高查詢效率;涉及sum和count語(yǔ)句時(shí),也可以在多個(gè)分區(qū)上并行處理,最后匯總結(jié)果。

分區(qū)表更容易維護(hù)。例如:想批量刪除大量數(shù)據(jù)可以清除整個(gè)分區(qū)。

可以使用分區(qū)表來(lái)避免某些特殊的瓶頸,例如InnoDB的單個(gè)索引的互斥訪問(wèn),ext3問(wèn)價(jià)你系統(tǒng)的inode鎖競(jìng)爭(zhēng)等。

四. 分區(qū)表的限制因素

一個(gè)表最多只能有1024個(gè)分區(qū)

MySQL5.1中,分區(qū)表達(dá)式必須是整數(shù),或者返回整數(shù)的表達(dá)式。在MySQL5.5中提供了非整數(shù)表達(dá)式分區(qū)的支持。

如果分區(qū)字段中有主鍵或者唯一索引的列,那么多有主鍵列和唯一索引列都必須包含進(jìn)來(lái)。即:分區(qū)字段要么不包含主鍵或者索引列,要么包含全部主鍵和索引列。

分區(qū)表中無(wú)法使用外鍵約束

MySQL的分區(qū)適用于一個(gè)表的所有數(shù)據(jù)和索引,不能只對(duì)表數(shù)據(jù)分區(qū)而不對(duì)索引分區(qū),也不能只對(duì)索引分區(qū)而不對(duì)表分區(qū),也不能只對(duì)表的一部分?jǐn)?shù)據(jù)分區(qū)。

五. 如何判斷當(dāng)前MySQL是否支持分區(qū)?

命令:show variables like ‘%partition%’ 運(yùn)行結(jié)果:

mysql> show variables like ‘%partition%’;+——————-+——-+| Variable_name ? ? | Value |+——————-+——-+| have_partitioning | YES ? |+——————-+——-+1 row in set (0.00 sec)have_partintioning 的值為YES,表示支持分區(qū)。

六. MySQL支持的分區(qū)類型有哪些?

RANGE分區(qū): 這種模式允許將數(shù)據(jù)劃分不同范圍。例如可以將一個(gè)表通過(guò)年份劃分成若干個(gè)分區(qū)

LIST分區(qū): 這種模式允許系統(tǒng)通過(guò)預(yù)定義的列表的值來(lái)對(duì)數(shù)據(jù)進(jìn)行分割。按照List中的值分區(qū),與RANGE的區(qū)別是,range分區(qū)的區(qū)間范圍值是連續(xù)的。

HASH分區(qū) :這中模式允許通過(guò)對(duì)表的一個(gè)或多個(gè)列的Hash Key進(jìn)行計(jì)算,最后通過(guò)這個(gè)Hash碼不同數(shù)值對(duì)應(yīng)的數(shù)據(jù)區(qū)域進(jìn)行分區(qū)。例如可以建立一個(gè)對(duì)表主鍵進(jìn)行分區(qū)的表。

KEY分區(qū) :上面Hash模式的一種延伸,這里的Hash Key是MySQL系統(tǒng)產(chǎn)生的。

四種隔離級(jí)別

Serializable (串行化):可避免臟讀、不可重復(fù)讀、幻讀的發(fā)生。

Repeatable read (可重復(fù)讀):可避免臟讀、不可重復(fù)讀的發(fā)生。

Read committed (讀已提交):可避免臟讀的發(fā)生。

Read uncommitted (讀未提交):最低級(jí)別,任何情況都無(wú)法保證。

關(guān)于MVVC

MySQL InnoDB存儲(chǔ)引擎,實(shí)現(xiàn)的是基于多版本的并發(fā)控制協(xié)議——MVCC (Multi-Version Concurrency Control) (注:與MVCC相對(duì)的,是基于鎖的并發(fā)控制,Lock-Based Concurrency Control)。MVCC最大的好處:讀不加鎖,讀寫不沖突。在讀多寫少的OLTP應(yīng)用中,讀寫不沖突是非常重要的,極大的增加了系統(tǒng)的并發(fā)性能,現(xiàn)階段幾乎所有的RDBMS,都支持了MVCC。

LBCC:Lock-Based Concurrency Control,基于鎖的并發(fā)控制。

MVCC:Multi-Version Concurrency Control,基于多版本的并發(fā)控制協(xié)議。純粹基于鎖的并發(fā)機(jī)制并發(fā)量低,MVCC是在基于鎖的并發(fā)控制上的改進(jìn),主要是在讀操作上提高了并發(fā)量。

在MVCC并發(fā)控制中,讀操作可以分成兩類:

快照讀 (snapshot read):讀取的是記錄的可見版本 (有可能是歷史版本),不用加鎖(共享讀鎖s鎖也不加,所以不會(huì)阻塞其他事務(wù)的寫)。

當(dāng)前讀 (current read):讀取的是記錄的最新版本,并且,當(dāng)前讀返回的記錄,都會(huì)加上鎖,保證其他事務(wù)不會(huì)再并發(fā)修改這條記錄。

行級(jí)鎖定的優(yōu)點(diǎn):

當(dāng)在許多線程中訪問(wèn)不同的行時(shí)只存在少量鎖定沖突。

回滾時(shí)只有少量的更改

可以長(zhǎng)時(shí)間鎖定單一的行。

行級(jí)鎖定的缺點(diǎn):

比頁(yè)級(jí)或表級(jí)鎖定占用更多的內(nèi)存。

當(dāng)在表的大部分中使用時(shí),比頁(yè)級(jí)或表級(jí)鎖定速度慢,因?yàn)槟惚仨毇@取更多的鎖。

如果你在大部分?jǐn)?shù)據(jù)上經(jīng)常進(jìn)行GROUP BY操作或者必須經(jīng)常掃描整個(gè)表,比其它鎖定明顯慢很多。

用高級(jí)別鎖定,通過(guò)支持不同的類型鎖定,你也可以很容易地調(diào)節(jié)應(yīng)用程序,因?yàn)槠滏i成本小于行級(jí)鎖定。

MySQL觸發(fā)器簡(jiǎn)單實(shí)例

CREATE TRIGGER <觸發(fā)器名稱> ?–觸發(fā)器必須有名字,最多64個(gè)字符,可能后面會(huì)附有分隔符.它和MySQL中其他對(duì)象的命名方式基本相象.

{ BEFORE | AFTER } ?–觸發(fā)器有執(zhí)行的時(shí)間設(shè)置:可以設(shè)置為事件發(fā)生前或后。

{ INSERT | UPDATE | DELETE } ?–同樣也能設(shè)定觸發(fā)的事件:它們可以在執(zhí)行insert、update或delete的過(guò)程中觸發(fā)。

ON <表名稱> ?–觸發(fā)器是屬于某一個(gè)表的:當(dāng)在這個(gè)表上執(zhí)行插入、 更新或刪除操作的時(shí)候就導(dǎo)致觸發(fā)器的激活. 我們不能給同一張表的同一個(gè)事件安排兩個(gè)觸發(fā)器。

FOR EACH ROW ?–觸發(fā)器的執(zhí)行間隔:FOR EACH ROW子句通知觸發(fā)器 每隔一行執(zhí)行一次動(dòng)作,而不是對(duì)整個(gè)表執(zhí)行一次。

<觸發(fā)器SQL語(yǔ)句> ?–觸發(fā)器包含所要觸發(fā)的SQL語(yǔ)句:這里的語(yǔ)句可以是任何合法的語(yǔ)句, 包括復(fù)合語(yǔ)句,但是這里的語(yǔ)句受的限制和函數(shù)的一樣。

什么是存儲(chǔ)過(guò)程

簡(jiǎn)單的說(shuō),就是一組SQL語(yǔ)句集,功能強(qiáng)大,可以實(shí)現(xiàn)一些比較復(fù)雜的邏輯功能,類似于JAVA語(yǔ)言中的方法;

ps:存儲(chǔ)過(guò)程跟觸發(fā)器有點(diǎn)類似,都是一組SQL集,但是存儲(chǔ)過(guò)程是主動(dòng)調(diào)用的,且功能比觸發(fā)器更加強(qiáng)大,觸發(fā)器是某件事觸發(fā)后自動(dòng)調(diào)用;

有哪些特性

有輸入輸出參數(shù),可以聲明變量,有if/else, case,while等控制語(yǔ)句,通過(guò)編寫存儲(chǔ)過(guò)程,可以實(shí)現(xiàn)復(fù)雜的邏輯功能;

函數(shù)的普遍特性:模塊化,封裝,代碼復(fù)用;

速度快,只有首次執(zhí)行需經(jīng)過(guò)編譯和優(yōu)化步驟,后續(xù)被調(diào)用可以直接執(zhí)行,省去以上步驟;

DROP PROCEDURE IF EXISTS `proc_adder`;

DELIMITER ;;

CREATE DEFINER=`root`@`localhost` PROCEDURE `proc_adder`(IN a int, IN b int, OUT sum int)

BEGIN

#Routine body goes here…

DECLARE c int;

if a is null then set a = 0;

end if;

if b is null then set b = 0;

end if;

set sum ?= a + b;

END

;;

DELIMITER ;

set @b=5;

call proc_adder(0,@b,@s);

SELECT @s as sum;

create table tab2(

tab2_id varchar(11)

);

DROP TRIGGER if EXISTS t_ai_on_tab1;

create TRAILING t_ai_on_tab1

AFTER INSERT ON tab1

for EACH ROW

BEGIN

INSERT INTO tab2(tab2_id) values(new.tab1_id);

end;

INSERT INTO tab1(tab1_id) values(‘0001’);

SELECT * FROM tab2;

MySQL優(yōu)化

開啟查詢緩存,優(yōu)化查詢

explain你的select查詢,這可以幫你分析你的查詢語(yǔ)句或是表結(jié)構(gòu)的性能瓶頸。EXPLAIN 的查詢結(jié)果還會(huì)告訴你你的索引主鍵被如何利用的,你的數(shù)據(jù)表是如何被搜索和排序的

當(dāng)只要一行數(shù)據(jù)時(shí)使用limit 1,MySQL數(shù)據(jù)庫(kù)引擎會(huì)在找到一條數(shù)據(jù)后停止搜索,而不是繼續(xù)往后查少下一條符合記錄的數(shù)據(jù)

為搜索字段建索引

使用 ENUM 而不是 VARCHAR,如果你有一個(gè)字段,比如“性別”,“國(guó)家”,“民族”,“狀態(tài)”或“部門”,你知道這些字段的取值是有限而且固定的,那么,你應(yīng)該使用 ENUM 而不是VARCHAR。

Prepared StatementsPrepared Statements很像存儲(chǔ)過(guò)程,是一種運(yùn)行在后臺(tái)的SQL語(yǔ)句集合,我們可以從使用 prepared statements 獲得很多好處,無(wú)論是性能問(wèn)題還是安全問(wèn)題。Prepared Statements 可以檢查一些你綁定好的變量,這樣可以保護(hù)你的程序不會(huì)受到“SQL注入式”攻擊

垂直分表

選擇正確的存儲(chǔ)引擎

key和index的區(qū)別

key 是數(shù)據(jù)庫(kù)的物理結(jié)構(gòu),它包含兩層意義和作用,一是約束(偏重于約束和規(guī)范數(shù)據(jù)庫(kù)的結(jié)構(gòu)完整性),二是索引(輔助查詢用的)。包括primary key, unique key, foreign key 等

index是數(shù)據(jù)庫(kù)的物理結(jié)構(gòu),它只是輔助查詢的,它創(chuàng)建時(shí)會(huì)在另外的表空間(mysql中的innodb表空間)以一個(gè)類似目錄的結(jié)構(gòu)存儲(chǔ)。索引要分類的話,分為前綴索引、全文本索引等;

Mysql 中 MyISAM 和 InnoDB 的區(qū)別有哪些?

區(qū)別:

InnoDB支持事務(wù),MyISAM不支持,對(duì)于InnoDB每一條SQL語(yǔ)言都默認(rèn)封裝成事務(wù),自動(dòng)提交,這樣會(huì)影響速度,所以最好把多條SQL語(yǔ)言放在begin和commit之間,組成一個(gè)事務(wù);

InnoDB支持外鍵,而MyISAM不支持。對(duì)一個(gè)包含外鍵的InnoDB表轉(zhuǎn)為MYISAM會(huì)失敗;

InnoDB是聚集索引,數(shù)據(jù)文件是和索引綁在一起的,必須要有主鍵,通過(guò)主鍵索引效率很高。但是輔助索引需要兩次查詢,先查詢到主鍵,然后再通過(guò)主鍵查詢到數(shù)據(jù)。因此,主鍵不應(yīng)該過(guò)大,因?yàn)橹麈I太大,其他索引也都會(huì)很大。而MyISAM是非聚集索引,數(shù)據(jù)文件是分離的,索引保存的是數(shù)據(jù)文件的指針。主鍵索引和輔助索引是獨(dú)立的。

InnoDB不保存表的具體行數(shù),執(zhí)行select count(*) from table時(shí)需要全表掃描。而MyISAM用一個(gè)變量保存了整個(gè)表的行數(shù),執(zhí)行上述語(yǔ)句時(shí)只需要讀出該變量即可,速度很快;

Innodb不支持全文索引,而MyISAM支持全文索引,查詢效率上MyISAM要高;

如何選擇:

是否要支持事務(wù),如果要請(qǐng)選擇innodb,如果不需要可以考慮MyISAM;

如果表中絕大多數(shù)都只是讀查詢,可以考慮MyISAM,如果既有讀寫也挺頻繁,請(qǐng)使用InnoDB。

系統(tǒng)奔潰后,MyISAM恢復(fù)起來(lái)更困難,能否接受;

MySQL5.5版本開始Innodb已經(jīng)成為Mysql的默認(rèn)引擎(之前是MyISAM),說(shuō)明其優(yōu)勢(shì)是有目共睹的,如果你不知道用什么,那就用InnoDB,至少不會(huì)差。

數(shù)據(jù)庫(kù)表創(chuàng)建注意事項(xiàng)

一、字段名及字段配制合理性

剔除關(guān)系不密切的字段

字段命名要有規(guī)則及相對(duì)應(yīng)的含義(不要一部分英文,一部分拼音,還有類似a.b.c這樣不明含義的字段)

字段命名盡量不要使用縮寫(大多數(shù)縮寫都不能明確字段含義)

字段不要大小寫混用(想要具有可讀性,多個(gè)英文單詞可使用下劃線形式連接)

字段名不要使用保留字或者關(guān)鍵字

保持字段名和類型的一致性

慎重選擇數(shù)字類型

給文本字段留足余量

二、系統(tǒng)特殊字段處理及建成后建議

添加刪除標(biāo)記(例如操作人、刪除時(shí)間)

建立版本機(jī)制

三、表結(jié)構(gòu)合理性配置

多型字段的處理,就是表中是否存在字段能夠分解成更小獨(dú)立的幾部分(例如:人可以分為男人和女人)

多值字段的處理,可以將表分為三張表,這樣使得檢索和排序更加有調(diào)理,且保證數(shù)據(jù)的完整性!

四、其它建議

對(duì)于大數(shù)據(jù)字段,獨(dú)立表進(jìn)行存儲(chǔ),以便影響性能(例如:簡(jiǎn)介字段)

使用varchar類型代替char,因?yàn)関archar會(huì)動(dòng)態(tài)分配長(zhǎng)度,char指定長(zhǎng)度是固定的。

給表創(chuàng)建主鍵,對(duì)于沒(méi)有主鍵的表,在查詢和索引定義上有一定的影響。

避免表字段運(yùn)行為null,建議設(shè)置默認(rèn)值(例如:int類型設(shè)置默認(rèn)值為0)在索引查詢上,效率立顯!

建立索引,最好建立在唯一和非空的字段上,建立太多的索引對(duì)后期插入、更新都存在一定的影響(考慮實(shí)際情況來(lái)創(chuàng)建)。

Redis

Redis單線程問(wèn)題

單線程指的是網(wǎng)絡(luò)請(qǐng)求模塊使用了一個(gè)線程(所以不需考慮并發(fā)安全性),即一個(gè)線程處理所有網(wǎng)絡(luò)請(qǐng)求,其他模塊仍用了多個(gè)線程。

為什么說(shuō)Redis能夠快速執(zhí)行

絕大部分請(qǐng)求是純粹的內(nèi)存操作(非常快速)

采用單線程,避免了不必要的上下文切換和競(jìng)爭(zhēng)條件

非阻塞IO – IO多路復(fù)用

Redis的內(nèi)部實(shí)現(xiàn)

內(nèi)部實(shí)現(xiàn)采用epoll,采用了epoll+自己實(shí)現(xiàn)的簡(jiǎn)單的事件框架。epoll中的讀、寫、關(guān)閉、連接都轉(zhuǎn)化成了事件,然后利用epoll的多路復(fù)用特性,不在io上浪費(fèi)一點(diǎn)時(shí)間 這3個(gè)條件不是相互獨(dú)立的,特別是第一條,如果請(qǐng)求都是耗時(shí)的,采用單線程吞吐量及性能很差。redis為特殊的場(chǎng)景選擇了合適的技術(shù)方案。

Redis關(guān)于線程安全問(wèn)題

redis實(shí)際上是采用了線程封閉的觀念,把任務(wù)封閉在一個(gè)線程,自然避免了線程安全問(wèn)題,不過(guò)對(duì)于需要依賴多個(gè)redis操作的復(fù)合操作來(lái)說(shuō),依然需要鎖,而且有可能是分布式鎖。

使用Redis有哪些好處?

速度快,因?yàn)閿?shù)據(jù)存在內(nèi)存中,類似于HashMap,HashMap的優(yōu)勢(shì)就是查找和操作的時(shí)間復(fù)雜度都是O(1)

支持豐富數(shù)據(jù)類型,支持string,list,set,sorted set,hash

支持事務(wù),操作都是原子性,所謂的原子性就是對(duì)數(shù)據(jù)的更改要么全部執(zhí)行,要么全部不執(zhí)行

豐富的特性:可用于緩存,消息,按key設(shè)置過(guò)期時(shí)間,過(guò)期后將會(huì)自動(dòng)刪除

redis相比memcached有哪些優(yōu)勢(shì)?

memcached所有的值均是簡(jiǎn)單的字符串,redis作為其替代者,支持更為豐富的數(shù)據(jù)類型

redis的速度比memcached快很多

redis可以持久化其數(shù)據(jù)

Redis支持?jǐn)?shù)據(jù)的備份,即master-slave模式的數(shù)據(jù)備份。

使用底層模型不同,它們之間底層實(shí)現(xiàn)方式 以及與客戶端之間通信的應(yīng)用協(xié)議不一樣。Redis直接自己構(gòu)建了VM 機(jī)制 ,因?yàn)橐话愕南到y(tǒng)調(diào)用系統(tǒng)函數(shù)的話,會(huì)浪費(fèi)一定的時(shí)間去移動(dòng)和請(qǐng)求。

value大小:redis最大可以達(dá)到1GB,而memcache只有1MB

Redis主從復(fù)制

過(guò)程原理:

當(dāng)從庫(kù)和主庫(kù)建立MS關(guān)系后,會(huì)向主數(shù)據(jù)庫(kù)發(fā)送SYNC命令

主庫(kù)接收到SYNC命令后會(huì)開始在后臺(tái)保存快照(RDB持久化過(guò)程),并將期間接收到的寫命令緩存起來(lái)

當(dāng)快照完成后,主Redis會(huì)將快照文件和所有緩存的寫命令發(fā)送給從Redis

從Redis接收到后,會(huì)載入快照文件并且執(zhí)行收到的緩存的命令

之后,主Redis每當(dāng)接收到寫命令時(shí)就會(huì)將命令發(fā)送從Redis,從而保證數(shù)據(jù)的一致

缺點(diǎn):所有的slave節(jié)點(diǎn)數(shù)據(jù)的復(fù)制和同步都由master節(jié)點(diǎn)來(lái)處理,會(huì)照成master節(jié)點(diǎn)壓力太大,使用主從從結(jié)構(gòu)來(lái)解決

Redis兩種持久化方式的優(yōu)缺點(diǎn)

RDB 持久化可以在指定的時(shí)間間隔內(nèi)生成數(shù)據(jù)集的時(shí)間點(diǎn)快照(point-in-time snapshot)

AOF 持久化記錄服務(wù)器執(zhí)行的所有寫操作命令,并在服務(wù)器啟動(dòng)時(shí),通過(guò)重新執(zhí)行這些命令來(lái)還原數(shù)據(jù)集。

Redis 還可以同時(shí)使用 AOF 持久化和 RDB 持久化。當(dāng)redis重啟時(shí),它會(huì)有限使用AOF文件來(lái)還原數(shù)據(jù)集,因?yàn)锳OF文件保存的數(shù)據(jù)集通常比RDB文件所保存的數(shù)據(jù)集更加完整

RDB的優(yōu)點(diǎn):

RDB 是一個(gè)非常緊湊(compact)的文件,它保存了 Redis 在某個(gè)時(shí)間點(diǎn)上的數(shù)據(jù)集。 這種文件非常適合用于進(jìn)行備份: 比如說(shuō),你可以在最近的 24 小時(shí)內(nèi),每小時(shí)備份一次 RDB 文件,并且在每個(gè)月的每一天,也備份一個(gè) RDB 文件。 這樣的話,即使遇上問(wèn)題,也可以隨時(shí)將數(shù)據(jù)集還原到不同的版本。

RDB 非常適用于災(zāi)難恢復(fù)(disaster recovery):它只有一個(gè)文件,并且內(nèi)容都非常緊湊,可以(在加密后)將它傳送到別的數(shù)據(jù)中心,或者亞馬遜 S3 中。

RDB 可以最大化 Redis 的性能:父進(jìn)程在保存 RDB 文件時(shí)唯一要做的就是 fork 出一個(gè)子進(jìn)程,然后這個(gè)子進(jìn)程就會(huì)處理接下來(lái)的所有保存工作,父進(jìn)程無(wú)須執(zhí)行任何磁盤 I/O 操作。

RDB 在恢復(fù)大數(shù)據(jù)集時(shí)的速度比 AOF 的恢復(fù)速度要快

Redis常見的性能問(wèn)題都有哪些?如何解決?

Master寫內(nèi)存快照,save命令調(diào)度rdbSave函數(shù),會(huì)阻塞主線程的工作,當(dāng)快照比較大時(shí)對(duì)性能影響是非常大的,會(huì)間斷性暫停服務(wù),所以Master最好不要寫內(nèi)存快照。

Master AOF持久化,如果不重寫AOF文件,這個(gè)持久化方式對(duì)性能的影響是最小的,但是AOF文件會(huì)不斷增大,AOF文件過(guò)大會(huì)影響Master重啟的恢復(fù)速度。Master最好不要做任何持久化工作,包括內(nèi)存快照和AOF日志文件,特別是不要啟用內(nèi)存快照做持久化,如果數(shù)據(jù)比較關(guān)鍵,某個(gè)Slave開啟AOF備份數(shù)據(jù),策略為每秒同步一次。

Master調(diào)用BGREWRITEAOF重寫AOF文件,AOF在重寫的時(shí)候會(huì)占大量的CPU和內(nèi)存資源,導(dǎo)致服務(wù)load過(guò)高,出現(xiàn)短暫服務(wù)暫停現(xiàn)象。

Redis主從復(fù)制的性能問(wèn)題,為了主從復(fù)制的速度和連接的穩(wěn)定性,Slave和Master最好在同一個(gè)局域網(wǎng)內(nèi)

Redis提供6種數(shù)據(jù)淘汰策略

volatile-lru:從已設(shè)置過(guò)期時(shí)間的數(shù)據(jù)集(server.db[i].expires)中挑選最近最少使用的數(shù)據(jù)淘汰

volatile-ttl:從已設(shè)置過(guò)期時(shí)間的數(shù)據(jù)集(server.db[i].expires)中挑選將要過(guò)期的數(shù)據(jù)淘汰

volatile-random:從已設(shè)置過(guò)期時(shí)間的數(shù)據(jù)集(server.db[i].expires)中任意選擇數(shù)據(jù)淘汰

allkeys-lru:從數(shù)據(jù)集(server.db[i].dict)中挑選最近最少使用的數(shù)據(jù)淘汰

allkeys-random:從數(shù)據(jù)集(server.db[i].dict)中任意選擇數(shù)據(jù)淘汰

no-enviction(驅(qū)逐):禁止驅(qū)逐數(shù)據(jù)