DROP TABLE IF EXISTS med_computer_info;
CREATE TABLE med_computer_info (
ID BIGINT NOT NULL AUTO_INCREMENT COMMENT '电脑id',
HOST_NAME VARCHAR ( 64 ) NOT NULL COMMENT '电脑id地址',
PORT VARCHAR ( 64 ) NOT NULL COMMENT '电脑端口',
TYPE INT NOT NULL COMMENT '电脑类型',
LAUNCH_DATE DATE NOT NULL COMMENT '电脑发布日期',
MODIFIED TIMESTAMP NOT NULL COMMENT '记录修改时间',
CREATED TIMESTAMP NOT NULL COMMENT '记录创建时间',
PRIMARY KEY ( ID ),
UNIQUE KEY INDEX_WORKER_NODE ( HOST_NAME, PORT, LAUNCH_DATE, TYPE )
) COMMENT = 'DB WorkerID Assigner for UID Generator',
ENGINE = INNODB;
select * from med_computer_info where PORT=3306 and Type=1 ;
select * from med_computer_info where PORT=3307 and HOST_NAME='172.21.1.1' ;
select * from med_computer_info where PORT=3308 AND HOST_NAME='172.21.1.2' AND TYPE=2 ;
第一句:没用到索引,在聚集索引上从左至右依次扫描过滤;
第二句:用到了辅助索引INDEX_WORKER_NODE;
第三句:用到了辅助索引INDEX_WORKER_NODE,但是只有HOST_NAME和PORT条件是通过索引完成的,条件TYPE是依次扫描过滤完成的;
因为辅助索引是B+树实现的,虽然可以指定多个列,但是每个列的比较优先级不一样,写在前面的优先比较。一旦出现遗漏,在B+树上就无法继续搜索了(通过补齐等措施解决的除外),因此是按照最左连续匹配来的。既然是在B+树上搜索,对于条件的比较自然是要求精确匹配(即"=“和"IN”)。不过顺序倒是可以颠倒,因为查询优化器重排序一下就好了。
第一句,由于缺少HOST_NAME,只能在聚集索引的叶节点上,从左至右的扫描,挨个比对;
第二句,可以直接在辅助索引上查找,被找到的子树的所有叶节点就是命中的记录;
第三句,缺少LAUNCH_DATE条件,所以只能先依据HOST_NAME和PROT在辅助索引上查找,找到的主键值作为候选记录,然后到聚集索引上读取对应记录,再比较TYPE条件是否满足。
DROP TABLE IF EXISTS student;
CREATE TABLE `student` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(255) DEFAULT NULL,
`cid` int(11) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `name_cid_INX` (`name`,`cid`),
KEY `name_INX` (`name`)
) ENGINE=InnoDB AUTO_INCREMENT=8 DEFAULT CHARSET=utf8
依据mysql索引最左匹配原则,两个索引都匹配上了,这个没有问题
EXPLAIN SELECT * FROM student WHERE name='小红';
判断条件是cid=1,而cid是(name,cid)复合索引的一部分,没有问题,可以进行index类型的索引扫描方式。explain显示结果使用到了索引,是index类型的方式。
EXPLAIN SELECT * FROM student WHERE cid=1;
cid字段的索引数据也是有序的情况下才能使用,什么时候才是有序的呢?观察可知,当然是在name字段是等值匹配的情况下,cid才是有序的。
EXPLAIN SELECT * FROM student WHERE cid=1 AND name='小红';
index:这种类型表示是mysql会对整个该索引进行扫描。要想用到这种类型的索引,对这个索引并无特别要求,只要是索引,或者某个复合索引的一部分,mysql都可能会采用index类型的方式扫描。但是呢,缺点是效率不高,mysql会从索引中的第一个数据一个个的查找到最后一个数据,直到找到符合判断条件的某个索引。
ref:这种类型表示mysql会根据特定的算法快速查找到某个符合条件的索引,而不是会对索引中每一个数据都进行一 一的扫描判断,也就是所谓你平常理解的使用索引查询会更快的取出数据。而要想实现这种查找,索引却是有要求的,要实现这种能快速查找的算法,索引就要满足特定的数据结构。简单说,也就是索引字段的数据必须是有序的,才能实现这种类型的查找,才能利用到索引。
以该表的(name,cid)复合索引为例,它内部结构简单说就是下面这样排列的:
Mysql创建复合索引的规则是首先会对复合索引的最左边的,也就是第一个name字段的数据进行排序,在第一个字段的排序基础上,然后再对后面第二个的cid字段进行排序。其实就相当于实现了类似 order by name cid这样一种排序规则。
所以:第一个name字段是绝对有序的,而第二字段就是无序的了。所以通常情况下,直接使用第二个cid字段进行条件判断是用不到索引的,当然,可能会出现上面的使用index类型的索引。这就是所谓的mysql为什么要强调最左前缀原则的原因。
那么什么时候才能用到呢?
当然是cid字段的索引数据也是有序的情况下才能使用
DROP TABLE IF EXISTS student;
CREATE TABLE `student` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(255) DEFAULT NULL,
`cid` int(11) DEFAULT NULL,
`home` VARCHAR(255) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `name_cid_INX` (`name`,`cid`),
KEY `name_INX` (`name`)
) ENGINE=InnoDB AUTO_INCREMENT=8 DEFAULT CHARSET=utf8
EXPLAIN SELECT * FROM student WHERE cid=1;
比案例二多了一个home字段,由于辅助索引包含聚集索引,所以案例二的辅助索引为全部字段。
辅助索引包含了主键id用于回表操作,同时利用覆盖索引扫描可以更好的优化SQL。
索引可以加快数据的检索,减少IO开销,会占用磁盘空间,是一种用空间换时间的优化手段,同时更新操作会导致索引频繁的合并分裂,影响索引性能,在实际的业务开发中,如何根据业务场景去设计合适的索引是非常重要的
mysql查询优化器会判断纠正这条sql语句该以什么样的顺序执行效率最高,最后才生成真正的执行计划。所以,当然是我们能尽量的利用到索引时的查询顺序效率最高咯,所以mysql查询优化器会最终以这种顺序进行查询执行。