① 解釋mysql中什麼是索引它的作用是什麼
索引的意義 ·索引在資料庫中的作用相當於目錄在書籍中的作用類似，都用來提高查找信息的速度。 ·索引是一個表中所包含值的列表，其中註明了表中包含各個值的行所在的存儲位置，使用索引查找數據時，先從索引對象中獲得相關列的存儲位置，然後再直接去其存儲位置查找所需信息，這樣就無需對這個表進行掃描，從而可以快速的找到所需數據。
② MySQL資料庫的四類索引
index ---- 普通索引,數據可以重復，沒有任何限制。
unique ---- 唯一索引,要求索引列的值必須唯一，但允許有空值；如果是組合索引，那麼列值的組合必須唯一。
primary key ---- 主鍵索引,是一種特殊的唯一索引，一個表只能有一個主鍵，不允許有空值，一般是在創建表的同時創建主鍵索引。
組合索引 ---- 在多個欄位上創建的索引，只有在查詢條件中使用了創建索引時的第一個欄位，索引才會被使用。
fulltext ---- 全文索引,是對於大表的文本域：char，varchar，text列才能創建全文索引，主要用於查找文本中的關鍵字，並不是直接與索引中的值進行比較。fulltext更像是一個搜索引擎，配合match against操作使用，而不是一般的where語句加like。
注:全文索引目前只有MyISAM存儲引擎支持全文索引，InnoDB引擎5.6以下版本還不支持全文索引
所有存儲引擎對每個表至少支持16個索引，總索引長度至少為256位元組，索引有兩種存儲類型，包括B型樹索引和哈希索引。
索引可以提高查詢的速度，但是創建和維護索引需要耗費時間，同時也會影響插入的速度，如果需要插入大量的數據時，最好是先刪除索引，插入數據後再建立索引。
③ MYSQL資料庫索引類型都有哪些
在滿足語句需求的情況下，盡量少的訪問資源是資料庫設計的重要原則，這和執行的 SQL 有直接的關系，索引問題又是 SQL 問題中出現頻率最高的，常見的索引問題包括：無索引（失效）、隱式轉換。
1. SQL 執行流程看一個問題，在下面這個表 T 中，如果我要執行 select * from T where k between 3 and 5; 需要執行幾次樹的搜索操作，會掃描多少行？mysql> create table T ( -> ID int primary key, -> k int NOT NULL DEFAULT 0, -> s varchar(16) NOT NULL DEFAULT '', -> index k(k)) -> engine=InnoDB;mysql> insert into T values(100,1, 'aa'),(200,2,'bb'), (300,3,'cc'),(500,5,'ee'),(600,6,'ff'),(700,7,'gg');
這分別是 ID 欄位索引樹、k 欄位索引樹。
這條 SQL 語句的執行流程：
1. 在 k 索引樹上找到 k=3，獲得 ID=3002. 回表到 ID 索引樹查找 ID=300 的記錄，對應 R33. 在 k 索引樹找到下一個值 k=5，ID=5004. 再回到 ID 索引樹找到對應 ID=500 的 R4
5. 在 k 索引樹去下一個值 k=6，不符合條件，循環結束
這個過程讀取了 k 索引樹的三條記錄，回表了兩次。因為查詢結果所需要的數據只在主鍵索引上有，所以必須得回表。所以，我們該如何通過優化索引，來避免回表呢？
2. 常見索引優化2.1 覆蓋索引覆蓋索引，換言之就是索引要覆蓋我們的查詢請求，無需回表。
如果執行的語句是 select ID from T wherek between 3 and 5;，這樣的話因為 ID 的值在 k 索引樹上，就不需要回表了。
覆蓋索引可以減少樹的搜索次數，顯著提升查詢性能，是常用的性能優化手段。
但是，維護索引是有代價的，所以在建立冗餘索引來支持覆蓋索引時要權衡利弊。
2.2 最左前綴原則
B+ 樹的數據項是復合的數據結構，比如 (name,sex，age) 的時候，B+ 樹是按照從左到右的順序來建立搜索樹的，當 (張三,F,26) 這樣的數據來檢索的時候，B+ 樹會優先比較 name 來確定下一步的檢索方向，如果 name 相同再依次比較 sex 和 age，最後得到檢索的數據。
# 有這樣一個表 P
mysql> create table P (id int primary key, name varchar(10) not null, sex varchar(1), age int, index tl(name,sex,age)) engine=IInnoDB;
mysql> insert into P values(1,'張三','F',26),(2,'張三','M',27),(3,'李四','F',28),(4,'烏茲','F',22),(5,'張三','M',21),(6,'王五','M',28);
# 下面的語句結果相同
mysql> select * from P where name='張三' and sex='F'; ## A1
mysql> select * from P where sex='F' and age=26; ## A2
# explain 看一下
mysql> explain select * from P where name='張三' and sex='F';
+----+-------------+-------+------------+------+---------------+------+---------+-------------+------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+-------+------------+------+---------------+------+---------+-------------+------+----------+-------------+
| 1 | SIMPLE | P | NULL | ref | tl | tl | 38 | const,const | 1 | 100.00 | Using index |
+----+-------------+-------+------------+------+---------------+------+---------+-------------+------+----------+-------------+
mysql> explain select * from P where sex='F' and age=26;
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+--------------------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+--------------------------+
| 1 | SIMPLE | P | NULL | index | NULL | tl | 43 | NULL | 6 | 16.67 | Using where; Using index |
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+--------------------------+
- 可以清楚的看到，A1 使用 tl 索引，A2 進行了全表掃描，雖然 A2 的兩個條件都在 tl 索引中出現，但是沒有使用到 name 列，不符合最左前綴原則，無法使用索引。所以在建立聯合索引的時候，如何安排索引內的欄位排序是關鍵。評估標準是索引的復用能力，因為支持最左前綴，所以當建立（a，b）這個聯合索引之後，就不需要給 a 單獨建立索引。原則上，如果通過調整順序，可以少維護一個索引，那麼這個順序往往就是需要優先考慮採用的。上面這個例子中，如果查詢條件里只有 b，就是沒法利用（a，b）這個聯合索引的，這時候就不得不維護另一個索引，也就是說要同時維護（a，b）、（b）兩個索引。這樣的話，就需要考慮空間佔用了，比如，name 和 age 的聯合索引，name 欄位比 age 欄位佔用空間大，所以創建（name，age）聯合索引和（age）索引佔用空間是要小於（age，name）、(name）索引的。
- 以人員表的聯合索引（name, age）為例。如果現在有一個需求：檢索出表中「名字第一個字是張，而且年齡是26歲的所有男性」。那麼，SQL 語句是這么寫的mysql> select * from tuser where name like '張%' and age=26 and sex=M;
- 通過最左前綴索引規則，會找到 ID1，然後需要判斷其他條件是否滿足在 MySQL 5.6 之前，只能從 ID1 開始一個個回表。到主鍵索引上找出數據行，再對比欄位值。而 MySQL 5.6 引入的索引下推優化(index condition pushdown)，可以在索引遍歷過程中，對索引中包含的欄位先做判斷，直接過濾掉不滿足條件的記錄，減少回表次數。這樣，減少了回表次數和之後再次過濾的工作量，明顯提高檢索速度。
- 隱式類型轉化主要原因是，表結構中指定的數據類型與傳入的數據類型不同，導致索引無法使用。所以有兩種方案：
- 修改表結構，修改欄位數據類型。
修改應用，將應用中傳入的字元類型改為與表結構相同類型。
- 3. 為什麼會選錯索引3.1 優化器選擇索引是優化器的工作，其目的是找到一個最優的執行方案，用最小的代價去執行語句。在資料庫中，掃描行數是影響執行代價的因素之一。掃描的行數越少，意味著訪問磁碟數據的次數越少，消耗的 CPU 資源越少。當然，掃描行數並不是唯一的判斷標准，優化器還會結合是否使用臨時表、是否排序等因素進行綜合判斷。
- MySQL 在真正開始執行語句之前，並不能精確的知道滿足這個條件的記錄有多少條，只能通過索引的區分度來判斷。顯然，一個索引上不同的值越多，索引的區分度就越好，而一個索引上不同值的個數我們稱為「基數」，也就是說，這個基數越大，索引的區分度越好。# 通過 show index 方法，查看索引的基數mysql> show index from t;+-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |+-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+| t | 0 | PRIMARY | 1 | id | A | 95636 | NULL | NULL | | BTREE | | || t | 1 | a | 1 | a | A | 96436 | NULL | NULL | YES | BTREE | | || t | 1 | b | 1 | b | A | 96436 | NULL | NULL | YES | BTREE | | |+-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
- MySQL 使用采樣統計方法來估算基數：采樣統計的時候，InnoDB 默認會選擇 N 個數據頁，統計這些頁面上的不同值，得到一個平均值，然後乘以這個索引的頁面數，就得到了這個索引的基數。而數據表是會持續更新的，索引統計信息也不會固定不變。所以，當變更的數據行數超過 1/M 的時候，會自動觸發重新做一次索引統計。
on 表示統計信息會持久化存儲。默認 N = 20，M = 10。
off 表示統計信息只存儲在內存中。默認 N = 8，M = 16。
- 由於是采樣統計，所以不管 N 是 20 還是 8，這個基數都很容易不準確。所以，冤有頭債有主，MySQL 選錯索引，還得歸咎到沒能准確地判斷出掃描行數。
- ANALYZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE tbl_name [, tbl_name] ...
- 3.3 索引選擇異常和處理1. 採用 force index 強行選擇一個索引。2. 可以考慮修改語句，引導 MySQL 使用我們期望的索引。3. 有些場景下，可以新建一個更合適的索引，來提供給優化器做選擇，或刪掉誤用的索引。
2.3 索引下推
2.4 隱式類型轉化
3.2 掃描行數
在 MySQL 中，有兩種存儲索引統計的方式，可以通過設置參數 innodb_stats_persistent 的值來選擇：
可以用 analyze table 來重新統計索引信息，進行修正。
④ 索引數據結構都有哪些 分別有什麼區別呢 一般都採用什麼結構的呢
全文索引、聚集索引、哈希索引、b+樹索引等
B+樹的簡單定義：B+樹是為磁碟或其他存儲設備設計的一種平衡查找樹。B+樹中所有記錄都是按鍵值大小順序存放在葉子節點上，各葉子節點通過指針進行連接。
哈希索引(Hash indexes)採用哈希表來對鍵值進行查找，時間復雜度為O(1)。
使用哈希索引時對於鍵值的等值查詢是非常快的，但是其他類型的查詢如范圍查詢、模糊查詢、排序等是不能使用哈希索引的。這是哈希索引使用比較少的主要原因。
聚集索引（Clustered Index）又稱聚簇索引，其葉子節點存放記錄。
每個InnoDB 表有一個特定的索引叫做聚集索引,存儲行的數據。
如果你的表定義了主鍵那麼主鍵就是聚集索引，如果沒有定義主鍵,MySQL 會選擇第一個非空唯一索引列作為聚集索引，如果表中也沒有唯一索引,InnoDB會生成一個類似RowId的隱藏的聚集索引。
全文索引查找條件使用 MATCH AGAINST。
全文索引(Full-text search indexes)使用倒排索引(inverted index)實現。倒排索引會記錄文本中的每個關鍵字出現在文檔中的位置。
⑤ mysql有那些索引分別在什麼場景使用
一、普通索引
這是最基本的索引，它沒有任何限制。有以下幾種創建方式：
1.創建索引
代碼如下:
CREATE INDEX indexName ON mytable(username(length));
如果是CHAR，VARCHAR類型，length可以小於欄位實際長度；如果是BLOB和TEXT類型，必須指定 length，下同。
2.修改表結構
代碼如下:
ALTER mytable ADD INDEX [indexName] ON (username(length)) -- 創建表的時候直接指定。
CREATE TABLE mytable( ID INT NOT NULL, username VARCHAR(16) NOT NULL, INDEX [indexName] (username(length)) );
-- 刪除索引的語法：
DROP INDEX [indexName] ON mytable;
二、唯一索引
它與前面的普通索引類似，不同的就是：索引列的值必須唯一，但允許有空值。如果是組合索引，則列值的組合必須唯一。它有以下幾種創建方式：
代碼如下:
CREATE UNIQUE INDEX indexName ON mytable(username(length))
-- 修改表結構
ALTER mytable ADD UNIQUE [indexName] ON (username(length))
-- 創建表的時候直接指定
CREATE TABLE mytable( ID INT NOT NULL, username VARCHAR(16) NOT NULL, UNIQUE [indexName] (username(length)) );
三、主鍵索引
它是一種特殊的唯一索引，不允許有空值。一般是在建表的時候同時創建主鍵索引：
代碼如下:
CREATE TABLE mytable( ID INT NOT NULL, username VARCHAR(16) NOT NULL, PRIMARY KEY(ID) );
當然也可以用 ALTER 命令。記住：一個表只能有一個主鍵。
四、組合索引
為了形象地對比單列索引和組合索引，為表添加多個欄位：
代碼如下:
CREATE TABLE mytable( ID INT NOT NULL, username VARCHAR(16) NOT NULL, city VARCHAR(50) NOT NULL, age INT NOT NULL );
為了進一步榨取MySQL的效率，就要考慮建立組合索引。
二：使用索引的注意事項
使用索引時，有以下一些技巧和注意事項：
1.索引不會包含有NULL值的列
只要列中包含有NULL值都將不會被包含在索引中，復合索引中只要有一列含有NULL值，那麼這一列對於此復合索引就是無效的。所以我們在資料庫設計時不要讓欄位的默認值為NULL。
2.使用短索引
對串列進行索引，如果可能應該指定一個前綴長度。例如，如果有一個CHAR(255)的列，如果在前10個或20個字元內，多數值是惟一的，那麼就不要對整個列進行索引。短索引不僅可以提高查詢速度而且可以節省磁碟空間和I/O操作。
3.索引列排序
MySQL查詢只使用一個索引，因此如果where子句中已經使用了索引的話，那麼order by中的列是不會使用索引的。因此資料庫默認排序可以符合要求的情況下不要使用排序操作；盡量不要包含多個列的排序，如果需要最好給這些列創建復合索引。
4.like語句操作
一般情況下不鼓勵使用like操作，如果非使用不可，如何使用也是一個問題。like 「%aaa%」 不會使用索引而like 「aaa%」可以使用索引。
5.不要在列上進行運算
select * from users where YEAR(adddate)<2007;
將在每個行上進行運算，這將導致索引失效而進行全表掃描，因此我們可以改成:
select * from users where adddate<『2007-01-01';
6.不使用NOT IN和<>操作。
三：sql優化原則
常見的簡化規則如下：
1.不要有超過5個以上的表連接（JOIN）
2.考慮使用臨時表或表變數存放中間結果。
3.少用子查詢
4.視圖嵌套不要過深,一般視圖嵌套不要超過2個為宜。
5.連接的表越多，其編譯的時間和連接的開銷也越大，性能越不好控制。
6.最好是把連接拆開成較小的幾個部分逐個順序執行。
7.優先執行那些能夠大量減少結果的連接。
8.拆分的好處不僅僅是減少SQL Server優化的時間，更使得SQL語句能夠以你可以預測的方式和順序執行。
如果一定需要連接很多表才能得到數據，那麼很可能意味著設計上的缺陷。
⑥ 請問mysql索引，有主鍵索引、唯一索引、全文索引、組合索引、普通索引，他們分別的數據結構是什麼
普通索引：最基本的索引，沒有任何限制
唯一索引：與"普通索引"類似，不同的就是：索引列的值必須唯一，但允許有空值。
主鍵索引：它 是一種特殊的唯一索引，不允許有空值。
全文索引：僅可用於 MyISAM 表，針對較大的數據，生成全文索引很耗時好空間。
組合索引：為了更多的提高mysql效率可建立組合索引，遵循」最左前綴「原則。
MyISAM中索引檢索的演算法為首先按照B+Tree搜索演算法搜索索引，如果指定的Key存在，則取出其data域的值，然後以data域的值為地址，讀取相應數據記錄。在MyISAM中，主索引和輔助索引（Secondary key）在結構上沒有任何區別，只是主索引要求key是唯一的，而輔助索引的key可以重復。
InnoDB的數據文件本身就是索引文件。InnoDB的輔助索引data域存儲相應記錄主鍵的值而不是地址。
聚集索引這種實現方式使得按主鍵的搜索十分高效，但是輔助索引搜索需要檢索兩遍索引：首先檢索輔助索引獲得主鍵，然後用主鍵到主索引中檢索獲得記錄。
⑦ 按照存儲結構劃分,索引分為哪兩類各有何作用
聚集索引：對表在物理數據頁中的數據排列進行排序，然後重新存儲到磁碟上，表中的數據行只能以一種方式存儲在磁碟上，故一個表只能有一個聚集索引。創建任何非聚集索引之前必須創建聚集索引。
非聚集索引：具有完全獨立於數據行的結構，使用非聚集索引不會影響數據表中記錄的實際存儲順序。
(7)mysql索引存儲結構包括擴展閱讀
優點
1.大大加快數據的檢索速度;
2.創建唯一性索引，保證資料庫表中每一行數據的唯一性;
3.加速表和表之間的連接;
4.在使用分組和排序子句進行數據檢索時，可以顯著減少查詢中分組和排序的時間。
缺點
1.索引需要佔物理空間。
2.當對表中的數據進行增加、刪除和修改的時候，索引也要動態的維護，降低了數據的維護速度。
⑧ 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 索引結構是btree還是b+tree
第一部分主要從數據結構及演算法理論層面討論MySQL資料庫索引的數理基礎。
第二部分結合MySQL資料庫中MyISAM和InnoDB數據存儲引擎中索引的架構實現討論聚集索引、非聚集索引及覆蓋索引等話題。
第三部分根據上面的理論基礎，討論MySQL中高性能使用索引的策略。