盡量使用覆蓋索引，減少select *。 那么什么是覆蓋索引呢？ 覆蓋索引是指 查詢使用了索引，并 且需要返回的列，在該索引中已經(jīng)全部能夠找到 。
延壽網(wǎng)站建設(shè)公司創(chuàng)新互聯(lián),延壽網(wǎng)站設(shè)計制作，有大型網(wǎng)站制作公司豐富經(jīng)驗。已為延壽數(shù)千家提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\外貿(mào)網(wǎng)站建設(shè)要多少錢，請找那個售后服務(wù)好的延壽做網(wǎng)站的公司定做！
現(xiàn)在有一張用戶表tb_user;
索引情況：
接下來，我們來看一組SQL的執(zhí)行計劃，看看執(zhí)行計劃的差別，然后再來具體做一個解析。
Using where; Using Index：查找使用了索引，但是需要的數(shù)據(jù)都在索引列中能找到，所以不需 要回表查詢數(shù)據(jù)
Using index condition：查找使用了索引，但是需要回表查詢數(shù)據(jù)
因為，在tb_user表中有一個聯(lián)合索引 idx_user_pro_age_sta，該索引關(guān)聯(lián)了三個字段 profession、age、status，而這個索引也是一個二級索引，所以葉子節(jié)點下面掛的是這一行的主 鍵id。 所以當(dāng)我們查詢返回的數(shù)據(jù)在 id、profession、age、status 之中，則直接走二級索引 直接返回數(shù)據(jù)了。 如果超出這個范圍，就需要拿到主鍵id，再去掃描聚集索引，再獲取額外的數(shù)據(jù)了，這個過程就是回表。 而我們?nèi)绻恢笔褂胹elect * 查詢返回所有字段值，很容易就會造成回表 查詢（除非是根據(jù)主鍵查詢，此時只會掃描聚集索引）。
為了大家更清楚的理解，什么是覆蓋索引，什么是回表查詢，我們一起再來看下面的這組SQL的執(zhí)行過 程。
id是主鍵，是一個聚集索引。 name字段建立了普通索引，是一個二級索引（輔助索引）。
B. 執(zhí)行SQL : select * from tb_user where id = 2;
根據(jù)id查詢，直接走聚集索引查詢，一次索引掃描，直接返回數(shù)據(jù)，性能高。
C. 執(zhí)行SQL：selet id,name from tb_user where name = 'Arm';
雖然是根據(jù)name字段查詢，查詢二級索引，但是由于查詢返回在字段為 id，name，在name的二級索 引中，這兩個值都是可以直接獲取到的，因為覆蓋索引，所以不需要回表查詢，性能高。
D. 執(zhí)行SQL：selet id,name,gender from tb_user where name = 'Arm';
由于在name的二級索引中，不包含gender，所以，需要兩次索引掃描，也就是需要回表查詢，性能相 對較差一點。
首先說說索引的 優(yōu)點 ：最大的好處無疑就是提高查詢效率。有的索引還能保證數(shù)據(jù)的唯一性，比如唯一索引。
而它的 壞處 也很明顯：索引也是文件，我們在創(chuàng)建索引時，也會創(chuàng)建額外的文件，所以會占用一些硬盤空間。其次，索引也需要維護(hù)，我們在增加刪除數(shù)據(jù)的時候，索引也需要去變化維護(hù)。當(dāng)一個表的索引多了以后，資源消耗是很大的，所以必須結(jié)合實際業(yè)務(wù)再去確定給哪些列加索引。
再說說索引的基本結(jié)構(gòu)。一說到這里肯定會脫口而出：B+樹！了解B+樹前先要了解二叉查找樹和二叉平衡樹。 二叉查找樹 ：左節(jié)點比父節(jié)點小，右節(jié)點比父節(jié)點大，所以二叉查找樹的中序遍歷就是樹的各個節(jié)點從小到大的排序。 二叉平衡樹 ：左右子樹高度差不能大于1。B+樹就是結(jié)合了它們的特點，當(dāng)然，不一定是二叉樹。
為什么要有二叉查找樹的特點？？ 因為查找效率快，二分查找在這種結(jié)構(gòu)下，查找效率是很快的。 那為什么要有平衡樹的特點呢？ 試想，如果不維護(hù)一顆樹的平衡性，當(dāng)插入一些數(shù)據(jù)后，樹的形態(tài)有可能變得很極端，比如左子樹一個數(shù)據(jù)沒有，而全在右子樹上，這種情況下，二分查找和遍歷有什么區(qū)別呢？而就是因為這些特點需要去維護(hù)，所以就有了上面提到的缺點，當(dāng)索引很多后，反而增加了系統(tǒng)的負(fù)擔(dān)。
接著說B+樹。 它的結(jié)構(gòu)如下 ：
可以發(fā)現(xiàn)，葉子節(jié)點其實是一個 雙向循環(huán)鏈表 ，這種結(jié)構(gòu)的好處就是，在范圍查詢的時候，我只用找到一個數(shù)據(jù)，就可以直接返回剩余的數(shù)據(jù)了。比如找小于30的，只用找到30，其余的直接通過葉子節(jié)點間的指針就可以找到。再說說其他特點： 數(shù)據(jù)只存在于葉子節(jié)點 。當(dāng)葉子節(jié)點滿了，如果再添加數(shù)據(jù)，就會拆分葉子節(jié)點，父節(jié)點就多了個子節(jié)點。如果父節(jié)點的位置也滿了，就會擴(kuò)充高度，就是拆分父節(jié)點，如25 50 75拆分成：25為左子樹，75為右子樹，50變成新的頭節(jié)點，此時B+樹的高度變成了3。它們的擴(kuò)充的規(guī)律如下表，Leaf Page是葉子節(jié)點，index Page是非葉子節(jié)點。
再說說B樹 ，B樹相比較B+樹，它所有節(jié)點都存放數(shù)據(jù)，所以在查找數(shù)據(jù)時，B樹有可能沒到達(dá)葉子節(jié)點就結(jié)束了。再者，B樹的葉子節(jié)點間不存在指針。
最后說說Hash索引 ，相較于B+樹，Hash索引最大的優(yōu)點就是查找數(shù)據(jù)快。但是Hash索引最大的問題就是不支持范圍查詢。試想，如果查詢小于30的數(shù)據(jù)，hash函數(shù)是根據(jù)數(shù)據(jù)的值找到其對應(yīng)的位置，誰又知道小于30的有哪幾個數(shù)據(jù)。而B+樹正好相反，范圍查詢是它的強(qiáng)項。
附錄： Hash到底是啥？？ 哈希中文名散列，哈希只是它的音譯。 為啥都說Hash快？？ 首先有一塊哈希表（散列表），它的數(shù)據(jù)結(jié)構(gòu)是個數(shù)組，一個任意長度的數(shù)據(jù)通過hash函數(shù)都可以變成一個固定長度的數(shù)據(jù)，叫hash值。然后通過hash值確定在數(shù)組中的位置，相同數(shù)據(jù)的hash值是相同的，所以我們存儲一個數(shù)據(jù)以后，只需O(1)的時間復(fù)雜度就可以找到數(shù)據(jù)。 那hash函數(shù)又是啥？？ 算術(shù)運算或位運算，很多應(yīng)用里都有hash函數(shù)，但實際運算過程大不一樣。這是Java里String的hashCode方法：
publicint hashCode() {
}
還有一個問題，hash函數(shù)計算出來的hash值有可能存在碰撞，即兩個不同的數(shù)據(jù)可能存在相同的hash值，在MySQL或其他的應(yīng)用中，如Java的HashMap等，如果存在碰撞就會以當(dāng)前數(shù)組位置為頭節(jié)點，轉(zhuǎn)變成一個鏈表。
說到這里也清楚了為啥Java中引用類型要同時重寫hashCode和equals了。兩個對象，實例就算一模一樣，它們的hash值也不相等， 為啥不相等？？ 默認(rèn)的Object的hashCode方法會根據(jù)對象來計算hash值的，實例相同，但它們還是兩個不同的對象啊，所以我們重寫hashCode時，最簡單的方法就是調(diào)用Object的hashCode方法，然后傳入該引用類型的屬性，讓hashCode方法只根據(jù)這幾個屬性來計算，那么實例相同的話，它們的hash值也會相等。等hashCode比較完后，如果相等再比較實例內(nèi)容，也就是equals，確保不是hash碰撞。
索引的分類
如果我們指定了一個主鍵，那么這個主鍵就是主鍵索引。如果我們沒有指定，Mysql就會自動找一個非空的唯一索引當(dāng)主鍵。如果沒有這種字段，Mysql就會創(chuàng)建一個大小為6字節(jié)的自增主鍵。如果有多個非空的唯一索引，那么就讓第一個定義為唯一索引的字段當(dāng)主鍵，注意，是第一個定義，而不是建表時出現(xiàn)在前面的。
對于輔助索引來說，它們的B+樹結(jié)構(gòu)稍微有點特殊，它們的葉子節(jié)點存儲的是主鍵，而不是整個數(shù)據(jù)。所以在大部分情況下，使用輔助索引查找數(shù)據(jù)，需要二次查找。但并不是所有情況都需要二次查找。比如查找的數(shù)據(jù)正好就是當(dāng)前索引字段的值，那么直接返回就行。這里提一句，B+樹的key就是對應(yīng)索引字段的內(nèi)容。
而輔助索引又有一些分類：唯一索引：不能出現(xiàn)重復(fù)的值，也算一種約束。普通索引：可以重復(fù)、可以為空，一般就是查詢時用到。前綴索引：只適用于字符串類型數(shù)據(jù)，對字符串前幾個字符創(chuàng)建索引。全文索引：作用是檢測大文本數(shù)據(jù)中某個關(guān)鍵字，這也是搜索引擎的一種技術(shù)。
注意，聚集索引、非聚集索引和前面幾個索引的分類并不是一個層面上的。上面的幾個分類是從索引的作用來分析的。聚集、非聚集索引是從索引文件上區(qū)分的。主鍵索引就屬于聚集索引，即索引和數(shù)據(jù)存放在一起，葉子節(jié)點存放的就是數(shù)據(jù)。數(shù)據(jù)表的.idb文件就是存放該表的索引和數(shù)據(jù)。
輔助索引屬于非聚集索引，說到這也就明白了。索引和數(shù)據(jù)不存放在一起的就是非聚集索引。在MYISAM引擎中，數(shù)據(jù)表的.MYI文件包含了表的索引， 該表的 葉子節(jié)點存儲索引和索引對應(yīng)數(shù)據(jù)的指針，指向.MYD文件的數(shù)據(jù)。
索引的幾點使用經(jīng)驗
經(jīng)常被查詢的字段；經(jīng)常作為條件查詢的字段；經(jīng)常用于外鍵連接或普通的連表查詢時進(jìn)行相等比較字段；不為null的字段；如果是多條件查詢，最好創(chuàng)建聯(lián)合索引，因為聯(lián)合索引只有一個索引文件。
經(jīng)常被更新的字段、不經(jīng)常被查詢的字段、存在相同功能的字段
引入一個面試問題:
看完以下以后再回顧，會發(fā)現(xiàn)迎刃而解
Mysql 可以為每一張表設(shè)置 存儲引擎 這里我們只說 InnoDB 存儲引擎.
由于實際情況，數(shù)據(jù)頁只能按照一棵 B+樹 進(jìn)行排序， 因此每張表只能擁有一個 聚集索引（即 主鍵）。
栗子：
每個葉子節(jié)點的索引行中包含了一個書簽（bookmark）. 該書簽是用來告訴 InnoDB存儲引擎哪里可以找到該索引對應(yīng)的數(shù)據(jù)行或者說 行數(shù)據(jù)！ 由于InnoDB存儲引擎表， 是按照主鍵來構(gòu)建的， 所以 ，該書簽內(nèi)其實包含或者說指向了 數(shù)據(jù)行所對應(yīng)的聚集索引鍵
也就是說 輔助索引的 葉結(jié)點保存了 指向?qū)?yīng)數(shù)據(jù)的 聚集索引， 可以通過該聚集索引 找到對應(yīng)的數(shù)據(jù)行
輔助索引的存在并不影響數(shù)據(jù)在聚集索引中的組織，因為每張表上可以有多個輔助索引。
當(dāng)通過輔助索引來尋找數(shù)據(jù)時，InnoDB 存儲引擎會遍歷輔助索引并通過葉級別的指針獲得指向主鍵索引(聚集索引)的主鍵，然后再通過聚集索引找到一個完整的數(shù)據(jù)行。
例如：
聚集索引輔助索引關(guān)系:
： 又叫做組合索引 ， 輔助索引的一種 ， 和普通創(chuàng)建索引的方式一樣，不同的是 可以同時添加多列來作為索引項;
從本質(zhì)上來說，聯(lián)合索引也是一課B+樹
個人理解： 所謂最左原則， 是因為 存儲引擎構(gòu)建組合索引時 是根據(jù)最左邊的那一列索引項進(jìn)行排序的 ，所以使用組合索引，必須滿足 條件中必須存在 最左邊那一列的索引項，這樣 才可以找到對應(yīng)的索引，繼而 去尋找對應(yīng)的數(shù)據(jù)
： 又叫做 索引覆蓋，InnoDB中支持覆蓋索引，即 從輔助索引中就可以得到查詢的記錄，而不需要查詢聚集索引中的記錄。
比如 這里沒有根據(jù)最左原則使用組合索引，但是 優(yōu)化器依然進(jìn)行選擇
共勉，歡迎指導(dǎo)謝謝~
二級索引？？
mysql中每個表都有一個聚簇索引（clustered index ），除此之外的表上的每個非聚簇索引都是二級索引，又叫輔助索引（secondary indexes）。
以InnoDB來說，每個InnoDB表具有一個特殊的索引稱為聚集索引。如果您的表上定義有主鍵，該主鍵索引是聚集索引。如果你不定義為您的表的主鍵時，MySQL取第一個唯一索引（unique）而且只含非空列（NOT NULL）作為主鍵，InnoDB使用它作為聚集索引。如果沒有這樣的列，InnoDB就自己產(chǎn)生一個這樣的ID值，它有六個字節(jié)，而且是隱藏的，使其作為聚簇索引。
聚簇索引主要是為了方便存儲。。所以二級索引應(yīng)該都是對聚簇索引的索引。
下面是Mysql Manual上的原話，也可能我理解有誤。
Every InnoDB table has a special index called the clustered index where the data for the rows is stored. If you define a PRIMARY KEY on your table, the index of the primary key is the clustered index.
If you do not define a PRIMARY KEY for your table, MySQL picks the first UNIQUE index that has only NOT NULL columns as the primary key and InnoDB uses it as the clustered index. If there is no such index in the table, InnoDB internally generates a hidden clustered index on a synthetic column containing row ID values. The rows are ordered by the ID that InnoDB assigns to the rows in such a table. The row ID is a 6-byte field that increases monotonically as new rows are inserted. Thus, the rows ordered by the row ID are physically in insertion order.
Accessing a row through the clustered index is fast because the row data is on the same page where the index search leads. If a table is large, the clustered index architecture often saves a disk I/O operation when compared to storage organizations that store row data using a different page from the index record. (For example, MyISAM uses one file for data rows and another for index records.)
In InnoDB, the records in non-clustered indexes (also called secondary indexes) contain the primary key value for the row. InnoDB uses this primary key value to search for the row in the clustered index. If the primary key is long, the secondary indexes use more space, so it is advantageous to have a short primary key.
MySql為以下這些操作使用索引：
1、為了快速查找匹配WHERE條件的行。
2、為了從考慮的條件中消除行。如果在多個索引之間選擇一個，正常情況下，MySql使用找到行的最小數(shù)量的那個索引。
3、如果表有一個multiple-column索引，任何一個索引的最左前綴可以通過使用優(yōu)化器來查找行。例如，如果你有一個 three-column索引在(col1, col2, col3)，你能搜索索引在(col1), (col1, col2),和 (col1, col2, col3)。
方法
(1) 根據(jù)需求找到關(guān)聯(lián)表
(2)找到關(guān)聯(lián)條件
重點的表tables
* 需求1：統(tǒng)計world庫下有幾個表
需求2:統(tǒng)計所有庫下表的個數(shù)
需求3:統(tǒng)計每個庫的總數(shù)據(jù)大小
--單表占空間：AVG_ROW_LENGTH*TABLE_ROWS+INDEX_LENGTH
什么使索引：索引其實就是一種算法
BTree
HASH
Rtree
Fulltext
輔助索引
輔助索引只提取索引列作為葉子節(jié)點
聚集索引
聚集索引提取整行數(shù)據(jù)作為葉子節(jié)點
1、輔助索引和聚集索引最大的區(qū)別就在于葉子節(jié)點，枝節(jié)點和根節(jié)點原理相同
2、輔助索引會記錄主鍵值，一般情況（除等值查詢），最終都會通過聚集索引(主鍵)來找到需要的數(shù)據(jù)
第二種
一般經(jīng)常用來查詢的列作為索引
索引可以有多個，但是索引名不可重名
第一種:單列索引
第二種：前綴索引
前綴索引只能應(yīng)用到字符串列，數(shù)字列不能用前綴索引
聯(lián)合索引說明：如果在一個表內(nèi)對A、B、C三個列創(chuàng)建聯(lián)合索引那么創(chuàng)建索引將按照如下情況創(chuàng)建索引表：
A
AB
ABC
======================================================
(1)查詢列無索引
(2)語句不符合走走索引條件
(3)需要查看全表
即把有索引的列全便利一遍
、 、 =、 =、 like、 between and 在范圍掃描中，這些會受到B+tree索引葉子節(jié)點上額外的優(yōu)化，因為這些是連續(xù)取值的
or、in 這兩個不是連續(xù)的取值，所以不能受到B+tree索引的額外優(yōu)化，使用時相當(dāng)于Btree索引
!=、 not in 只有在主鍵列才走索引也是range級別
(1)、 、 =、 =、 like、 between and
(2)or、in
(3)!=、 not in
多表連接查詢，非驅(qū)動表連接條件是主鍵或唯一鍵
一般多表查詢的時，最左側(cè)的表為驅(qū)動表，右側(cè)的為非驅(qū)動表，下邊的例子中country標(biāo)為非驅(qū)動表
7.1.1 數(shù)字類型
7.1.2 字符串類型：
字符集
中文
gbk 2字節(jié)
utf8 3字節(jié)
utf8mb4 4字節(jié)
utf8mb4 為例:
舉例(1)聯(lián)合索引等值查詢
舉例(2) 聯(lián)合索引中有不等值查詢
如果Extra列出現(xiàn)Using temporary、Using filesort,兩項內(nèi)容，那么考慮以下語句的問題。
group by
order by
distinct
join on
union
重慶分公司
重慶分公司
