建了索引还慢，多半是索引失效（未使用），可用 explain 分析。索引失效常见原因有 :
where 中使用 != 或 <> 或 or 或表达式或函数（左侧）
like 语句 % 开头
字符串未加’’
索引字段区分度过低，如性别
未匹配最左前缀
如果要 MySQL 给一个理由，还是那棵 B+ 树。
函数操作
当在 查询 where = 左侧使用表达式或函数时，如字段 A 为字符串型且有索引, 有 where length(a) = 6查询，这时传递一个 6 到 A 的索引树，不难想象在树的第一层就迷路了。
隐式转换
隐式类型转换和隐式字符编码转换也会导致这个问题。
隐式类型转换对于 JOOQ 这种框架来说一般倒不会出现。
隐式字符编码转换在连表查询时倒可能出现，即连表字段的类型相同但字符编码不同。
破坏了有序性
至于 Like 语句 % 开头、字符串未加 ’’ 原因基本一致，MySQL 认为对索引字段的操作可能会破坏索引有序性就机智的优化掉了。
不过，对于如性别这种区分度过低的字段，索引失效就不是因为这个原因。
为什么索引区分度低的字段不要加索引。盲猜效率低，效率的确低，有时甚至会等于没加。
对于非聚簇索引，是要回表的。假如有 100 条数据，在 sex 字段建立索引，扫描到 51 个 male，需要再回表扫描 51 行。还不如直接来一次全表扫描呢。
所以，InnoDB 引擎对于这种场景就会放弃使用索引，至于区分度多低多少会放弃，大致是某类型的数据占到总的 30% 左右时，就会放弃使用该字段的索引，有兴趣可以试一下。
前面说到大多慢查询都源于索引，怎么建立并用好索引。这里有一些简单的规则。
索引下推：性别字段不适合建索引，但确实存在查询场景怎么办？如果是多条件查询，可以建立联合索引利用该特性优化。
覆盖索引：也是联合索引，查询需要的信息在索引里已经包含了，就不会再回表了。
前缀索引：对于字符串，可以只在前 N 位添加索引，避免不必要的开支。假如的确需要如关键字查询，那交给更合适的如 ES 或许更好。
对于确定的、写多读少的表或者频繁更新的字段都应该考虑索引的维护成本。
原文链接: https://www.yukx.com/bingningm/article/details/2032.html 优科学习网性别字段为什么不适合加索引
