MySQL中，性别列（男，女）为什么不适合建索引？

1. 低区分度问题

   • 当某个列的唯一值比例（Cardinality）过低时（如性别列仅有2种值），索引的筛选效率会显著下降
   • 假设表中有100万条数据，使用性别索引查询时：

     SELECT * FROM users WHERE gender = '男'
     

     可能返回约50万条记录，此时：
     • 索引需要执行50万次回表查询（随机I/O）
     • 全表扫描只需一次顺序I/O即可完成

2. 索引维护成本

   • 每次INSERT/UPDATE/DELETE操作都需要维护索引
   • 当索引带来的查询优化收益 < 维护成本时，索引反而成为性能负担

3. 优化器选择策略

   • MySQL优化器发现使用索引的成本高于全表扫描时（通常当筛选比例>30%），会自动放弃使用索引
   • 可通过EXPLAIN验证：

     EXPLAIN SELECT * FROM users WHERE gender = '男'
     

     输出结果中的type列会显示ALL（全表扫描）

4. 存储空间浪费

   • 每个索引需要占用约表数据量的5-15%存储空间
   • 对于百万级表，性别索引可能浪费数十MB存储空间

例外情况（合理使用场景）：

• 组合索引：当性别与其他高区分度列组合查询时

  -- 组合索引 (gender, age)
  SELECT * FROM users 
  WHERE gender = '女' AND age BETWEEN 20 AND 30
  

• 极端数据倾斜：如99%为男性，需要频繁查询1%的女性数据
• 覆盖索引：当查询仅需要返回性别列本身时

  SELECT gender FROM users WHERE gender = '男'
  

建议解决方案：

1. 避免单独为低区分度列创建索引
2. 优先考虑组合索引策略
3. 使用枚举类型存储性别（ENUM('男','女')）可节省存储空间
4. 对于高频查询需求，可考虑：

   ALTER TABLE users 
   ADD INDEX idx_gender_name (gender, name)  -- 组合索引示例
   

性能对比实验：

-- 创建测试表
CREATE TABLE user_test (
  id INT PRIMARY KEY AUTO_INCREMENT,
  gender ENUM('男','女') NOT NULL,
  INDEX idx_gender (gender)
) ENGINE=InnoDB;

-- 插入100万测试数据（50%男，50%女）
INSERT INTO user_test (gender) 
SELECT IF(RAND() < 0.5, '男', '女') FROM information_schema.columns a, information_schema.columns b LIMIT 1000000;

-- 禁用查询缓存
SET SESSION query_cache_type = OFF;

-- 使用索引查询（执行时间约120ms）
SELECT SQL_NO_CACHE * FROM user_test WHERE gender = '男';

-- 强制全表扫描（执行时间约80ms）
SELECT SQL_NO_CACHE * FROM user_test IGNORE INDEX(idx_gender) WHERE gender = '男';

实验结果显示，在这种场景下全表扫描比使用索引快约33%。这说明对于低区分度列，索引反而可能降低查询性能。