结论（以innodb为例）
 
a、非聚簇索引存储了对主键的引用，如果select字段不在非聚簇索引内，就需要跳到主键索引（上图中从右边的索引树跳到左边的索引树），再获取select字段值
 
b、如果非聚簇索引值重复率高，那么查询时就会大量出现上图中从右边跳到左边的情况，导致整个流程很慢
 
c、如果where值重复率高的字段，select用了limit，只查较少数据，也就是跳的次数很少的情况下，还是可以建索引的（后来想想也没必要，limit限制了数量，全表扫描也很快，除非字段值是排序的，必须扫描完前面的所有值）
 
d、如果没有3这个前提，则不建议在值重复率高的字段上建索引，因为查询效率低，还需要维护索引

create table tb_Test
(
    char sex  check sex in('男'，‘女’)//设置性别只能为男，女
)
 
字段取值为0,1
 
将字段定义为BIT数据类型，如
create table 你的表名
(
字段1 varchar(20),
字段2 bit
)

 
 

  create 
  table 
  学生表
 
 

  (
 
 

  学号 
  char
  (5) 
  not 
  null 
  primary 
  key
  ,
 
 

  姓名 
  varchar
  (10) 
  not 
  null
  ,
 
 

  性别 
  char
  (2) 
  default 
  '男' 
  check 
  (性别 
  in 
  (
  '男'
  ,
  '女'
  ))
 
 

  )
 
 其中default '男'  就是默认为男
check (性别 in ('男','女') 就是性别只可以为男或女
 
 
在数据库取值为哦0，1在显示出男女
if(SEX=1) return 男 else return 女
如何设置性别 “1：男，0：女，默认1“
  

   
   
你可以在数据库中建一个字段sex设置数据类型为bit或char(2),然后在下边“列属性”中设置该字段的默认值为1；或用语句来做 create table [表名](sex bit default '1')
   

  
这样做，只是因为性别只有2种情况，所以用bit类型的1和0表示，取数据的时候，还是要根据1和0判断是男是女。。。
select 
case when Sex=1 then'男' when Sex=100 then '女' end
from Users
select t....,t...., case t.gender when '1' then '男' else '女' end as gender from xxx t

表users
字段
ID int
UserName varchar(50)
PassWord varchar(50)

在保证ID为主键的情况下，如何让UserName输入的数据不重复。
为username指定一个唯一约束.
alter table [users ]add constraint cons_01 unique (UserName) 

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

理论文章会告诉你值重复率高的字段不适合建索引。不要说性别字段只有两个值，网友亲测，一个字段使用拼音首字母做值，共有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