I don't think I'd call this a bug. SQL Server can use the Primary Key or a Unique Constraint/index to as the reference column(s) for a foreign key. In this case (or these cases for those who have experienced it), SQL Server is probably using a unique clustered index to enforce a foreign key because it believes that it will improve performance. I'd have to assume that the lead column in the unique clustered index is the same column as the primary key. I'd be checking to see if both indexes are needed and perhaps make the unique clustered index the PK.