在家闲来无聊，发现下面的 SQL 不走索引，哪位大神帮忙解释一下....
Create Table: CREATE TABLE `catalogs` (
....
`catalog_type` varchar(255) NOT NULL DEFAULT '' COMMENT 'type of catalog',
`parent_id` int(11) NOT NULL DEFAULT '0' COMMENT 'the parent''s id',
`status` int(11) NOT NULL DEFAULT '0' COMMENT 'status of catalog',
.....
KEY `index_catalogs_on_catalog_type_and_status_and_parent_id` (`catalog_type`,`status`,`parent_id`)
) ENGINE=InnoDB AUTO_INCREMENT=108 DEFAULT CHARSET=utf8
正如上面执行的结构，Mysql 的 InnerDB 不是最左匹配原则吗？为什么 SQL 查询时 catalog_type 的为 user-menu 时，不走索引而是全表扫描？而为 user_menu 时走索引了？
nouse
#11
2018年11月16日
KEY index_catalogs_on_catalog_type_and_status_and_parent_id (catalog_type,status,parent_id) 看上去应该是三个条件都要有才会用到索引？不太了解 MySQL，PG 是这样的。
原来还有这种操作
A，B联合索引
where A = ? AND B = ? //命中索引
where A = ? //命中索引
where B = ? //不命中索引
spfzzz
#19
2018年11月16日
对
mysterytree
回复
mysterytree
回复
明白了。就是说 InnoDB 的索引虽然采用的 B+tree 结构，大原则上也遵循最左匹配；但是真正执行查询的时候，会根据实际情况，不一定会走索引。有一问题咨询一下，如果 SQL 已经被缓存了（Mysql 开启了查询缓存），是不是也不走索引了，而是拿到缓存的数据直接返回应用层。
对
spfzzz
回复
spfzzz
回复
缓存命中应该是不走索引直接 return
但是加了 explain 参数后
应该会穿透缓存去执行
飞哥是要在家修炼一段时间杀回北京啊
