索引可以讓伺服器快速的定位到表的指定位置。但是這並不是索引的唯一作用，到目前位置可以看到，根據建立索引的資料結構不同，索引頁有一些其他的附加作用。
最常見的b-tree索引，按照順序儲存資料，所以mysql可以用來做order by和group by 操作。因為資料是有序的，所以b-tree也就會將相關的列值都儲存在一起。最後，因為索引中村吃醋了實際的列值，所以某些查詢只使用索引就能夠完成全部查詢。根據此特性，索引有以下三個優點：
① 索引大大減少了伺服器需要掃瞄的資料量。
② 索引可以幫助伺服器避免排序和臨時表。
③ 索引可以將隨機i/o變為順序i/o
如果想深入理解索引推薦閱讀有tapio lahdenmaki和mike leach編寫的relational database index design and the optimizers(wiley出版社)這本書，書中詳細介紹了如何計算索引的成本和作用、如何評估查詢速度、如何分析索引維護的代價等
注意：索引不一定是最好的解決方案
總的來說，真自由當索引幫助村吃醋引擎快速查詢到記錄帶來的好處大於其帶來的額外工作時，索引才是有效的。對於非常小的表，大部分情況下簡單的全表掃瞄效率更高。對於中大型的表，索引才是有效的。但對於特大型別的表，簡歷和使用索引的代價將隨之增長。這種情況下，則需要一種技術可以直接群分出查詢需要的一組資料，而不是一條記錄一條記錄的匹配。這就是分割槽。
如果表的數量特別多，可以建立乙個元資料資訊表，用來查詢需要用到的某些特性。例如執行哪些需要聚合多個應用分布在多個表的資料查詢，則需要記錄那個使用者的資訊儲存在哪個表中的元資料，這樣查詢時就可以直接忽略哪些不報汗指定使用者資訊的表。這對於大型系統，是乙個常用的技巧。事實上infobright就是使用類似的實現。對於tb級別的資料，定位單條記錄的意義不大，所以京城會使用塊級別元資料技術來替代索引。
例：之前在一家小公司，由於專案是從外包做得，所以架構不是很好，一條常用的資料經常需要查詢好幾張表。後來給我提了乙個需求要按天做乙個產品的統計資訊並用echarts生成圖表，這個產品分3~5個級別大概1000多個種類，幾十萬的資料量，當時的開始時間到結束時間的跨度是2年左右，要統計每個種類的數量並展示每個大類別的所佔比例及每個種類的top5，這一系列查詢大概涉及到5個表。所以我並沒有使用建立索引的方式來做即時查詢而是建立了一張新的彙總表，定時計算每個種類的數量資訊，在拿這些資料進行簡單的算數運算，每次頁面重新整理大概3~5秒左右，後來我又使用redis做了一次結果的快取，這時候每次頁面重新整理耗時1~2秒。
高效能mysql（一） 建立高效能索引
單列索引和多列索引 單列索引 多個單列索引的選擇問題 多個or條件 多個單列的效能往往效能很低，盡量建立高效的多列索引。多列索引 選擇合適的索引順序 避免範圍條件 在where子句中，in是有效的，範圍條件會導致後面的索引無效！在order by中，範圍條件和in都會導致無法按照索引排序！按照索引順...
高效能Mysql筆記 優化
了解查詢的整個生命週期，清楚每個階段的時間消耗情況 參考select profiling 檢視profiling是否開啟 set profiling 1 開啟profiling show profiles 檢視每條查詢的效能 show profile for query id 檢視query id的...
Mysql建立高效能索引
mysql索引的基礎和型別 索引的基礎 1.索引類似於書籍的目錄，要想找到一本書的某個特定主題，需要先查詢書的目錄，定位對應的頁碼 儲存引擎使用類似的方式進行資料查詢，先去索引當中找到對應的值，然後根據匹配的索引找到對應的資料行 索引對效能的影響 大大減少伺服器需要掃瞄的資料量，比如我們資料表中有一...