为何USER_ID列在索引表中同时存在唯一与非唯一索引？

• 适配不同查询场景：联合索引AD_ID（比如结构是(USER_ID, 其他字段)）只能高效处理以USER_ID开头的联合查询，比如WHERE USER_ID = ? AND AD_STATUS = ?这类语句。但如果系统里有大量只针对USER_ID的单条件查询（比如SELECT nickname FROM users WHERE USER_ID = ?），单独的USER_ID索引能直接覆盖这类请求，不用走联合索引的回表步骤，也不会浪费资源去匹配联合索引里的其他字段。
• 提升缓存与查询效率：独立的USER_ID索引体积更小，只存储USER_ID和主键值，相比包含多列的联合索引，更容易被数据库缓存到内存里，相同内存空间能缓存更多索引数据，查询时的IO开销更低，速度更快。
• 历史遗留或迭代问题：大概率是系统迭代过程中留下的——前期可能只建了联合索引满足特定业务查询，后来新增了大量单独查USER_ID的场景，直接加了独立索引；也可能是不同开发人员在不同阶段分别创建，没做索引梳理导致重复。
• 优化锁粒度：在部分数据库中，用独立索引定位数据行时，锁的范围会更精准。比如针对USER_ID的更新操作，用独立索引找到目标行后，锁的范围比用联合索引更小，能减少锁冲突，提升并发性能。
• 支持排序/分组需求：如果有单独对USER_ID排序或分组的场景（比如ORDER BY USER_ID LIMIT 100），独立索引本身是有序的，数据库可以直接遍历索引得到结果，不用额外做排序操作；而联合索引如果后续列不参与排序，数据库可能需要临时排序，效率差很多。

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