.net Entity Framework(调研的是Entity Framework 4.0) code first方式生成数据库时，不能修改数据库表的索引，而SQLServer默认会把数据表的主键设置为聚集索引，所以Entity Framework如果要修改索引，只能执行sql脚本修改。
这里主要介绍一下调研修改聚集索引来提升查询性能的过程。
系统环境
我们做的是一个form程序，多个客户端直接访问数据库。对于此系统，用户没有需求在短时间内插入大量的数据，只需要满足一般的业务需求即可，但是用户需要一些复杂的查询，有些复杂的查询包括了5个表的查询，这5个表的查询中，有三个表的查询条件加起来有30个，而且每个表还有好多模糊查询（主要是为了用户能查询到数据，所以模糊查询还是必须的）。
我们使用的ORM框架的是.net 的Entity Framework，版本是4.0，开发环境是vs2010，用Entity Framework的code first方式生成数据库，数据库中每张表的主键是无序的GUID。
在开发测试中发现的一些问题
一个系统随着数据量的增加，性能还是很重要的。所以我们在测试的时候，制造了一些数据，用于平时的性能测试。主要的表有20w数据，5个表加起来有70w左右的数据。在测试时，发现在这个数量级的数据下，有些复杂的查询会很慢（每次查询清理数据库缓存来查询，清理缓存的语句：DBCC freeproccache;DBCC dropcleanbuffers;），有的甚至到了20多秒才能查询出来结果，虽然这个查询不是经常使用的查询，但是对于用户来说，肯定体验不够好，于是就开始调研怎么才能查询快一些。
调研过程
首先，想到的是手动编写SQL来代替Entity Framework自动生成的SQL，因为Entity Framework自动生成的SQL经过一系列的转化，最后变得很复杂，而且阅读性不够好。于是手动写了几个sql的查询条件的语句，然后在SqlServer管理界面直接执行脚本，查看手写与Entity Framework生成的同样条件的脚本（Entity Framework生成的脚本是用Sql Server Profiler捕捉得到的）查询性能有多大差距。
得到的结论是手写的脚本比Entity Framework生成的有的提升性能不大，有的反而比Entity Framework生成的还慢了，执行脚本时，也是每次查询都清理数据库缓存。除非对SQL很深入的了解，知道怎么能很好的提升性能，否则自己写的比自动生成的还慢了。对数据库查询比较了解的可以自己尝试一下，看看能不能大幅度提高。
其次，查阅了网上关于SQL提升查询性能的文章，大多提到的是设置正确的索引能提升性能，对我帮助很大的是这几个网页：
http://www.cnblogs.com/marvin/p/4123745.html
http://www.cnblogs.com/chenmh/p/3999475.html
http://www.cnblogs.com/zhouruifu/archive/2012/04/18/2454088.html
我发现我们系统生成的数据库，每张表的Id都是聚集索引，都是无序的GUID，于是就想着更改几张表的聚集索引。刚开始我在查找有没有简单的修改索引的方法，可不可以直接删除聚集索引，然后更改其它某个字段为聚集索引，因为好多表与我们查询的主表有关联，有一些外键，所以索引不能直接删除，除非先把这些外键删除，但是删除外键后担心有些表关联查询就会慢了，于是就开始尝试着先删除使用到这几个表主键作为外键的外键，查找要删除的外键很简单，删除表的主键的聚集索引，会提示有还有哪个外键不能删除，如下图所示。
等所有的约束删除后，主键的聚集索引就可以删除了。注意，删除的时候请记住删除了哪些外键，等修改聚集索引后，还需要把这些删除的外键加上，不知道怎么加外键？请查看每个表的Create语句。
然后选择表的某个字段作为聚集索引，之后再把表的Id修改为非聚集索引。
最后，5个表中，三个表修改好聚集索引后，可以测试性能是否有所提高了。
修改索引的脚本写好后，开始在SQL Server的2005和2008上做测试。
以下是我在SQL Server 2008上测试结果
以下是我在SQL Server 2005上测试结果
测试结论
修改索引后，查询速度比不修改索引时快，速度提高了一半以上，但是插入数据时会相对慢一些，虽然慢一些，但是都是在1秒之内，尤其在Sql Server 2008上比较明显。
当然这个提高幅度不是特别大很多，如果数据量再大一些，到了百万级别，也许这个解决方案可能效果不太明显，百万级别的没有进一步测试。
初次写长篇文章，有些数据不便于与大家分享，欢迎大家提意见和建议，如果有更好的方案来提升性能，那就最好不过了。