mysql官方對索引的定義為：索引(index)是幫助MySQL高效獲取數(shù)據(jù)的數(shù)據(jù)結構。

索引的本質：索引是數(shù)據(jù)結構。索引就是排好序的快速查找數(shù)據(jù)結構一般來說索引本身也很大不可能全部存儲在內存中，因此索引往往以索引文件的形式存儲在磁盤上平時所說的索引，如果沒有特別說明，都是指b樹(多路搜索樹，并不一定是二叉的)結構組織的索引。其中聚集索引、次要索引、復合索引、前綴索引、唯一索引都是默認使用B+樹索引，統(tǒng)稱索引。除了B+樹這種類型的索引之外，還有哈希索引等

1.索引的分類

• 主鍵索引(PRIMARY KEY)
  • 唯一的標識，因為主鍵不可重復，只能有一個列作為主鍵
• 唯一索引(UNIQUE KEY)
  • 避免重復的列出現(xiàn)，唯一索引可以重復，多個列都可以標識為唯一索引
• 常規(guī)索引(KEY ? / INDEX)
  • 默認的， 可以用index 、key 關鍵字來設置
• 全文索引(FullText)
  • 在特定的數(shù)據(jù)庫引擎下才有，myisam
  • 可以快速定位數(shù)據(jù)

show engines; --查看數(shù)據(jù)庫索引MySQL索引分類

• 單值索引
  • 一個索引只包含單個列，一個表可以有多個單列索引
• 唯一索引
  • 索引列的值必須唯一，但允許有null值
• 復合索引
  • 一個索引包含多個列

索引的使用1.在創(chuàng)建表的時候給字段增加索引2.創(chuàng)建完畢后，增加索引SHOW INDEX FROM student;--顯示表中的所有的索引信息--創(chuàng)建表的時候添加索引--增加一個全文索引(索引名) 列名ALTER TABLE school.student ADD FULLTEXT INDEX 'studentName'('studentName');--create index 索引名 on 表(字段名)create index id_student_studentName on student(studentName)--explain 分析SQL執(zhí)行的狀況EXPLAIN SELECT * FROM student;--非全文索引EXPLAIN SELECT * FROM student where match(studentName) agains('張');

2.測試索引

索引在小數(shù)據(jù)量的時候用處不大，但是在大數(shù)據(jù)的時候，區(qū)別十分明顯--添加大批量數(shù)據(jù)，使用SQL函數(shù)delimiter $$CREATE FUNCTION mock_data()RETURNS INTBEGINDECLARE num INT DEFAULT 1000000;DECLARE i INT DEFAULT 0;WHILE i--插入語句...SET i = i+1;END WHILE END

3.索引原則

• 索引不是越多越好
• 不要對經常變動的數(shù)據(jù)添加索引
• 小數(shù)據(jù)量的表不需要加索引
• 索引一般加在常用來查詢的字段上

索引的數(shù)據(jù)結構創(chuàng)建的時候默認的是hash類型的索引，不是innodb默認的，Btree: ? InnoDB 的默認數(shù)據(jù)結構資料鏈接：http://blog.codinglabs.org/articles/theory-of-mysql-index.html3層的B+樹可以表示上百萬的數(shù)據(jù)，如果上百萬的數(shù)據(jù)查找只需要三次IO操作，性能提高將是巨大的，如果就沒有索引，每個數(shù)據(jù)項都要發(fā)生一次IO,成本非常非常高。哪些情況下需要創(chuàng)建索引

• 主鍵自動建立唯一索引
• 頻繁作為查詢條件的字段應該創(chuàng)建索引
• 查詢中與其它表關聯(lián)的字段，外鍵關系建立索引
• 頻繁更新的字段不適合創(chuàng)建索引，因為每次更新不單單是更新了記錄，還會更新索引
• where條件里用不到的字段不創(chuàng)建索引
• 單鍵/組合索引的選擇問題(高并發(fā)下傾向創(chuàng)建組合索引)
• 查詢中排序的字段，排序字段若通過索引去訪問將大大提高排序速度
• 查詢中統(tǒng)計或者分組字段

哪些情況下不需要創(chuàng)建索引

• 表記錄太少
• 經常增刪改的表
• 數(shù)據(jù)重復且分布平均的表字段，因此應該只為最經常查詢和最經常排序的數(shù)據(jù)列建立索引，如果某個數(shù)據(jù)列包含許多重復的內容，為它建立索引就沒有太大的實際效果。

4.性能分析

MySQL Query Optimizer

• Mysql Query optimizer ：Mysql中有專門負責優(yōu)化SELECT語句的優(yōu)化器模塊，主要功能：通過計算分析系統(tǒng)中收集到的統(tǒng)計信息，為客戶端請求的Query提供他認為最優(yōu)的執(zhí)行計劃(他認為最優(yōu)的數(shù)據(jù)檢索方式,但不見得DBA認為是最優(yōu)的，這部分比較耗時)

• 當客戶端向MySQL 請求一條Query，命令解析器模塊完成請求分類，區(qū)別出是 SELECT 并轉發(fā)給MySQL Query Optimizer時，MySQL Query Optimizer 首先會對整條Query進行優(yōu)化，處理掉一些常量表達式的預算，直接換算成常量值。并對 Query 中的查詢條件進行簡化和轉換，如去掉一些無用或顯而易見的條件、結構調整等。然后分析 Query 中的 Hint 信息(如果有)，看顯示Hint信息是否可以完全確定該Query 的執(zhí)行計劃。如果沒有 Hint 或Hint 信息還不足以完全確定執(zhí)行計劃，則會讀取所涉及對象的統(tǒng)計信息，根據(jù) Query 進行寫相應的計算分析，然后再得出最后的執(zhí)行計劃。Query Optimizer 是一個數(shù)據(jù)庫軟件非常核心的功能，雖然說起來只是簡單的幾句話，但在 MySQL 內部，MySQL Query Optimizer 實際上經過了很多復雜的運算分析，才得出最后的執(zhí)行計劃。

MySQL常見瓶頸

• CPU：CPU在飽和的時候一般發(fā)生在數(shù)據(jù)裝入內存或從磁盤上讀取數(shù)據(jù)時候
• IO: ? 磁盤I/O瓶頸發(fā)生在裝入數(shù)據(jù)遠大于內存容量的時候
• 服務器硬件的性能瓶頸：top，free，iostat和vmstat來查看系統(tǒng)的性能狀態(tài)

Explain使用explain關鍵字可以模擬優(yōu)化器執(zhí)行SQL查詢語句，從而知道MySQL是如何處理你的SQL語句的。分析你的查詢語句或是表結構的性能瓶頸作用

• 表的讀取順序
• 數(shù)據(jù)讀取操作的操作類型
• 那些索引可以使用
• 哪些索引被實際使用
• 表之間的引用
• 每張表有多少行被優(yōu)化器查詢

用法Explain + SQL語句

idselect 查詢的序列號，包含一組數(shù)字，表示查詢中執(zhí)行select子句或操作表的順序

• id相同，執(zhí)行順序由上至下
• id不同，如果是子查詢，id的序號會遞增，id值越大優(yōu)先級越高，越先被執(zhí)行
• id相同不同，同時存在

select_type

• SIMPLE
  • 簡單的select查詢，查詢中不包含子查詢或者UNION
• PRIMARY
  • 查詢中若包含任何復查的子部分，最外層查詢則被標記
• SUBQUERY
  • 在select或者where列表中包含了子查詢
• DERIVED
  • 在from列表中包含的子查詢被標記為derived(衍生)，mysql會遞歸執(zhí)行這些子查詢，把結果放在臨時列表里。
• UNION
  • 若第二個select出現(xiàn)在union之后，則被標記為union；若union包含在from子句的子查詢中，外層select將被標記為：DERIVED
• UNION RESULT
  • 從union表中獲取結果的select

查詢的類型，主要是用于區(qū)別普通查詢、聯(lián)合查詢、子查詢等的復雜查詢table顯示這一行的數(shù)據(jù)是關于哪張表的type訪問類型排列從最好到最差依次是：system>const>eq_ref>ref>range>index>ALL,一般來說，得保證查詢至少達到range級別，最好能達到ref

• system : ?表只有一行記錄，(等于系統(tǒng)表)，這是const類型的特列，平時不會出現(xiàn)，這個也可以忽略不計

• const: ?表示通過索引一次就能找到了，const用于比較prinmary key 或者 unique索引，因為只匹配一行數(shù)據(jù)，所以很快，如將主鍵置于where列表中，mysql就能將該查詢轉換為一個常量。

• eq_ref: ?唯一索引掃描，對于每一個索引鍵，表中只有一條記錄與之匹配，常見于主鍵或唯一索引掃描。

• ref: ?非唯一性索引掃描，返回匹配某個單獨值的所有行，本質上也是一種索引訪問，他返回所有匹配某個單獨值的行，然而，他可能會找到多個符合條件的行，所以他應該屬于查找和掃描的混合體

• range: ?質檢所給定范圍的行，使用一個索引來選擇行。key 列顯示使用了哪個索引，一般就是在where語句中出現(xiàn)了between、、in等的查詢；這種 范圍掃描索引，比全表掃描要好，因為它只需要開始于索引的某一點，而結束與另一點，不用掃描全部索引。

• index： ?full index scan, index 與all區(qū)別為index類型只遍歷索引樹。這通常比all快，因為索引文件通常比數(shù)據(jù)文件小。也就是說，雖然all和index都是從索引中讀取的，但是index是從索引中讀取的，而all是從硬盤中讀取的。

• all: Full Table Scan，將遍歷全表以找到匹配的行。

possible_keys顯示可能在這張表中的索引，一個或多個；查詢涉及到的字段上若存在索引，則該索引將被列出，但不一定被查詢實際使用。key實際使用的索引，如果為null,則沒有使用索引，查詢中若使用了覆蓋索引，則該索引僅出現(xiàn)在key列表中key_len表示索引中使用的字節(jié)數(shù)，可通過該列計算查詢中使用的索引的長度。在不損失精確性的情況下，長度越短越好；key_len 顯示的值為索引字段的最大可能長度，并非實際使用長度，即key_len是根據(jù)表定義計算而得，不是通過表內檢索出的ref顯示索引的哪一列被使用了，如果可能的話，是一個常數(shù)，哪些列或常量被用于查找索引列上的值。rows根據(jù)表統(tǒng)計信息及索引選用情況，大致估算出找到所需的記錄所需要讀取的行數(shù)。(每張表有多少行被優(yōu)化器查詢)Extra包含不適合在其他列中顯示但十分重要的額外信息join語句的優(yōu)化盡可能減少join語句中的NetedLoop的循環(huán)次數(shù)；“永遠小結果集驅動大結果集”。優(yōu)先優(yōu)化NestedLoop的內層循環(huán)保證join語句中被驅動表上join條件字段已經被索引；當無法保證被驅動表的join條件字段被索引且內存資源充足的前提下，不要太吝惜JoinBuffer的設置

5.索引的優(yōu)勢和劣勢

• 優(yōu)勢
  • 提高數(shù)據(jù)檢索的效率，降低數(shù)據(jù)庫的IO成本
  • 通過索引對數(shù)據(jù)進行排序，降低數(shù)據(jù)排序的成本，降低了CPU的消耗
• 劣勢
  • 實際上索引也是一張表，該表保存了主鍵與索引字段，并指向實體表的記錄，所以索引也是要占用空間的
  • 雖然索引大大提高了查詢速度，同時卻會降低更新表的速度，如對表進行INSERT UPDATE ?和 DELETE。因為更新表時，MySQL不僅要保存數(shù)據(jù)，還要保存一下索引文件每次更新添加了索引列的字段，都會調整因為更新所帶來的鍵值變化后的索引信息。
  • 索引只是提高效率的一個因素，如果數(shù)據(jù)庫有大數(shù)據(jù)量的表，就需要花費時間建立最優(yōu)秀的索引，或優(yōu)化查詢

總結

以上是生活随笔為你收集整理的eclipse的servlet默认不执行index_MySQL之索引及执行计划分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。