联合主键下的聚簇索引

懂的越多,不懂的越多

上次提到,mysql创建表结构时,如果使用的不是单一主键,而是联合主键,那么主键对应的索引会如何建立哪?没有实践,就没有发言权,今天就来进行一番彻底的比对实验把!

create table test1(id1 int Not Null,id2 int Not Null, Primary Key (id1, id2),val int);
create table test2(id1 int Not Null,id2 int Not Null, Primary Key (id2, id1),val int);

创建表test1和test2

type 类型有10多种,我们今天会见到的有all,index,ref,const这几种
类型 all index ref const 对应意义 全表扫描 查找所有的索引树 查找非唯一性索引 查找主键索引
possible_keys:查询中涉及到索引,但是要注意,这个索引不一定被使用。

话不多说直接上对比

第一组sql:

sql type possible_keys EXPLAIN SELECT * FROM test1 WHERE ID1=1; ref PRIMARY EXPLAIN SELECT * FROM test1 WHERE ID2=1; ALL EXPLAIN SELECT * FROM test2 WHERE ID1=1; ALL EXPLAIN SELECT * FROM test2 WHERE ID2=1; ref PRIMARY
好像我们可以得出一个结论 “建立表时,联合主键的顺序会影响索引的建立,顺序在前的会建立索引,之后的并不会建立索引。” 但是真的是这样吗?

第二组sql:

sql type possible_keys EXPLAIN SELECT * FROM test1 WHERE ID1=1; ref PRIMARY EXPLAIN SELECT * FROM test1 WHERE ID2=1; ALL EXPLAIN SELECT * FROM test1 WHERE ID1=1 AND ID2=1; const PRIMARY
这种情况是不是有点面熟哪?复合索引,联合主键自动建立复合索引。

有兴趣的朋友可以使用三个键的联合主键来进行测试,三个键用来做对比食用更美味。

上边有提到一个问题,explain 的 possible_keys 指的是:涉及到索引,但是这个索引不一定被使用,那么问题来了,什么场景下索引不会被使用哪?

经验分享 程序员 微信小程序 职场和发展