索引选择性是唯一值数量与总行数的比值，比值越高，索引效率越高；应优先在高选择性列如用户ID、订单号上建索引，避免在性别、状态等低基数列单独建索引，否则易被优化器忽略。
索引选择性是指索引列中不同值的数量与表中总行数的比值，通常用公式：选择性 = 唯一值数量 / 总行数。选择性越高，说明该列区分度越好，索引的效率也越高。在MySQL中，高选择性的索引能显著提升查询性能，因为优化器可以更精准地定位目标数据，减少扫描的行数。
索引选择性对查询的影响
当一个索引的选择性很高时（接近1），意味着大多数记录的索引值是唯一的，比如主键或身份证号。这种情况下，使用该索引进行查询可以快速定位到具体行，极大减少IO和CPU开销。
相反，如果索引选择性很低（例如性别、状态标志等只有几个取值的字段），即使建立了索引，优化器也可能选择不使用它，转而进行全表扫描。因为读取索引再回表的成本可能高于直接扫描整个表。
常见影响包括：- 低选择性索引容易被优化器忽略，导致索引失效
- 组合索引中列的顺序若未按选择性高低排列，可能导致无法充分利用索引
- 在WHERE条件中对低选择性列先过滤，可能无法有效缩小结果集
提高索引选择性的优化方法
为了最大化索引效率，应优先在高选择性的列上创建索引，并合理设计复合索引结构。
1. 优先为高选择性列建立索引
- 如用户ID、订单编号、手机号等唯一或接近唯一的字段
- 可通过SQL估算选择性：
SELECT COUNT(DISTINCT column_name) / COUNT(*) FROM table_name;
- 将选择性高的列放在复合索引的前面
- 例如，(user_id, status) 比 (status, user_id) 更高效，因为user_id选择性远高于status
- 遵循“最左前缀”原则的同时兼顾选择性分布
- 如枚举类型、布尔字段、状态码等，单独建索引意义不大
- 可作为复合索引的后续列使用，而非独立索引
- 对于VARCHAR(255)类字段（如email、url），可创建前缀索引：
CREATE INDEX idx_email ON users(email(8)); - 需权衡前缀长度与选择性，确保截取部分仍具备足够区分度
- 执行
ANALYZE TABLE table_name;更新索引基数统计 - 帮助优化器更准确判断索引选择性，做出正确执行计划
实际案例参考
假设有一张用户表users，包含字段：id（主键）、name、gender（男/女）、created_at。
- gender选择性极低，单独建索引无效
- 若常按时间范围查某个性别用户，应建复合索引：
(created_at, gender) - 尽管gender选择性低，但在created_at已筛选出小范围后，gender可进一步过滤，此时仍有作用
基本上就这些。关键是理解选择性本质是“区分能力”，结合查询模式设计索引，而不是盲目为所有WHERE字段加索引。
