内容查询Web部件（Content Query Web Part，或简称CQWP）自从在2007引入SharePoint（企业版）以来，受到了无数人的关注。一方面因为其跨网站、跨列表查询的能力、样式订制扩展的能力，另一方面也因为各种各样的Bug。
其中最“臭名昭著”的一个Bug，就是在查询的列表超过10个的时候，可能无法返回完整的结果，这个是由于其核心的SPSiteDataQuery的Bug造成的（微软已经确定声明这个Bug，详见：http://support.microsoft.com/kb/946484）
最近的一个项目是用到了2010，在类似需求的场景中，使用了另外一个API - CrossListQuery，这个同样是CQWP的核心查询，是对SPSiteDataQuery的一个封装，利用了对象缓存的功能，可以在服务器端缓存查询结果，以此来提高查询性能，这三者的关系基本上可以用下图来表示：
因为担心上面提到的那个Bug，我还专门用SPSiteDataQuery测试了一下，当超过10个文档库并且有不同字段设置的时候，可以查询到完整结果。
于是很Happy的就用了，然后上线了，然后客户开始迁移数据，当迁移到10万+文档的时候，客户过来找我，说首页的“最新更新”内容都不见了……
于是在解决这个问题的过程中，我陆陆续续发现了如下莫名其妙的现象：
1、同样的查询条件，RowLimit限制为5，返回0个结果；RowLimit为24，返回2个结果；RowLimit为30，返回5个结果；RowLimit为50，返回50个结果……
2、同样的查询条件，使用修改时间排序的时候，不返回任何结果；使用我自己定义的一个字段排序的时候，正常；使用ID排序的时候，正常……
3、同样的查询条件和排序条件，使用系统账户的时候，一切正常；使用另一个完全控制权限（通过Web应用程序策略设置）的账号，不返回任何结果……
通过上述现象的观察，基本上确定了不是我们自己的代码造成的问题，为了进一步验证这一点，我直接使用了CQWP，现象同上。
上述经验表明，CQWP是个大坑（网上搜CQWP + Bug，可以找到各种各样诡异的现象），尤其在大数据量的时候，慎用。
btw，最后我们的解决办法，就是无论页面上需要显示多少个结果（首页是5个），都强制后台查询的RowLimit为50，然后在前台扔掉后45个……
btw2，SharePoint 2013中引入了CQWP的一个替代品，Content Search Web Part，这个是基于搜索的，也很有意思，有机会专门分享一下这个东西。