一個(gè)表只能有一個(gè)主鍵索引,一個(gè)主鍵索引可以多個(gè)字段

面試的時(shí)候肯定會(huì)問這一個(gè)問題，mysql為什么會(huì)選擇b+樹作為索引呢？而不選擇其他索引，例如b樹？hash？

創(chuàng)新互聯(lián)服務(wù)項(xiàng)目包括肅州網(wǎng)站建設(shè)、肅州網(wǎng)站制作、肅州網(wǎng)頁制作以及肅州網(wǎng)絡(luò)營(yíng)銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢(shì)、行業(yè)經(jīng)驗(yàn)、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機(jī)構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，肅州網(wǎng)站推廣取得了明顯的社會(huì)效益與經(jīng)濟(jì)效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到肅州省份的部分城市，未來相信會(huì)繼續(xù)擴(kuò)大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！

下面說的磁盤IO是指數(shù)據(jù)從硬盤加載到內(nèi)存中的操作

hash索引的話，不支持范圍查詢，因?yàn)閔ash就是一個(gè)鍵對(duì)應(yīng)一個(gè)值的，沒辦法范圍查詢

二叉樹的話，它的特點(diǎn)就是左子樹小于根節(jié)點(diǎn)小于右子樹，如果根節(jié)點(diǎn)取值有問題的話，有可能會(huì)退化成鏈表，就是樹不分叉了，樹一直往左或者一直往右，這樣就不能折半查找從而減少IO次數(shù)了，不支持范圍查詢，要是范圍查詢的話，每次都要從根部遍歷，樹也太高了，樹越高，IO操作越頻繁，浪費(fèi)資源

平衡二叉樹的話，它就沒有了二叉樹的這種退化成鏈表的缺點(diǎn)，因?yàn)樗笥易庸?jié)點(diǎn)最多相差1層，可是他也不支持范圍查找這一點(diǎn)和二叉樹的問題一樣

b樹的話，和二叉樹比起來樹是很矮胖，IO操作減少了，是個(gè)多叉樹，它每個(gè)節(jié)點(diǎn)都存了對(duì)應(yīng)的行數(shù)據(jù)，可是如果這一行的數(shù)據(jù)的列不斷的增加，那么這一頁存儲(chǔ)的節(jié)點(diǎn)就會(huì)變少，因?yàn)樗嫉目臻g不斷的變大，樹也會(huì)越來越高，增加IO操作次數(shù)，同時(shí)是也不支持范圍查找。要是相同大小的空間可以存很多的節(jié)點(diǎn)數(shù)據(jù)的話就更好了，所以就有了下面的b+樹

b+樹 它非葉子節(jié)點(diǎn)只存索引的數(shù)據(jù)，不存整行數(shù)據(jù)，但是葉子節(jié)點(diǎn)是冗余的，冗余了非葉子節(jié)點(diǎn)，葉子節(jié)點(diǎn)還都用雙向鏈表鏈接起來，這樣有助于順序查找，b+樹和b樹比起來，更加矮胖，磁盤IO次數(shù)更少

二、 mysql中索引類型

聚簇索引與非聚簇索引

我們可以簡(jiǎn)單的理解為 聚簇索引就是主鍵索引，非聚簇索引就是普通索引

本質(zhì)的區(qū)別是

聚簇索引的葉子節(jié)點(diǎn)存儲(chǔ)的是整行數(shù)據(jù)

innodb是通過主鍵來實(shí)現(xiàn)聚簇索引的，如果沒有主鍵的話，那么他就會(huì)選擇一個(gè)唯一非空的索引來實(shí)現(xiàn)，如果再?zèng)]有的話，他就會(huì)隱式生成一個(gè)主鍵來實(shí)現(xiàn)聚簇索引

非聚簇索引存儲(chǔ)的是索引值和主鍵值

普通索引 一張表中可以有多個(gè)普通索引，隨便一個(gè)字段都可以建立的索引，我們平常建立的索引大部分都是普通索引

聯(lián)合索引 好幾個(gè)字段聯(lián)合起來建立的索引

唯一索引 業(yè)務(wù)中唯一的字段適合建立唯一索引，一個(gè)表中可以有多個(gè)唯一索引

主鍵索引 和唯一索引一樣，主鍵索引也是唯一的，不同的就是，一個(gè)表只能有一個(gè)主鍵索引

三、關(guān)于索引的sql

創(chuàng)建主鍵索引

ALTER TABLE test add PRIMARY KEY (id)

創(chuàng)建唯一索引

ALTER TABLE test add UNIQUE idx_id_card(id_card)

創(chuàng)建普通索引

ALTER TABLE test add INDEX idx_name(name)

創(chuàng)建聯(lián)合索引

ALTER TABLE test add INDEX idx_age_name(age,name)

修改索引名稱 ：先刪除再添加

刪除索引 （兩種方式）

mysql 為什么不用二叉樹查找

兩者的算法思路其實(shí)很像：比中間的小就在剩下的左邊，大就在剩下的右邊找 但是： 二叉樹查找一般習(xí)慣是在鏈?zhǔn)酱鎯?chǔ)上進(jìn)行，為一個(gè)樹形結(jié)構(gòu) 二分查找一定在順序存儲(chǔ)上進(jìn)行

mysql索引采用什么數(shù)據(jù)結(jié)構(gòu)

文就是對(duì)這兩種數(shù)據(jù)結(jié)構(gòu)做簡(jiǎn)單的介紹。

1. B-Tree

B-Tree不是“B減樹”，而是“B樹”。

這里參考了嚴(yán)蔚敏《數(shù)據(jù)結(jié)構(gòu)》對(duì)B-Tree的定義：

一棵m階的B-Tree,或者為空樹，或者滿足下列特性：

1.樹中每個(gè)結(jié)點(diǎn)至多有m棵子樹；

2.若根結(jié)點(diǎn)不是葉子結(jié)點(diǎn)，則至少有兩棵子樹；

3.除根節(jié)點(diǎn)之外的所有非終端結(jié)點(diǎn)至少有[m/2]棵子樹；

4.所有非終端結(jié)點(diǎn)中包含下列信息數(shù)據(jù):

(n,A0,K1,A1,K2,A2……Kn,An)

其中，n為關(guān)鍵字的數(shù)目，K(i)為關(guān)鍵字，且K(i) K(i+1), Ai為指向子樹根結(jié)點(diǎn)的指針，且指針A(i-1)所指子樹中所有結(jié)點(diǎn)的關(guān)鍵字均小于Ki，Ai所指子樹中所有結(jié)點(diǎn)的關(guān)鍵字均大于Ki；

5.所有葉子結(jié)點(diǎn)都出現(xiàn)在同一層次上；

下面通過一個(gè)例子解釋一下B-Tree的查找過程。

這是一棵4階的B-Tree，深度為4。

假如在該圖中查找關(guān)鍵字47，首先從根結(jié)點(diǎn)開始，根據(jù)根結(jié)點(diǎn)指針t找到*a結(jié)點(diǎn)，因?yàn)?7大于 *a 結(jié)點(diǎn)的關(guān)鍵字35，所以會(huì)去A1指針指向的 *c結(jié)點(diǎn)繼續(xù)尋找，因?yàn)?*c的關(guān)鍵字 43 要查找的47 *c結(jié)點(diǎn)的關(guān)鍵字78，所以去 *c結(jié)點(diǎn)A1指針指向的 *g結(jié)點(diǎn)去尋找，結(jié)果在 *g結(jié)點(diǎn)中找到了關(guān)鍵字47，查找成功。

2. B+Tree

不同的存儲(chǔ)引擎可能使用不同的數(shù)據(jù)結(jié)構(gòu)存儲(chǔ)，InnoDB使用的是B+Tree；那什么是B+Tree呢？

B+Tree是應(yīng)文件系統(tǒng)所需而出的一種B-Tree的變型樹，一棵m階的B+樹和m階的B-樹的差異在于:

1.有n棵子樹的結(jié)點(diǎn)中含有n個(gè)關(guān)鍵字；

2.所有的葉子結(jié)點(diǎn)中包含了全部關(guān)鍵字的信息，及指向含這些關(guān)鍵字的記錄的指針，且葉子結(jié)點(diǎn)本身依關(guān)鍵字的大小自小而大順序鏈接；

3.所有的非終端結(jié)點(diǎn)可以看成是索引部分，結(jié)點(diǎn)中僅含有其子樹(根結(jié)點(diǎn))中的最大（或最小）關(guān)鍵字；

還是通過一個(gè)例子來說明。

這個(gè)例子中，所有非終端結(jié)點(diǎn)僅含有子樹中最大的關(guān)鍵字。

因?yàn)槿~子節(jié)點(diǎn)本身依據(jù)關(guān)鍵字的大小自小而大順序鏈接，所以可以從最小關(guān)鍵字起順序查找。也可以從根結(jié)點(diǎn)開始，進(jìn)行隨機(jī)查找。

在B+樹中隨機(jī)差找和在B-樹中類似，以上圖為例。假設(shè)要查找關(guān)鍵字51，現(xiàn)在根節(jié)點(diǎn)中比較，發(fā)現(xiàn)5159，因?yàn)檫@里使用的是非終端結(jié)點(diǎn)的關(guān)鍵字是子樹中最大的關(guān)鍵字，所以進(jìn)入最大值為59的子結(jié)點(diǎn)(15\44\59)中查找，同理，因?yàn)?45159，所以進(jìn)入P3指向的結(jié)點(diǎn)(51\59)中查找，然后命中關(guān)鍵字51，因?yàn)榇私Y(jié)點(diǎn)(51\59)是葉子結(jié)點(diǎn)，所以查找終止，該結(jié)點(diǎn)包含指向數(shù)據(jù)的指針。

3.索引如何在B+Tree中組織數(shù)據(jù)存儲(chǔ)

假設(shè)有如下表:

對(duì)于表中的每一行數(shù)據(jù)，索引中包含了last_name、first_name和dob列的值，下圖展示索引是如何組織數(shù)據(jù)存儲(chǔ)的:

索引對(duì)多個(gè)值進(jìn)行排序的依據(jù)是定義索引時(shí)列的順序。

(Allen Cuba 1960-01-01)結(jié)點(diǎn)左側(cè)的指針指向[?,Allen Cuba 1960-01-01)的葉子頁，(Allen Cuba 1960-01-01)和(Astaire,Angelina,1980-03-04)之間的指針指向[Allen Cuba 1960-01-01,Astaire Angelina 1980-03-04)的葉子頁，以此類推?？傊總€(gè)指針指向的結(jié)點(diǎn)中的最小值就是該指針左側(cè)的的值。

這種存儲(chǔ)結(jié)構(gòu)也說明了在定義多個(gè)列組成的多列索引中，為什么需要把重復(fù)率最低的列放到最左側(cè)，因?yàn)檫@會(huì)減少比較的次數(shù)，查找起來更加高效。

4.索引為什么選用B樹這種數(shù)據(jù)結(jié)構(gòu)？

因?yàn)槭褂肂樹查找時(shí)，所用的磁盤IO操作次數(shù)比平衡二叉樹更少，效率也更高。

為什么使用B樹查找所用的磁盤IO操作次數(shù)比平衡二叉樹更少？

大規(guī)模數(shù)據(jù)存儲(chǔ)中，樹節(jié)點(diǎn)存儲(chǔ)的元素?cái)?shù)量是有限的（如果元素?cái)?shù)量非常多的話，查找就退化成節(jié)點(diǎn)內(nèi)部的線性查找了），這樣導(dǎo)致二叉查找樹結(jié)構(gòu)由于樹的高度過大而造成磁盤I/O讀寫過于頻繁，進(jìn)而導(dǎo)致查詢效率低下。那么我們就需要減少樹的高度以提高查找效率。而平衡多路查找樹結(jié)構(gòu)B樹就滿足這樣的要求。B樹的各種操作能使B樹保持較低的高度，從而達(dá)到有效減少磁盤IO操作次數(shù)。

mysql如何創(chuàng)建二叉樹

在二叉樹中有一種平衡二叉樹，通過平衡算法可以讓二叉樹兩邊的節(jié)點(diǎn)平均分布，這樣就能讓所有的索引查找都在一個(gè)近似的時(shí)間內(nèi)完成。而MySQL這類數(shù)據(jù)庫(kù)采用了二叉樹的升級(jí)版B+Tree的形式，每個(gè)節(jié)點(diǎn)有三個(gè)支葉，不過其算法原理仍然是平衡樹的原理。

數(shù)據(jù)庫(kù)怎么不用*

MySQL(和PHP調(diào)配之***組合)的授權(quán)方法

MySQL(和PHP調(diào)配之***組合)選用兩層授權(quán)(Dual Licensed)，它們是GPL和MySQL數(shù)據(jù)庫(kù)(和PHP調(diào)配之***組合) AB擬定的商業(yè)答應(yīng)協(xié)議。

假如你在一個(gè)遵從GPL的自在(開源)項(xiàng)目中運(yùn)用MySQL(和PHP調(diào)配之***組合)，那么你能夠遵從GPL協(xié)議運(yùn)用MySQL(和PHP調(diào)配之***組合)。

可是，假如你的項(xiàng)目不是在GPL協(xié)議下的話，你有必要為運(yùn)用MySQL(和PHP調(diào)配之***組合)來付出答應(yīng)費(fèi)用，或許你或許由于這個(gè)要素而將你的項(xiàng)目改為遵從GPL，那么你需求處理因而帶來的更多的支撐作業(yè)，這有或許會(huì)帶來本錢上的進(jìn)步。在這種情況下，一些軟件發(fā)行商或許傾向于挑選其他開源數(shù)據(jù)庫(kù)，例如遵從BSD授權(quán)的PostgreSQL。

2、產(chǎn)品老練性

到2009年，甲骨文的數(shù)據(jù)庫(kù)Oracle(大型網(wǎng)站數(shù)據(jù)庫(kù)渠道)現(xiàn)已誕生了30周年，而MySQL(和PHP調(diào)配之***組合)卻連它的一半時(shí)刻都沒有。微軟的sql server(WINDOWS渠道上強(qiáng)壯的數(shù)據(jù)庫(kù)渠道)只是比MySQL(和PHP調(diào)配之***組合)大兩年，可是sql server(WINDOWS渠道上強(qiáng)壯的數(shù)據(jù)庫(kù)渠道)的發(fā)布是建立在Sybase的基礎(chǔ)上，那時(shí)分Sybase現(xiàn)已誕生了6年的時(shí)刻。

至于其他值得重視的開源數(shù)據(jù)庫(kù)，PostgreSQL將在2009年到達(dá)20歲的生日。雖然MySQL數(shù)據(jù)庫(kù)(和PHP調(diào)配之***組合)并不是市場(chǎng)上最年青的數(shù)據(jù)庫(kù)，可是卻有更多老練的數(shù)據(jù)庫(kù)可供咱們挑選。

當(dāng)然，或許這并不是咱們回絕MySQL(和PHP調(diào)配之***組合)的一個(gè)有說服力的理由，可是關(guān)于一些比較保守的IT司理來說，在為一些要害事務(wù)挑選渠道的時(shí)分，渠道的老練性卻是有必要要考慮的一個(gè)要素，在這一點(diǎn)上，MySQL(和PHP調(diào)配之***組合)無疑毫無優(yōu)勢(shì)。

3、功用設(shè)置老練性

要想在MySQL(和PHP調(diào)配之***組合)與其他數(shù)據(jù)庫(kù)之間進(jìn)行一個(gè)八面玲瓏的功用設(shè)置比照，并不是一件簡(jiǎn)單的工作。跟著新軟件版其他發(fā)布或一些補(bǔ)丁的推出，從前的功用列表或許會(huì)敏捷變得過期了。并且，有些功用對(duì)有的使用程序非常重要，可是對(duì)其他使用程序則不必定。

有的時(shí)分，一些缺失的功用能夠通過其他方法來完成，例如，在MySQL(和PHP調(diào)配之***組合) 4.1曾經(jīng)，你能夠通過運(yùn)

大文件導(dǎo)入 MYSQL，如何最快速

一般的數(shù)據(jù)備份用 ：mysql路徑+bin/mysqldump -u 用戶名 -p 數(shù)據(jù)庫(kù)名 導(dǎo)出的文件名

數(shù)據(jù)還原是：到mysql命令行下面，用：source ? 文件名;的方法。

但是這種方法對(duì)大數(shù)據(jù)量的表進(jìn)行操作就非常慢。因?yàn)樗粌H導(dǎo)出了數(shù)據(jù)還導(dǎo)出了表結(jié)構(gòu)。

在針對(duì)大數(shù)據(jù)量的表時(shí)，我們可以用infile和 outfile來操作。

outfile導(dǎo)出數(shù)據(jù)庫(kù)數(shù)據(jù)的用法：

下圖我們可以看到6百多萬數(shù)據(jù)35秒就搞定了：

下面我們看看infile的語法：

在infile導(dǎo)入數(shù)據(jù)的時(shí)候，我們還可以做一些優(yōu)化。我們可以用

alter table table_name disable keys ? 關(guān)閉普通索引。等數(shù)據(jù)導(dǎo)入玩，再用：

alter table table_name enable keys ? ?來開啟普通索引。這樣就不會(huì)邊導(dǎo)入數(shù)據(jù)，邊整理索引的二叉樹兒影響導(dǎo)數(shù)據(jù)的效率。

如果可以保證 數(shù)據(jù)的正確性，我們可以將表的唯一索引也關(guān)閉，之后再開啟,不是每條數(shù)據(jù)就算是唯一的他都要去檢測(cè)一遍。命令：

set unique_checks=0;?#關(guān)閉唯一校驗(yàn)

set unique_checks=1;#開啟唯一校驗(yàn)

如果是InnoDB存儲(chǔ)引擎，我們還可以set auto commit=0;關(guān)閉自動(dòng)提交，來提高效率。InnoDB是按主鍵的順序保存的，我們將其主鍵順序排列也可以提高效率。

下面我們對(duì)myisam引擎的表做個(gè)測(cè)試，我們先不關(guān)索引，導(dǎo)入數(shù)據(jù)(用了近4分鐘)：

然后我們先把索引關(guān)閉試試(只用了一分鐘多一點(diǎn)，快了不少啊！摸摸大！)：