一、兩大類索引定義

1.1 聚集索引

聚集索引（Clustered index）定義：數(shù)據(jù)行的物理順序與列值（一般是主鍵的那一列）的邏輯順序相同偷溺，一個(gè)表中只能擁有一個(gè)聚集索引哄孤。

聚集索引也稱為聚簇索引跨释、主鍵索引等胸私、聚類索引、簇集索引鳖谈。

1.2 非聚集索引定義

非聚集索引（Non-Clustered index）定義：該索引中索引的邏輯順序與磁盤上行的物理存儲(chǔ)順序不同岁疼，一個(gè)表中可以擁有多個(gè)非聚集索引。

非聚集索引也稱普通索引缆娃、二級(jí)索引等捷绒，除聚集索引外的索引，即非聚集索引贯要。

二暖侨、索引存儲(chǔ)結(jié)構(gòu)

2.1 聚集索引

聚集索引：指索引項(xiàng)的排序方式和表中數(shù)據(jù)記錄排序方式一致的索引

聚集索引的順序就是數(shù)據(jù)的物理存儲(chǔ)順序，它會(huì)根據(jù)聚集索引鍵的順序來存儲(chǔ)表中的數(shù)據(jù)崇渗，即對(duì)表的數(shù)據(jù)按索引鍵的順序進(jìn)行排序字逗，然后重新存儲(chǔ)到磁盤上。因?yàn)閿?shù)據(jù)在物理存放時(shí)只能有一種排列方式显押，所以一個(gè)表只能有一個(gè)聚集索引扳肛。

聚集索引

比如字典中傻挂，用【拼音】查漢字乘碑，就是聚集索引。因?yàn)檎闹凶侄际前凑掌匆襞判虻慕鹁堋６谩酒圆渴住坎闈h字兽肤，就是非聚集索引，因?yàn)檎闹械淖植⒉皇前凑掌圆渴着判虻男髋祝覀兺ㄟ^檢字表得到正文中的字在索引中的映射资铡，然后通過映射找到所需要的字。

2.2 非聚集索引

非聚集索引： 索引順序與物理存儲(chǔ)順序不同

非聚集索引

三幢码、何時(shí)使用聚集索引或非聚集索引

何時(shí)使用聚集索引或非聚集索引

• 使用聚集索引的查詢效率要比非聚集索引的效率要高笤休，但是如果需要頻繁去改變聚集索引的值，寫入性能并不高症副，因?yàn)樾枰苿?dòng)對(duì)應(yīng)數(shù)據(jù)的物理位置店雅。

• 非聚集索引在查詢的時(shí)候可以的話就避免二次查詢，這樣性能會(huì)大幅提升贞铣。

• 不是所有的表都適合建立索引闹啦，只有數(shù)據(jù)量大表才適合建立索引，且建立在選擇性高的列上面性能會(huì)更好辕坝。

事實(shí)上窍奋，我們可以通過前面聚集索引和非聚集索引的定義的例子來理解上表。如：返回某范圍內(nèi)的數(shù)據(jù)一項(xiàng)。比如某個(gè)表有一個(gè)時(shí)間列琳袄，恰好把聚合索引建立在了該列江场，這時(shí)查詢2004年1月1日至2004年10月1日之間的全部數(shù)據(jù)時(shí)，這個(gè)速度就將是很快的窖逗，因?yàn)檫@本字典正文是按日期進(jìn)行排序的扛稽，聚集索引只需要找到要檢索的所有數(shù)據(jù)中的開頭和結(jié)尾數(shù)據(jù)即可。而不像非聚集索引滑负，必須先查到目錄中查到每一項(xiàng)數(shù)據(jù)對(duì)應(yīng)的頁碼在张，然后再根據(jù)頁碼查到具體內(nèi)容。

四矮慕、explain分析索引

4.1 數(shù)據(jù)準(zhǔn)備

4.1.1 建表

CREATE TABLE IF NOT EXISTS `user` (
    `id` INT UNSIGNED AUTO_INCREMENT,
    `name` VARCHAR(60),
    `age` TINYINT(4),
    PRIMARY KEY (id),
    INDEX idx_age (age)
)  ENGINE=INNODB CHARSET=UTF8MB4;

id 字段是聚簇索引帮匾，age 字段是普通索引（二級(jí)索引）

4.1.2 插入數(shù)據(jù)

insert into user(name,age) values('張三',30);
insert into user(name,age) values('李四',20);
insert into user(name,age) values('王五',40);
insert into user(name,age) values('劉八',10);

查詢數(shù)據(jù)

4.2 索引存儲(chǔ)結(jié)構(gòu)

4.2.1 id 聚集索引

id 是主鍵且為聚集索引，其葉子節(jié)點(diǎn)存儲(chǔ)的是對(duì)應(yīng)行記錄的數(shù)據(jù)痴鳄。

id 聚集索引

4.2.2 age非聚集索引

age 是普通索引（二級(jí)索引）瘟斜，非聚簇索引，其葉子節(jié)點(diǎn)存儲(chǔ)的是聚簇索引的的值痪寻。

age非聚集索引

4.3 查詢

如果查詢條件為主鍵（聚集索引）螺句，則只需掃描一次B+樹即可通過聚集索引定位到要查找的行記錄數(shù)據(jù)。

select * from user where id = 1;

id查詢

如果查詢條件為普通索引（非聚集索引）橡类，需要掃描兩次B+樹蛇尚，第一次掃描通過普通索引定位到聚集索引的值，然后第二次掃描通過聚集索引的值定位到要查找的行記錄數(shù)據(jù)顾画。

select * from user where age = 30;

1》先通過普通索引【age=30】定位到主鍵值 【id=1】

普通索引

2》在通過聚集索引【id=1】定位到行記錄數(shù)據(jù)

普通索引

五取劫、回表查詢

先通過普通索引的值定位到聚集索引值，在通過聚集索引的值定位到行記錄數(shù)據(jù)研侣，要通過掃描兩次索引B+樹谱邪，它的性能較掃描一次較低。

六庶诡、索引覆蓋

只需在一顆索引樹上就能獲取SQL所需的所有列數(shù)據(jù)惦银，無需回表，速度更快末誓。

select id,age from user where age = 10;

6.1 如何實(shí)現(xiàn)覆蓋索引

常見的方法是：將被查詢的字段扯俱，建立到聯(lián)合索引里去（若查詢有where條件，同時(shí)where條件字段也必須為索引字段）基显。

例一：覆蓋索引

explain select id,age from user where age = 10;

explain分析：因?yàn)閍ge是普通索引蘸吓，使用到了age索引，通過一次掃描B+樹即可查詢到相應(yīng)的結(jié)果撩幽，這樣就實(shí)現(xiàn)了覆蓋索引库继。此時(shí)的Extra列的【Using Index】表示進(jìn)行了聚集索引箩艺。

覆蓋索引

例二：索引未覆蓋

explain select id,age,name from user where age = 10;

索引未覆蓋

explain分析：age是普通索引，但name列不在索引樹上宪萄，所以通過age索引在查詢到id和age的值后艺谆，需要進(jìn)行回表再查詢name的值。此時(shí)的Extra列的NULL表示進(jìn)行了回表查詢拜英。

為了實(shí)現(xiàn)索引覆蓋静汤，需要建組合索引idx_age_name(age,name)

drop index idx_age on user;
create index idx_age_name on user(`age`,`name`);

索引覆蓋

6.2 查詢條件中，一定不要使用select *

在SQL優(yōu)化的方式中有一條是【查詢條件中居凶，一定不要使用select *】虫给，其中有一個(gè)理由就是【覆蓋索引】。因?yàn)槭褂?code>select *失去mysql優(yōu)化器“覆蓋索引”策略優(yōu)化的可能性侠碧。

例如抹估，有一個(gè)表為t(a,b,c,d,e,f)，其中弄兜，a為主鍵药蜻，b列有索引。

那么替饿，在磁盤上有兩棵 B+ 樹语泽，即聚集索引和輔助索引（包括單列索引、聯(lián)合索引）视卢，分別保存(a,b,c,d,e,f)和(a,b)踱卵，如果查詢條件中where條件可以通過b列的索引過濾掉一部分記錄，查詢就會(huì)先走輔助索引腾夯，如果用戶只需要a列和b列的數(shù)據(jù)颊埃，直接通過輔助索引就可以知道用戶查詢的數(shù)據(jù)蔬充。

如果用戶使用select *蝶俱，獲取了不需要的數(shù)據(jù)，則首先通過輔助索引過濾數(shù)據(jù)饥漫，然后再通過聚集索引獲取所有的列榨呆，這就多了一次b+樹查詢，速度必然會(huì)慢很多庸队。

6.3 哪些場景適合使用索引覆蓋來優(yōu)化SQL

6.3.1 全表count查詢優(yōu)化

explain select count(age) from user;

count索引覆蓋

6.3.2 分頁查詢

explain select id,age,name from user order by age limit 100,2;

分頁索引覆蓋

七积蜻、MySQL聚集索引&非聚集索引

MySQL的兩種數(shù)據(jù)存儲(chǔ)方式，一種是InnoDB彻消，一種是MyISAM竿拆。這兩種存儲(chǔ)都是基于B+樹的存儲(chǔ)方式，但是也有點(diǎn)不同宾尚。

MyISAM索引文件和數(shù)據(jù)文件是分離的丙笋，索引文件僅保存數(shù)據(jù)記錄的地址谢澈。主索引和輔助索引沒有區(qū)別都是非聚集索引。索引頁正常大小為1024字節(jié)御板，索引頁存放在.MYI 文件中锥忿。MyISAM引擎使用B+Tree作為索引結(jié)構(gòu)，葉節(jié)點(diǎn)的data域存放的是數(shù)據(jù)記錄的地址怠肋。

InnoDB 也使用B+Tree作為索引結(jié)構(gòu)敬鬓，索引頁大小16，和表數(shù)據(jù)頁共同存放在表空間中笙各。從InnoDB表數(shù)據(jù)存放方式可看出InnoDB表數(shù)據(jù)文件本身就是按B+Tree組織的一個(gè)索引結(jié)構(gòu)钉答，這棵樹的葉節(jié)點(diǎn)data域保存了完整的數(shù)據(jù)記錄。這個(gè)索引的key是數(shù)據(jù)表的主鍵杈抢，因此InnoDB表數(shù)據(jù)文件本身就是主索引希痴。

• 如果表設(shè)置了主鍵，則主鍵就是聚集索引
• 如果表沒有主鍵春感，則會(huì)默認(rèn)第一個(gè)NOT NULL砌创，且唯一（UNIQUE）的列作為聚集索引瘤旨。
• 以上都沒有笆环，則會(huì)默認(rèn)創(chuàng)建一個(gè)隱藏的row_id作為聚集索引

一般來說，InnoDB 會(huì)以聚集索引的形式來存儲(chǔ)實(shí)際的數(shù)據(jù)但狭，它是其它二級(jí)索引的基礎(chǔ)窥岩。

八甲献、Innodb中建議設(shè)置主鍵自增

目前MySQL中就是將自增Id強(qiáng)制設(shè)定為主鍵索引，這是為了B+Tree和分頁颂翼。MySQL中每次新增數(shù)據(jù)晃洒，都是將一個(gè)頁寫滿，然后新創(chuàng)建一個(gè)頁繼續(xù)寫朦乏，這里其實(shí)是有個(gè)隱含條件的球及，那就是主鍵自增！主鍵自增寫入時(shí)新插入的數(shù)據(jù)不會(huì)影響到原有頁呻疹，插入效率高吃引！且頁的利用率高！但是如果主鍵是無序的或者隨機(jī)的刽锤，那每次的插入可能會(huì)導(dǎo)致原有頁頻繁的分裂镊尺，影響插入效率，降低頁的利用率并思，這也是為什么在Innodb中建議設(shè)置主鍵自增的原因庐氮。

九、聯(lián)合索引最左前綴匹配原則

9.1 最左前綴匹配原則概念

在MySQL建立聯(lián)合索引時(shí)會(huì)遵守最左前綴匹配原則宋彼，即最左優(yōu)先弄砍，在檢索數(shù)據(jù)時(shí)從聯(lián)合索引的最左邊開始匹配颅筋。

要想理解聯(lián)合索引的最左匹配原則，先來理解下索引的底層原理输枯。索引的底層是一顆B+樹议泵，那么聯(lián)合索引的底層也就是一顆B+樹，只不過聯(lián)合索引的B+樹節(jié)點(diǎn)中存儲(chǔ)的是鍵值桃熄。由于構(gòu)建一棵B+樹只能根據(jù)一個(gè)值來確定索引關(guān)系先口，所以數(shù)據(jù)庫依賴聯(lián)合索引最左的字段來構(gòu)建。

舉例：創(chuàng)建一個(gè)（a,b）的聯(lián)合索引瞳收，那么它的索引樹就是下圖的樣子碉京。

聯(lián)合索引

可以看到a的值是有順序的，1螟深，1谐宙，2，2界弧，3凡蜻，3，而b的值是沒有順序的1垢箕，2划栓，1，4条获，1忠荞，2。但是我們又可發(fā)現(xiàn)a在等值的情況下帅掘，b值又是按順序排列的委煤，但是這種順序是相對(duì)的。這是因?yàn)镸ySQL創(chuàng)建聯(lián)合索引的規(guī)則是首先會(huì)對(duì)聯(lián)合索引的最左邊第一個(gè)字段排序修档，在第一個(gè)字段的排序基礎(chǔ)上碧绞，然后在對(duì)第二個(gè)字段進(jìn)行排序。所以b=2這種查詢條件沒有辦法利用索引萍悴。

由于整個(gè)過程是基于explain結(jié)果分析的头遭，那接下來在了解下explain中的type字段和key_lef字段。

9.2 explain說明

9.2.1 type（聯(lián)接類型）

下面給出各種聯(lián)接類型,按照從最佳類型到最壞類型進(jìn)行排序:（重點(diǎn)看ref,rang,index）

• system：表只有一行記錄（等于系統(tǒng)表）癣诱，這是const類型的特例，平時(shí)不會(huì)出現(xiàn)袜香，可以忽略不計(jì)撕予。

• const：表示通過索引一次就找到了，const用于比較primary key 或者 unique索引蜈首。因?yàn)橹恍杵ヅ湟恍袛?shù)據(jù)实抡，所有很快欠母。如果將主鍵置于where列表中，mysql就能將該查詢轉(zhuǎn)換為一個(gè)const吆寨。

• eq_ref：唯一性索引掃描赏淌，對(duì)于每個(gè)索引鍵，表中只有一條記錄與之匹配啄清。常見于主鍵 或 唯一索引掃描六水。

注意：ALL全表掃描的表記錄最少的表如t1表。

• ref：非唯一性索引掃描辣卒，返回匹配某個(gè)單獨(dú)值的所有行掷贾。本質(zhì)是也是一種索引訪問，它返回所有匹配某個(gè)單獨(dú)值的行荣茫，然而他可能會(huì)找到多個(gè)符合條件的行想帅，所以它應(yīng)該屬于查找和掃描的混合體。

• range：只檢索給定范圍的行啡莉，使用一個(gè)索引來選擇行港准。key列顯示使用了那個(gè)索引。一般就是在where語句中出現(xiàn)了bettween咧欣、<叉趣、>、in等的查詢该押。這種索引列上的范圍掃描比全索引掃描要好疗杉。只需要開始于某個(gè)點(diǎn)，結(jié)束于另一個(gè)點(diǎn)蚕礼，不用掃描全部索引烟具。

• index：Full Index Scan，index與ALL區(qū)別為index類型只遍歷索引樹奠蹬。這通常為ALL塊朝聋，應(yīng)為索引文件通常比數(shù)據(jù)文件小。（Index與ALL雖然都是讀全表囤躁，但index是從索引中讀取狸演，而ALL是從硬盤讀取）

• ALL：Full Table Scan劝篷，遍歷全表以找到匹配的行活鹰。

9.2.2 key_len

key_len顯示MySQL實(shí)際決定使用的索引的長度蕊蝗。如果索引是NULL宾抓，則長度為NULL。如果不是NULL，則為使用的索引的長度。所以通過此字段就可推斷出使用了那個(gè)索引。

計(jì)算規(guī)則：

1.定長字段，int占用4個(gè)字節(jié)宾娜，date占用3個(gè)字節(jié)嚣艇，char(n)占用n個(gè)字符。

2.變長字段varchar(n)，則占用n個(gè)字符+兩個(gè)字節(jié)吱抚。

3.不同的字符集，一個(gè)字符占用的字節(jié)數(shù)是不同的。Latin1編碼的，一個(gè)字符占用一個(gè)字節(jié)，gdk編碼的，一個(gè)字符占用兩個(gè)字節(jié)，utf-8編碼的，一個(gè)字符占用三個(gè)字節(jié)淆衷。由于我數(shù)據(jù)庫使用的是Latin1編碼的格式，所以在后面的計(jì)算中碉输，一個(gè)字符按一個(gè)字節(jié)算）

4.對(duì)于所有的索引字段肄梨，如果設(shè)置為NULL阻荒，則還需要1個(gè)字節(jié)。

9.3 explain分析

9.3.1 數(shù)據(jù)準(zhǔn)備

創(chuàng)建數(shù)據(jù)表

CREATE TABLE staffs (
    id INT(10) DEFAULT NULL,
    name CHAR(10) DEFAULT NULL,
    age INT(10) DEFAULT NULL,
    KEY `id_name_age_index` (`id` , `name` , `age`)
)  ENGINE=INNODB DEFAULT CHARSET=LATIN1;

插入數(shù)據(jù)

insert into staffs(id,name,age) values(1,'hhh',20);
insert into staffs(id,name,age) values(2,'bbb',21);
insert into staffs(id,name,age) values(3,'ccc',22);

該表中對(duì)id列.name列.age列建立了一個(gè)聯(lián)合索引 id_name_age_index众羡，實(shí)際上相當(dāng)于建立了三個(gè)索引（id）（id_name）（id_name_age）侨赡。

9.3.2 全值匹配查詢時(shí)

SQL 1

explain select * from staffs where id=1 and age=20 and name='hhh';

1

SQL 2

explain select * from staffs where name='hhh' and id=1 and age=20;

2

SQL 3

explain select * from staffs where age=20 and name='hhh' and id=1;

3

通過觀察上面的結(jié)果圖可知，where后面的查詢條件纱控，不論是使用（id辆毡，age，name）（name甜害，id舶掖，age）還是（age，name尔店，id）順序眨攘，在查詢時(shí)都使用到了聯(lián)合索引，可能有同學(xué)會(huì)疑惑嚣州，為什么底下兩個(gè)的搜索條件明明沒有按照聯(lián)合索引從左到右進(jìn)行匹配鲫售，卻也使用到了聯(lián)合索引？ 這是因?yàn)镸ySQL中有查詢優(yōu)化器explain该肴，所以sql語句中字段的順序不需要和聯(lián)合索引定義的字段順序相同情竹，查詢優(yōu)化器會(huì)判斷糾正這條SQL語句以什么樣的順序執(zhí)行效率高，最后才能生成真正的執(zhí)行計(jì)劃匀哄，所以不論以何種順序都可使用到聯(lián)合索引秦效。另外通過觀察上面三個(gè)圖中的key_len字段，也可說明在搜索時(shí)使用的聯(lián)合索引中的（id_name_age）索引涎嚼，因?yàn)閕d為int型阱州，允許null，所以占5個(gè)字節(jié)法梯，name為char(10)苔货，允許null，又使用的是latin1編碼，所以占11個(gè)字節(jié)夜惭，age為int型允許null姻灶，所以也占用5個(gè)字節(jié)，所以該索引長度為21（5+11+5）滥嘴，而上面key_len的值也正好為21木蹬，可證明使用的（id_name_age）索引至耻。

9.3.3 匹配最左邊的列時(shí)

SQL 1

explain select * from staffs where id=1;

1

該搜索是遵循最左匹配原則的若皱，通過key字段也可知，在搜索過程中使用到了聯(lián)合索引尘颓，且使用的是聯(lián)合索引中的（id）索引走触，因?yàn)閗ey_len字段值為5，而id索引的長度正好為5（因?yàn)閕d為int型疤苹，允許null互广，所以占5個(gè)字節(jié)）。

SQL 2

explain select * from staffs where id=1 and name='hhh';

2

由于id到name是從左邊依次往右邊匹配卧土，這兩個(gè)字段中的值都是有序的惫皱，所以也遵循最左匹配原則，通過key字段可知尤莺，在搜索過程中也使用到了聯(lián)合索引旅敷，但使用的是聯(lián)合索引中的（id_name）索引，因?yàn)閗ey_len字段值為16颤霎，而(id_name)索引的長度正好為16（因?yàn)閕d為int型媳谁，允許null，所以占5個(gè)字節(jié)友酱，name為char(10)晴音，允許null，又使用的是latin1編碼缔杉，所以占11個(gè)字節(jié)）锤躁。

SQL 3

explain select * from staffs where id=1 and name='hhh' and age=20;

3

由于上面三個(gè)搜索都是從最左邊id依次向右開始匹配的，所以都用到了id_name_age_index聯(lián)合索引或详。那如果不是依次匹配呢系羞？

SQL 4

explain select * from staffs where id=1 and age=20;

4

通過key字段可知，在搜索過程中也使用到了聯(lián)合索引鸭叙，但使用的是聯(lián)合索引中的（id）索引觉啊，從key_len字段也可知。因?yàn)槁?lián)合索引樹是按照id字段創(chuàng)建的沈贝，但age相對(duì)于id來說是無序的杠人，只有id只有序的，所以他只能使用聯(lián)合索引中的id索引。

SQL 5

explain select * from staffs where name='hhh';

5

通過觀察發(fā)現(xiàn)上面key字段發(fā)現(xiàn)在搜索中也使用了id_name_age_index索引嗡善，可能許多同學(xué)就會(huì)疑惑它并沒有遵守最左匹配原則辑莫，按道理會(huì)索引失效，為什么也使用到了聯(lián)合索引罩引？因?yàn)闆]有從id開始匹配各吨，且name單獨(dú)來說是無序的，所以它確實(shí)不遵循最左匹配原則袁铐，然而從type字段可知揭蜒，它雖然使用了聯(lián)合索引，但是它是對(duì)整個(gè)索引樹進(jìn)行了掃描剔桨，正好匹配到該索引屉更，與最左匹配原則無關(guān)，一般只要是某聯(lián)合索引的一部分洒缀，但又不遵循最左匹配原則時(shí)瑰谜，都可能會(huì)采用index類型的方式掃描，但它的效率遠(yuǎn)不如最做匹配原則的查詢效率高树绩，index類型類型的掃描方式是從索引第一個(gè)字段一個(gè)一個(gè)的查找萨脑，直到找到符合的某個(gè)索引，與all不同的是饺饭，index是對(duì)所有索引樹進(jìn)行掃描渤早，而all是對(duì)整個(gè)磁盤的數(shù)據(jù)進(jìn)行全表掃描。

SQL 6

explain select * from staffs where age=20;

6

SQL 7

explain select * from staffs where name='hhh' and age=20;

7

這兩個(gè)結(jié)果跟上面的是同樣的道理砰奕，由于它們都沒有從最左邊開始匹配蛛芥，所以沒有用到聯(lián)合索引，使用的都是index全索引掃描军援。

9.3.4 匹配列前綴

如果id是字符型仅淑，那么前綴匹配用的是索引，中墜和后綴用的是全表掃描胸哥。

select * from staffs where id like 'A%';//前綴都是排好序的涯竟，使用的都是聯(lián)合索引
select * from staffs where id like '%A%';//全表查詢
select * from staffs where id like '%A';//全表查詢

9.3.5 匹配范圍值

SQL 1

explain select * from staffs where id>1 and id<3;

1

在匹配的過程中遇到<>=號(hào)，就會(huì)停止匹配空厌，但id本身就是有序的庐船，所以通過possible_keys字段和key_len 字段可知，在該搜索過程中使用了聯(lián)合索引的id索引（因?yàn)閕d為int型嘲更，允許null筐钟，所以占5個(gè)字節(jié)），且進(jìn)行的是rang范圍查詢赋朦。

explain select * from staffs where id<4 and age>20 and age<50;

SQL 2

2

由于不遵循最左匹配原則篓冲，且在id<4的范圍中李破，age是無序的，所以使用的是index全索引掃描壹将。

SQL 3

explain select * from staffs where id<2 and age>20 and age<50;

3

不遵循最左匹配原則嗤攻，但在數(shù)據(jù)庫中id<2的只有一條（id），所以在id<2的范圍中诽俯，age是有序的妇菱，所以使用的是rang范圍查詢。

SQL 4

explain select * from staffs where age>20 and age<50;

4

不遵循最左匹配原則暴区，而age又是無序的闯团，所以進(jìn)行的全索引掃描。

9.3.6 準(zhǔn)確匹配第一列并范圍匹配其他某一列

SQL 1

explain select * from staffs where id=1 and age<50;

1

由于搜索中有id=1颜启，所以在id范圍內(nèi)age是無序的偷俭，所以只使用了聯(lián)合索引中的id索引。