主键(PRIMARY KEY)与聚集索引(Clustered Index)的对比可以参看我之前的博客：SQL Server 索引基础知识(4)----主键与聚集索引
一个表最多一个主键，最多一个聚集索引。
数据库在创建主键同时，会自动建立一个唯一索引。如果这个表之前没有聚集索引，同时建立主键时候没有强制指定使用非聚集索引，则建立主键时候，同时建立一个唯一的聚集索引。
所以建立主键(PRIMARY KEY)与聚集索引(Clustered Index)的先后顺序就只有下面几种情况：
为了更方面的描述，假设我们有如下表：
CREATE TABLE [dbo].[User]( [UserName] [nvarchar](10) NOT NULL, [Email] [nvarchar](100) NULL ) ON [PRIMARY] GO
情况一、在没有任何索引的表上建主键，同时自动产生唯一的聚集索引。
这种情况最简单。在表设计中，通过下图方式设置主键，同时不做任何其他修改，就会在建主键的同时，自动建立了唯一的聚集索引。
同时自动建立的主键和聚集索引
情况二、在没有任何索引的表上先建聚集索引，再建主键。
我们如下面2幅图方式创建索引：
这个索引的参数设置如下图：
这个聚集索引创建好后如下：
这时候，我们再按照情况一的方式在表设计中创建主键。
完成后，主建和索引的情况如下图：
显然，这种情况下在创建主键的同时，建立了一个唯一的非聚集索引。
上面演示情况下，显然 PK_User 这个唯一的非聚集索引没有任何存在的价值。
情况三、在有非聚集索引表（即堆）上，先建主键。
情况三和情况四的初始环境都如下，存在一个非聚集索引。
结果如下，类似于情况一，建主键时自动建立一个唯一的聚集索引。
需要注意的是：
没有聚集索引,有非聚集索引的表非聚集索引的行指针会指向数据堆，聚集索引重建时非聚集索引的行指针又会指回聚集索引的行位置。建聚集索引会导致现有的非聚集索引全部重新组织一边。
情况四，在有非聚集索引的表，先建聚集索引，再建主键。
这时候的结果如下图：
类似于情况二。
其他情况：
其他情况都可以归入上述四类。
比如：在一个同时存在聚集索引，非聚集索引的表上建主键，就可以归入情况二。
参考资料：
SQL Server 索引基础知识(2)----聚集索引，非聚集索引
http://blog.joycode.com/ghj/archive/2008/01/02/113291.aspx
如何修改主键 (Visual Database Tools)
http://technet.microsoft.com/zh-cn/library/ms189251.aspx