mysql索引最左匹配原则

啊对对对，索引最左匹配，这玩意儿在 MySQL 里头挺重要的。
你就记住啊，用多列索引的时候，查条件得从最左边的列开始，连续往下查。
断了，中间跳过去了，那索引就白用了，数据库就得全表扫。

比如说，你有个索引是 (a, b, c)。
那你要查 WHERE a = 1 AND b = 2 ，这就叫连续匹配，能用好索引。
但你要是查 WHERE b = 2 ，或者查 WHERE a = 1 AND c = 3 ，这就不行了，因为不是从最左边的 a 开始，或者中间的 b 跳过去了，索引就失效了。

为啥呢？索引是按列顺序存的，有点像字典。
像 (a, b) 这个索引，a 的值决定了 b 存在哪儿。
你要是单独查 b，数据库就搞不定了，因为 b 在索引里没顺序，只能一整表地看。

不过啊，也有点例外。
一个就是范围查询。
比如 WHERE a > 1 AND b = 2 ，那 a 用范围索引，b 这列还能用上。
但你不能跨得太多，像 WHERE a > 1 AND c = 3 ，那 c 就不能用索引了，因为中间隔了 b。

还有啊，就是索引覆盖。
你要是查的列都在索引里了，就算没严格从左往右查，也可能不用全表扫。
比如你 SELECT a, b，WHERE b = 2 ，但索引是 (b, a)，那数据库可能直接从索引里拿数据，不用回表查原表。

所以你看，用好最左匹配原则，能省多少事儿啊。
比如查 WHERE a = 1 AND b = 2 ，用 (a, b) 这个索引，能快速找到 a = 1 的那一堆行，直接在那一堆里找 b = 2 的，不用看其他 a 不等于 1 的行。
你要是直接查 b = 2 ，那数据库得先全表扫，再找 b = 2 的，那得多慢。

搞索引啊，列顺序得设计好。
把经常一起查的放左边。
别断点，像 WHERE a = 1 AND c = 3 这种，a 和 c 中间隔着 b，肯定不行。
覆盖索引是个好东西，能不用回表就别回表。
还有啊，慎用 OR，像 WHERE a = 1 OR b = 2 ，这俩条件用 OR 连着，索引可能就废了，最好拆成两个查询用 UNION。

有时候有些人也搞不清。
比如 LIKE '%abc'，这肯定不能用索引，因为不是从左边开始匹配。
得像 LIKE 'abc%' 这样，从左边开始，才符合最左原则。
还有啊，类型得匹配，比如 WHERE a = '1 '，但 a 这列是整型，那数据库可能会自动把 '1 ' 当整数，或者当字符串，搞混了，索引也就失效了。

总之啊，最左匹配就是个规矩，你得记住了。
索引顺序设计好，查条件连续匹配，查询效率就能上去了。

mysql索引最左匹配原则的理解?

对，就是这个问题。
MySQL索引最左匹配不绝对。

上周刚处理一个，查询没按预期走索引。

就是用trace工具看，实际怎么走。

有时候，MySQL会选全表扫描，不按最左匹配。

比如，name和cid，MySQL可能不按顺序走。

条件顺序不重要，优化器看具体情况。

理解优化机制，才能优化查询和索引。

面试前必须要掌握的MySQL索引最左前缀匹配原则

哎，说起来这最左前缀匹配原则，我第一次面试的时候，哎，我就懵了。
我当时那个面试官，他问我，联合索引你懂不？我那时候就瞎说一气，说联合索引啊，就是可以提高查询效率嘛。
他问，那最左前缀匹配呢？我当时就有点蒙，我后来才反应过来，哎，就是从最左边的字段开始匹配。

哎，我当时举了个例子，说就像你有一本书，书的封面、目录、章节，你找东西，肯定是从封面开始翻起，对吧？联合索引也是这样，得从最左边开始用。

那原理呢，我后来想啊，就B+树结构，联合索引构建，查询匹配，这些概念，我就硬着头皮解释了一下。
我当时说，就B+树啊，节点里存储的是键值，然后按顺序排好，联合索引就是按字段顺序排。

我面试的那个城市是杭州，我记得当时说，如果查询条件里没有最左边的字段，那MySQL就只能全表扫描了，效率可就低多了。

然后我提到了应用，全值匹配、匹配最左边的列、匹配列前缀，还有匹配范围值，这些我都尽量说得详细点。
我就说，比如你查个名字，就按名字开头字母查，这个也能用索引。

我还说了注意事项，查询优化器啊，索引选择啊，避免冗余索引啊。
我就说，面试官，你看，这个联合索引啊，得根据需求来设计，不能乱加。

哎，说到底，最左前缀匹配原则这东西，面试前真的得掌握好，不然像我当时那样，哎，就有点尴尬了。