结论（以innodb为例）

a、非聚簇索引存储了对主键的引用，如果select字段不在非聚簇索引内，就需要跳到主键索引（上图中从右边的索引树跳到左边的索引树），再获取select字段值

b、如果非聚簇索引值重复率高，那么查询时就会大量出现上图中从右边跳到左边的情况，导致整个流程很慢

c、如果where值重复率高的字段，select用了limit，只查较少数据，也就是跳的次数很少的情况下，还是可以建索引的（后来想想也没必要，limit限制了数量，全表扫描也很快，除非字段值是排序的，必须扫描完前面的所有值）

d、如果没有3这个前提，则不建议在值重复率高的字段上建索引，因为查询效率低，还需要维护索引

以性别字段为例：

表名：sex
	
字段名：sex
	
字段值：男或女


查询语句
-- 查询性别字段中男性字段值与女性字段值的比例
SELECT sum(CASE when sex='男' then 1 ELSE 0 END)/sum(CASE when sex='女' then 1 ELSE 0 END) from sex;
-- 查询性别字段中男性字段值在字段值的总数中的占比
SELECT sum(CASE when sex='男' then 1 ELSE 0 END)/COUNT(*) from sex;
-- 查询性别字段对应的字段值的总数
SELECT COUNT(*) from sex;
-- 查询性别字段中男性字段值的总数
SELECT sum(CASE when sex='男' then 1 ELSE 0 END) from sex;

结果
男性/女性=2.6667
	
男性/总人数=0.7273
	
总人数=11
	
男性人数=8

理论文章会告诉你值重复率高的字段不适合建索引。不要说性别字段只有两个值，网友亲测，一个字段使用拼音首字母做值，共有26种可能，加上索引后，百万加的数据量，使用索引的速度比不使用索引要慢！
一个表可能会涉及两个数据结构(文件)，一个是表本身，存放表中的数据，另一个是索引。索引是什么？它就是把一个或几个字段（组合索引）按规律排列起来，再附上该字段所在行数据的物理地址（位于表中）。比如我们有个字段是年龄，如果要选取某个年龄段的所有行，那么一般情况下可能需要进行一次全表扫描。但如果以这个年龄段建个索引，那么索引中会按年龄值建一个排列，这样在索引中就能迅速定位，不需要进行全表扫描。
为什么性别不适合建索引呢？因为你访问索引需要付出额外的IO开销，你从索引中拿到的只是地址，要想真正访问到数据还是要对表进行一次IO。假如你要从表的100万行数据中取几个数据，那么利用索引迅速定位，访问索引的这IO开销就非常值了。但如果你是从100万行数据中取50万行数据，就比如性别字段，那你相对需要访问50万次索引，再访问50万次表，加起来的开销并不会比直接对表进行一次完整扫描小。
当然凡事不是绝对，如果把性别字段设为表的聚集索引，那么就肯定能加快大约一半该字段的查询速度了。聚集索引指的是表本身中数据按哪个字段的值来进行排序。因此，聚集索引只能有一个，而且使用聚集索引不会付出额外IO开销。当然你得能舍得把聚集索引这么宝贵资源用到性别字段上。
参考文章：
https://www.cnblogs.com/sunxi/p/4011592.html
http://www.cnblogs.com/Lovepanda/archive/2010/03/24/MySql.html

大家都知道索引分聚集索引和非聚集索引，性别字段因为可重复肯定只能建立非聚集索引，然而因为非聚集索引叶子节点存储的是索引值和聚集索引值，需要回表。所以在性别这种辨别度较低的字段上建立索引，索引树可能只有两个节点，跟线性查找没有太大区别，并且因为回表的存在导致在聚集索引树和非聚集索引树来回切换反而导致查询时间更慢。并且维护该索引还要一定的开销。另外，数据库优化器最终很大概率也不会选择走这个索引。综上，在辨别度较低的字段上建立索引得不偿失。
但是，并不是通用规则！
若这些可选择性非常低的字段，在其中的一种分布非常少，而且查询非常频繁的话，可以对该字段进行索引！
比如有一个枚举字段[1,2,3], 在上百万行数据中，1占1%， 2占%2， 3占%97，然后业务经常需要查询1和2的数据，那么就可以在该字段进行索引。