为全唯一值列创建索引是否值得？能否提升SELECT性能？

当然有价值！而且对于非主键的唯一ID这类**高基数（每条值都唯一）**的列来说，创建索引带来的SELECT性能提升甚至比status这种低基数列更显著——咱们从索引的工作原理拆解来看：

一、为什么唯一值列建索引很有必要？ #

• 索引就是数据库的“快速查找目录”：不管列的基数高低，索引都能帮数据库绕开耗时的全表扫描，直接定位目标数据。而唯一值列的索引因为每条值对应唯一一行，查找效率是天花板级别的。
• 彻底告别全表扫描：拿100万条记录的表来说，全表扫描要遍历所有行，而唯一索引的查找是O(log n)的时间复杂度——相当于只需要遍历几十次就能找到目标，速度差了好几个数量级。
• 额外的约束buff：如果建的是UNIQUE INDEX，还能自动保证列的唯一性，相当于同时给数据加了完整性约束，一举两得。

二、非主键唯一ID列的SELECT性能表现 #

假设你的表有100万条记录，非主键的唯一ID列（比如user_uuid）建了索引：

• 单条精准查询：执行SELECT * FROM your_table WHERE unique_id = 'xxx'时，数据库会直接通过索引定位到唯一的一行，速度快到离谱——甚至比查status列的FAILED还要快，因为status查询可能要返回成百上千条匹配行，而唯一ID只返回1行，索引定位后不需要额外的行遍历。
• 范围查询：如果是SELECT * FROM your_table WHERE unique_id > 'a123' AND unique_id < 'z456'，索引也能快速锁定范围的起始和结束位置，只扫描范围内的行，而非全表。
• 和主键索引的差异：非主键的唯一索引和主键索引性能几乎没差，唯一区别是InnoDB引擎下主键索引是聚簇索引（数据行直接存在索引叶子节点），非主键唯一索引的叶子节点存的是主键值，需要再做一次回表查询——但这个回表的开销极小，单条查询几乎可以忽略不计。

三、和低基数列（如status）的索引对比 #

你提到的status列只有3种值，属于低基数列：

• 当查询WHERE status = 'FAILED'时，如果FAILED的记录占比很高（比如30%），数据库可能会放弃用索引，因为遍历索引再回表的开销比直接扫表还大；只有当FAILED占比很低（比如1%）时，索引才会真正发挥作用。
• 而唯一值列的查询，不管什么时候数据库都会优先用索引，因为目标行唯一，索引的优势能完全发挥，不存在“索引是否被选用”的不确定性。

总结 #

• 为唯一值列创建索引绝对有价值，尤其是非主键的唯一ID列，能极大提升SELECT查询的性能。
• 唯一值列的索引性能比低基数列更稳定、更高效，不会出现“索引失效”的尴尬情况。
• 如果业务上需要保证该列的唯一性，直接建UNIQUE INDEX，既加了数据约束又提升了查询速度。

内容的提问来源于stack exchange，提问作者hieinji