server2008中guid做主键跟聚集索引是否合适

server2008中guid做主键和聚集索引是否合适？
单表的数据可能会达到2000万，会有多个表之间的关联查询，多用户同时几百条的数据插入，如下建表，guid做主键和聚集索引，对性能有多大影响？
CREATE TABLE Test_Guid
(
Guid uniqueidentifier not null default(newsequentialid()),
TestId int not null,
TestText ntext not null,
TestDateTime datetime default getdate(),
    CONSTRAINT PK_Guid PRIMARY KEY (Guid)
)
GO
主要是想了解一下在实际项目中有没有人采用这种方式，那种简单的增加10万条记录的也测试过，guid大多情况会比int 慢那么一点点，如果数量到了千万级或亿万级，表又是很多的时候，性能会有多大影响呢？
------解决思路----------------------
看你是单线程测试还是多线程测试

网上有非常多的测试资料，大概原理你知道了，甚至有很多相反的结论，如果再分场景看，明白其中的原理，就不会有那么多的疑惑了

1，首先从主键方面说，int做id和guid做主键，相比来说int肯定占优势，因为int是四个字节，guid是16个字节，当然现实情况中也有出现int满了，装不下更多数据的情况，可以换做bigint
2，从聚集索引看，int适合，这里只是跟guid相比，guid是随机的，作为聚集索引，必然会引起大量的也拆分和碎片，对数据的读取有致命的伤害
3，从插入数据来看，如果是有并发的情况，guid比较有优势，因为int自增id做聚集索引的情况下，并发写入的时候必然会引起热点页问题，也就是说多个会话的都相对集中地网一个区域插入数据，插入数据的时候是有一个page级别的不兼容的锁的。这会引起插入的效率遍地。对于guid来说，因为是随机的，可以将多个会话的写入动作分散到多个数据页上，这一点看是guid的优势

以上是我简单想到的，实际情况来看，个人认为这两个ID结合起来使用更好，用guid做主键，不做聚集索引，用int ID 做聚集索引，当然根据业务情况，更多的时候是把创建时间之类的递增的列做聚集索引，查询的时候可以更好地使用到聚集索引。

你可以参考微软给出的实例数据库，看看人家是怎么设计的。