先来看个例子：
1. 示例1：假设有如下的一张表：
- DROP TABLE IF EXISTS testTable;
- CREATE TABLE testTable
- (
- ID BIGINT NOT NULL AUTO_INCREMENT COMMENT 'auto increment id',
- HOST_NAME VARCHAR(64) NOT NULL COMMENT 'host name',
- PORT VARCHAR(64) NOT NULL COMMENT 'port',
- TYPE INT NOT NULL COMMENT 'node type: ACTUAL or CONTAINER',
- LAUNCH_DATE DATE NOT NULL COMMENT 'launch date',
- MODIFIED TIMESTAMP NOT NULL COMMENT 'modified time',
- CREATED TIMESTAMP NOT NULL COMMENT 'created time',
- 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 testTable where PORT=3306 and Type=1
- select * from testTable where PORT=3307 and HOST_NAME='172.21.1.1'
- select * from testTable 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条件是否满足。
2. 示例2：假设有如下的一张表：
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
随便建了一个student表做测试。
create INDEX name_cid_INX ON student(name,cid);
create INDEX name_INX ON student(name);
建了两个索引，故意这样建的。
执行1:
EXPLAIN SELECT * FROM student WHERE name='小红';
依据mysql索引最左匹配原则，两个索引都匹配上了，这个没有问题。。
执行2:
EXPLAIN SELECT * FROM student WHERE cid=1;
EXPLAIN SELECT * FROM student WHERE cid=1 AND name='小红';
为什么还能匹配索引？
讲上面问题之前，我先补充一些知识，因为我觉得你对索引理解是狭隘的：
上述你的两个查询的explain结果中显示用到索引的情况类型是不一样的。,可观察explain结果中的type字段。你的查询中分别是：
1. type: index
2. type: ref
解释：
index：这种类型表示是mysql会对整个该索引进行扫描。要想用到这种类型的索引，对这个索引并无特别要求，只要是索引，或者某个复合索引的一部分，mysql都可能会采用index类型的方式扫描。但是呢，缺点是效率不高，mysql会从索引中的第一个数据一个个的查找到最后一个数据，直到找到符合判断条件的某个索引。
EXPLAIN SELECT * FROM student WHERE cid=1;
判断条件是cid=1,而cid是(name,cid)复合索引的一部分，没有问题，可以进行index类型的索引扫描方式。explain显示结果使用到了索引，是index类型的方式。
---------------------------------------------------------------------------------------------------------------------------
ref：这种类型表示mysql会根据特定的算法快速查找到某个符合条件的索引，而不是会对索引中每一个数据都进行一 一的扫描判断，也就是所谓你平常理解的使用索引查询会更快的取出数据。而要想实现这种查找，索引却是有要求的，要实现这种能快速查找的算法，索引就要满足特定的数据结构。简单说，也就是索引字段的数据必须是有序的，才能实现这种类型的查找，才能利用到索引。
有些了解的人可能会问，索引不都是一个有序排列的数据结构么。不过答案说的还不够完善，那只是针对单个索引，而复合索引的情况有些同学可能就不太了解了。
下面就说下复合索引：
以该表的(name,cid)复合索引为例,它内部结构简单说就是下面这样排列的：
所以：第一个name字段是绝对有序的，而第二字段就是无序的了。所以通常情况下，直接使用第二个cid字段进行条件判断是用不到索引的，当然，可能会出现上面的使用index类型的索引。这就是所谓的mysql为什么要强调最左前缀原则的原因。
那么什么时候才能用到呢?当然是cid字段的索引数据也是有序的情况下才能使用咯，什么时候才是有序的呢？观察可知，当然是在name字段是等值匹配的情况下，cid才是有序的。发现没有，观察两个name名字为 c 的cid字段是不是有序的呢。从上往下分别是4 5。
这也就是mysql索引规则中要求复合索引要想使用第二个索引，必须先使用第一个索引的原因。（而且第一个索引必须是等值匹配）。
---------------------------------------------------------------------------------------------------------------------------
所以对于你的这条sql查询：
EXPLAIN SELECT * FROM student WHERE cid=1 AND name='小红';
没有错，而且复合索引中的两个索引字段都能很好的利用到了！因为语句中最左面的name字段进行了等值匹配，所以cid是有序的，也可以利用到索引了。
你可能会问：我建的索引是(name,cid)。而我查询的语句是cid=1 AND name='小红'; 我是先查询cid，再查询name的，不是先从最左面查的呀？
好吧，我再解释一下这个问题：首先可以肯定的是把条件判断反过来变成这样 name='小红' and cid=1; 最后所查询的结果是一样的。
那么问题产生了？既然结果是一样的，到底以何种顺序的查询方式最好呢？