❶ mysql索引
在mysql中，索引是一種特殊的資料庫結構，由數據表中的一列或多列組合而成，可以用來快速查詢數據表中有某一特定值的記錄。
通過索引，查詢數據時不用讀完記錄的所有信息，而只是查詢索引列即可。
通過索引，查詢數據時不用讀完記錄的所有信息，而只是查詢索引列。否則，資料庫系統將讀取每條記錄的所有信息進行匹配。
可以把索引比作新華字典的音序表。例如，要查「庫」字，如果不使用音序，就需要從字典的 400 頁中逐頁來找。但是，如果提取拼音出來，構成音序表，就只需要從 10 多頁的音序表中直接查找。這樣就可以大大節省時間。
因此，使用索引可以很大程度上提高資料庫的查詢速度，還有效的提高了資料庫系統的性能。
索引的優缺點
索引有其明顯的優勢，也有其不可避免的缺點。
優點
索引的優點如下：
1、通過創建唯一索引可以保證資料庫表中每一行數據的唯一性。
2、可以給所有的 MySQL 列類型設置索引。
3、可以大大加快數據的查詢速度，這是使用索引最主要的原因。
4、在實現數據的參考完整性方面可以加速表與表之間的連接。
5、在使用分組和排序子句進行數據查詢時也可以顯著減少查詢中分組和排序的時間
缺點
增加索引也有許多不利的方面，主要如下：
1、創建和維護索引組要耗費時間，並且隨著數據量的增加所耗費的時間也會增加。
2、索引需要佔磁碟空間，除了數據表占數據空間以外，每一個索引還要佔一定的物理空間。如果有大量的索引，索引文件可能比數據文件更快達到最大文件尺寸。
3、當對表中的數據進行增加、刪除和修改的時候，索引也要動態維護，這樣就降低了數據的維護速度。
使用索引時，需要綜合考慮索引的優點和缺點。
❷ mysql的索引用的什麼數據結構
談到索引，大家並不陌生。索引本身是一種數據結構，存在的目的主要是為了縮短數據檢索的時間，最大程度減少磁碟 IO。
任何有數據的場景幾乎都有索引，比如手機通訊錄、文件系統（ext4\xfs\ntfs)、資料庫系統（MySQL\Oracle）。資料庫系統和文件系統一般都採用 B+ 樹來存儲索引信息，B+ 樹兼顧寫和讀的性能，最極端時檢索復雜度為 O(logN)，其中 N 指的是節點數量，logN 表示對磁碟 IO 掃描的總次數。
MySQL 支持的索引結構有四種：B+ 樹，R 樹，HASH，FULLTEXT。
❸ mysql索引採用什麼數據結構
文就是對這兩種數據結構做簡單的介紹。
1. B-Tree
B-Tree不是「B減樹」，而是「B樹」。
這里參考了嚴蔚敏《數據結構》對B-Tree的定義：
一棵m階的B-Tree,或者為空樹，或者滿足下列特性：
1.樹中每個結點至多有m棵子樹；
2.若根結點不是葉子結點，則至少有兩棵子樹；
3.除根節點之外的所有非終端結點至少有[m/2]棵子樹；
4.所有非終端結點中包含下列信息數據:
(n,A0,K1,A1,K2,A2……Kn,An)
其中，n為關鍵字的數目，K(i)為關鍵字，且K(i) < K(i+1), Ai為指向子樹根結點的指針，且指針A(i-1)所指子樹中所有結點的關鍵字均小於Ki，Ai所指子樹中所有結點的關鍵字均大於Ki；
5.所有葉子結點都出現在同一層次上；
下面通過一個例子解釋一下B-Tree的查找過程。
這是一棵4階的B-Tree，深度為4。
假如在該圖中查找關鍵字47，首先從根結點開始，根據根結點指針t找到*a結點，因為47大於 *a 結點的關鍵字35，所以會去A1指針指向的 *c結點繼續尋找，因為 *c的關鍵字 43 < 要查找的47 < *c結點的關鍵字78，所以去 *c結點A1指針指向的 *g結點去尋找，結果在 *g結點中找到了關鍵字47，查找成功。
2. B+Tree
不同的存儲引擎可能使用不同的數據結構存儲，InnoDB使用的是B+Tree；那什麼是B+Tree呢？
B+Tree是應文件系統所需而出的一種B-Tree的變型樹，一棵m階的B+樹和m階的B-樹的差異在於:
1.有n棵子樹的結點中含有n個關鍵字；
2.所有的葉子結點中包含了全部關鍵字的信息，及指向含這些關鍵字的記錄的指針，且葉子結點本身依關鍵字的大小自小而大順序鏈接；
3.所有的非終端結點可以看成是索引部分，結點中僅含有其子樹(根結點)中的最大（或最小）關鍵字；
還是通過一個例子來說明。
這個例子中，所有非終端結點僅含有子樹中最大的關鍵字。
因為葉子節點本身依據關鍵字的大小自小而大順序鏈接，所以可以從最小關鍵字起順序查找。也可以從根結點開始，進行隨機查找。
在B+樹中隨機差找和在B-樹中類似，以上圖為例。假設要查找關鍵字51，現在根節點中比較，發現51<59，因為這里使用的是非終端結點的關鍵字是子樹中最大的關鍵字，所以進入最大值為59的子結點(15\44\59)中查找，同理，因為44<51<59，所以進入P3指向的結點(51\59)中查找，然後命中關鍵字51，因為此結點(51\59)是葉子結點，所以查找終止，該結點包含指向數據的指針。
3.索引如何在B+Tree中組織數據存儲
假設有如下表:
對於表中的每一行數據，索引中包含了last_name、first_name和dob列的值，下圖展示索引是如何組織數據存儲的:
索引對多個值進行排序的依據是定義索引時列的順序。
(Allen Cuba 1960-01-01)結點左側的指針指向[?,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)的葉子頁，以此類推。總之，每個指針指向的結點中的最小值就是該指針左側的的值。
這種存儲結構也說明了在定義多個列組成的多列索引中，為什麼需要把重復率最低的列放到最左側，因為這會減少比較的次數，查找起來更加高效。
4.索引為什麼選用B樹這種數據結構？
因為使用B樹查找時，所用的磁碟IO操作次數比平衡二叉樹更少，效率也更高。
為什麼使用B樹查找所用的磁碟IO操作次數比平衡二叉樹更少？
大規模數據存儲中，樹節點存儲的元素數量是有限的（如果元素數量非常多的話，查找就退化成節點內部的線性查找了），這樣導致二叉查找樹結構由於樹的高度過大而造成磁碟I/O讀寫過於頻繁，進而導致查詢效率低下。那麼我們就需要減少樹的高度以提高查找效率。而平衡多路查找樹結構B樹就滿足這樣的要求。B樹的各種操作能使B樹保持較低的高度，從而達到有效減少磁碟IO操作次數。
❹ 索引數據結構都有哪些 分別有什麼區別呢 一般都採用什麼結構的呢
全文索引、聚集索引、哈希索引、b+樹索引等
B+樹的簡單定義：B+樹是為磁碟或其他存儲設備設計的一種平衡查找樹。B+樹中所有記錄都是按鍵值大小順序存放在葉子節點上，各葉子節點通過指針進行連接。
哈希索引(Hash indexes)採用哈希表來對鍵值進行查找，時間復雜度為O(1)。
使用哈希索引時對於鍵值的等值查詢是非常快的，但是其他類型的查詢如范圍查詢、模糊查詢、排序等是不能使用哈希索引的。這是哈希索引使用比較少的主要原因。
聚集索引（Clustered Index）又稱聚簇索引，其葉子節點存放記錄。
每個InnoDB 表有一個特定的索引叫做聚集索引,存儲行的數據。
如果你的表定義了主鍵那麼主鍵就是聚集索引，如果沒有定義主鍵,MySQL 會選擇第一個非空唯一索引列作為聚集索引，如果表中也沒有唯一索引,InnoDB會生成一個類似RowId的隱藏的聚集索引。
全文索引查找條件使用 MATCH AGAINST。
全文索引(Full-text search indexes)使用倒排索引(inverted index)實現。倒排索引會記錄文本中的每個關鍵字出現在文檔中的位置。
❺ mysql索引使用的是Btree還是B+tree為什麼
結合MySQL中Innodb存儲引擎索引結構來看的話……
教科書上的B+Tree是一個簡化了的，方便於研究和教學的B+Tree。然而在資料庫實現時，為了更好的性能或者降低實現的難度，都會在細節上進行一定的變化。下面以InnoDB為例，來說說這些變化。
04 - Sparse Index中的數據指針
在「由淺入深理解InnoDB索引的實現(1)」中提到，Sparse Index中的每個鍵值都有一個指針指向所在的數據頁。這樣每個B+Tree都有指針指向數據頁。
如果數據頁進行了拆分或合並操作，那麼所有的B+Tree都需要修改相應的頁指針。特別是Secondary B+Tree(輔助索引對應的B+Tree), 要對很多個不連續的頁進行修改。同時也需要對這些頁加鎖，這會降低並發性。為了降低難度和增加更新(分裂和合並B+Tree節點)的性能，InnoDB 將 Secondary B+Tree中的指針替換成了主鍵的鍵值。
這樣就去除了Secondary B+Tree對數據頁的依賴，而數據就變成了Clustered B+Tree(簇索引對應的B+Tree)獨占的了。對數據頁的拆分及合並操作，僅影響Clustered B+Tree. 因此InnoDB的數據文件中存儲的實際上就是多個孤立B+Tree。
一個有趣的問題: 當用戶顯式的把主鍵定義到了二級索引中時，還需要額外的主鍵來做二級索引的數據嗎(即存儲2份主鍵)? 很顯然是不需要的。InnoDB在創建二級索引的時候，會判斷主鍵的欄位是否已經被包含在了要創建的索引中.
接下來看一下數據操作在B+Tree上的基本實現。
- 用主鍵查詢
直接在Clustered B+Tree上查詢。
- 用輔助索引查詢
A. 在Secondary B+Tree上查詢到主鍵。
B. 用主鍵在Clustered B+Tree上查詢到數據。
可以看出，在使用主鍵值替換頁指針後，輔助索引的查詢效率降低了。
A. 如果能用主鍵查詢，盡量使用主鍵來查詢數據。
B. 但是由於Clustered B+Tree包含了完整的數據，遍歷的效率比 Secondary B+Tree的效率低。如果遍歷操作不涉及到二級索引和主鍵以外的數據，則盡量使用二級索引進行遍歷。
- INSERT
A. 在Clustered B+Tree上插入一條記錄
B. 在所有其他Secondary B+Tree上插入一條記錄(僅包含索引欄位和主鍵)
- DELETE
A. 在Clustered B+Tree上刪除一條記錄。
B. 在所有Secondary B+Tree上刪除二級索引的記錄。
- UPDATE 非鍵列
A. 在Clustered B+Tree上更新數據。
- UPDATE 主鍵列
A. 在Clustered B+Tree刪除原有的記錄(只是標記為DELETED,並不真正刪除)。
B. 在Clustered B+Tree插入一條新的記錄。
C. 在每一個Secondary B+Tree上刪除原有的記錄。(有疑問，看下一節。)
D. 在每一個Secondary B+Tree上插入一個條新的記錄。
- UPDATE 輔助索引的鍵值
A. 在Clustered B+Tree上更新數據。
B. 在每一個Secondary B+Tree上刪除原有的記錄。
C. 在每一個Secondary B+Tree上插入一條新的記錄。
更新鍵列時，需要更新多個頁，效率比較低。
A. 盡量不用對主鍵列進行UPDATE操作。
B. 更新很多時，盡量少建索引。
05 – 非唯一鍵索引
教科書上的B+Tree操作，通常都假設」鍵值是唯一的「。但是在實際的應用中Secondary Index是允許鍵值重復的。在極端的情況下，所有的鍵值都一樣，該如何來處理呢？InnoDB 的 Secondary B+Tree中，主鍵也是此二級鍵的一部分。 Secondary Key = 用戶定義的KEY + 主鍵。
注意主鍵不僅做為數據出現在葉子節點，同時也作為鍵的一部分出現非葉子節點。對於非唯一鍵來說，因為主鍵是唯一的，Secondary Key也是唯一的。當然，在插入數據時，還是會根據用戶定義的Key，來判斷唯一性。按理說，如果輔助索引是唯一的(並且所有欄位不能為空)，就不需要這樣做。可是，InnoDB對所有的Secondary B+Tree都這樣創建。
還沒弄明白有什麼特殊的用途？有知道的朋友可以幫忙解答一下。
也許是為了降低代碼的復雜性，這是我想到的唯一理由。
弄清楚了,即便是非空唯一鍵，在二級索引的B+Tree中也可能重復，因此必須要將主鍵加入到非葉子節點。
06 – <Key, Pointer>對
標準的B+Tree的每個節點有K個鍵值和K+1個指針，指向K+1個子節點。
而在「由淺入深理解索引的實現(1)」中圖. 9的B+Tree上，每個節點有K個鍵值和K個指針。InnoDB的B+Tree也是如此。
這樣做的好處在於，鍵值和指針一一對應。我們可以將一個<Key,Pointer>對看作一條記錄。這樣就可以用數據塊的存儲格式來存儲索引塊。因為不需要為索引塊定義單獨的存儲格式，就降低了實現的難度。
- 插入最小值
當考慮在變形後的B+Tree上進行INSERT操作時,發現了一個有趣的問題。如果插入的數據的健值比B+Tree的最小鍵值小時，就無法定位到一個適當的數據塊上去(<Key,Pointer>中的Key代表了子節點上的鍵值是>=Key的)。例如，在圖.5的B+Tree中插入鍵值為0的數據時，無法定位到任何節點。在標準的B+Tree上，這樣的鍵值會被定位到最左側的節點上去。這個做法，對於圖.5中的B+Tree也是合理的。Innodb的做法是，將每一層（葉子層除外）的最左側節點的第一條記錄標記為最小記錄(MIN_REC).在進行定位操作時，任何鍵值都比標記為MIN_REC的鍵值大。因此0會被插入到最左側的記錄節點上。
07 – 順序插入數據
標準的B-Tree分裂時，將一半的鍵值和數據移動到新的節點上去。原有節點和新節點都保留一半的空間，用於以後的插入操作。當按照鍵值的順序插入數據時，左側的節點不可能再有新的數據插入。因此，會浪費約一半的存儲空間。
解決這個問題的基本思路是：分裂順序插入的B-Tree時，將原有的數據都保留在原有的節點上。創建一個新的節點，用來存儲新的數據。順序插入時的分裂過程.
以上是以B-Tree為例，B+Tree的分裂過程類似。InnoDB的實現以這個思路為基礎，不過要復雜一些。因為順序插入是有方向性的，可能是從小到大，也可能是從大到小的插入數據。所以要區分不同的情況。如果要了解細節，可參考以下函數的代碼。
btr_page_split_and_insert();
btr_page_get_split_rec_to_right();
btr_page_get_split_rec_to_right();
InnoDB的代碼太復雜了，有時候也不敢肯定自己的理解是對的。因此寫了一個小腳本，來列印InnoDB數據文件中B+Tree。這樣可以直觀的來觀察B+Tree的結構，驗證自己的理解是否正確。
❻ mysql採用哪些索引，B樹索引解釋下
事實上，在MySQL資料庫中，諸多存儲引擎使用的是B+樹，即便其名字看上去是BTREE。
4.1 innodb的索引機制
先以innodb存儲引擎為例，說明innodb引擎是如何利用B+樹建立索引的
首先創建一張表：zodiac，並插入一些數據
❼ Mysql空間索引
在涉及LBS的服務開發過程中，經常需要存儲地理空間的位置並進行一定計算（附近商家等需求），本文主要介紹mysql對於LBS的支持。
Mysql的空間擴展主要提供一下幾個方面的功能：
其中前兩點對InnoDB，MyISAM，NDB，ARCHIVE等mysql存儲引擎都支持，第三點只有對InnoDB和MyISAM的支持，由於InnoDB的支持行鎖以及事務的特性，現在基本上已經是默認存儲引擎了，所以本文以下內容都默認使用InnoDB。
創建空間列以及空間索引的語句如下：
Mysql的空間數據類型與OpenGIS的數據類型相對應。
Mysql的空間數據有不同表示格式，其中咱能看懂的也就第一種
因為上文提到了SRID，這里說下什麼是SRID，SR是指Spatial Reference，也就是我們常說的空間參考系，mysql支持卡迪爾坐標系和地理坐標系，其中地理坐標系又有好多種，下面說幾種常用的空間參考系
Mysql的所有空間坐標系都存在表 mysql.st_spatial_reference_system 中，這個表是隱藏的，看不見的，但是你可以通過 infomation_shcema.st_spatial_reference_system 中查看參考系的信息，這個表就是 mysql.st_spatial_reference_system 的一個視圖的實現。
mysql的空間索引的數據結構是R樹，R樹實際上就是多維的B樹，B樹的數據結構在我的另一篇博客中有介紹，這里就不展開了，說幾點在應用的時候需要注意的。
最後轉一篇博文 https://visonforcoding.github.io/di-li-wei--geochu-li--mysql-geo-suo-yin.html
❽ 《mysql索引背後的數據結構及演算法原理》pdf下載在線閱讀全文，求百度網盤雲資源
《mysql索引背後的數據結構及演算法原理》網路網盤pdf最新全集下載:
鏈接: https://pan..com/s/1c-AnaxEqIfFdcsLOvD_vuA
簡介：本文以MySQL資料庫為研究對象，討論與資料庫索引相關的一些話題。特別需要說明的是，MySQL支持諸多存儲引擎，而各種存儲引擎對索引的支持也各不相同，因此MySQL資料庫支持多種索引類型，如BTree索引，哈希索引，全文索引等等。為了避免混亂，本文將只關注於BTree索引，因為這是平常使用MySQL時主要打交道的索引，至於哈希索引和全文索引本文暫不討論。
❾ mysql 索引結構是btree還是b+tree
第一部分主要從數據結構及演算法理論層面討論MySQL資料庫索引的數理基礎。
第二部分結合MySQL資料庫中MyISAM和InnoDB數據存儲引擎中索引的架構實現討論聚集索引、非聚集索引及覆蓋索引等話題。
第三部分根據上面的理論基礎，討論MySQL中高性能使用索引的策略。