One main difference is that the unique index can have a NULL value that is not allowed in the primary key. Clustered or not, this is the main difference between the practical implementation of a Primary Key versus a Unique Key.
Oh, and the fact that a table can have one PK and many UK :-).
These are both differences in INTENT not in PERFORMANCE.
Otherwise, I don't think there's any difference.
Behind any PK or UK the SQL Server builds an index (depending on the request, clustered or not) and the way it's used is transparent for the source is coming from.
Primary index
A primary index is an index on a set of fields that includes
the unique primary key for the field and is guaranteed not to contain duplicates.
Also Called a Clustered index.
eg. Employee ID can be Example of it.
Secondary index
A Secondary index is an index that is not a primary index and may have duplicates.
eg. Employee name can be example of it. Because Employee name can have similar values.
Dense Index
Index record appears for every search key value in the file.
Dense indexes point directly to individual records.
Sparse index
contains index records for only some search key values.
Applicable when records are sequentially ordered on search key.
Just as with book indexes, sparse database indexes don’t point to individual records, but to ‘pages'
Best Answer
And it looks like curiosity didn't actually kill the cat :-). So I found this book Database System Concepts (Sixth Edition) online and it's freely available to be read. I've scratched it a bit and it turns out that it has the needed definition inside:
So there you have it. Now I suppose you were reading another book (by same author(s)) which was with tests inside (Q&A) and not this one with theory. I'd say you should use them both at the same time.
Now, I'm not sure that a general book would be the best way to start. Personally I'd start with any freely available kit (SQL Server Express, MySQL Lamp, Oracle XE, SQLite...whatever sounds good for your ear) and play with concepts and also their physical implementation. I'd say going also with examples will work better than just pure theory.