怎么肥四？mysql联合索引的最左原则失效了？？？

最近新工作忙活告一段落，开始着手梳理老系统的业务逻辑写成文档，没想到看到了祖传代码：存储过程。虽然我没写过存储过程不过好在我sql功底不错，也能看得懂，我把存储过程的sql整理出来，发现有一断sql慢查询严重，经过EXPLAIN分析发现有一小段sql扫描了全表，心里想着难道没给这个字段加索引？于是看看对应的表发现虽然没有专门为这个字段加索引，不过这个字段有组合索引，

了解过组合索引的同学知道有个最左原则：
比方说我给a,b,c三个字段建立组合索引，实际上是建立了3个索引：

• a字段索引
• a,b字段索引
• a,b,c字段索引

因此没必要再次建立a和a,b索引，这样的好处能否实现索引覆盖避免回表。

但是为什么这个字段没有用到索引呢？？？

建立索引时还有一个原则是不要给那些值分不太均匀的字段建立索引，比如想gender(性别),要么是M要么是F，或者有同学用1，2区分，这不重要，因为这个性别字段的值分布大约各为50%，这样的话索引是不生效的，因为mysql执行优化器判断走索引的收益大不大，一般来说走索引检索出的结果占总量的30%(记不清了？？？)才会走索引。

但是我这个字段是仓库ID啊，一般来说唯一的，怎么肥四？？我找个值试了一下：

此时的我陷入了沉思，怎么肥四？于是我去表结构看了看这个字段，顿时晴天霹雳，我勒个擦，这尼玛是VARCHAR字符串类型啊！！！

然后机智的我把值前后加上引号变成字符串：

美滋滋，到此谜底揭开了，因为传值时候要注意值类型，如果数据库是字符串类型你传整型或者倒过来，虽然不会报错，但是mysql会隐式转译，这样索引会失效，这个道理呢我是知道的，但我在这里犯下的错误是：先入为主！！！，因为这个老系统不是我做的，因此我也不知道是字符串类型，自以为就当成了整型。
先入为主很可怕，有时候我们在做逻辑时候会因为先入为主产生很多bug，当我们转测时候发现很多先入为主的逻辑错误在修改代码就很麻烦了，因此我们在做逻辑时候不确定的一定要先确定好。
好了，最后本文章我们提炼下关于索引的3个知识点：

1. 组合索引最左原则
2. 不要在值分布就均匀的字段上建立索引
3. 条件传值类型一定要匹配，避免mysql隐式转换