有两个 Web 部件可用于在 SharePoint 网站上搜索数据。 它们非常相似： 内容查询 Web 部件 (CQWP) 和 内容搜索 Web 部件 (CSWP) 。 仅从这两个部件的名称不太容易分辨这两者的区别。
在大多数情况下，我们建议使用内容搜索 Web 部件，因为它不会像内容查询 Web 部件那样影响性能。
请务必了解这两个 Web 部件的优点和限制。 在大多数情况下，我们建议使用内容搜索 Web 部件，因为它不会像内容查询 Web 部件那样影响性能。
-
如果已有内容不多，查询简单，并且预计内容在将来增长幅度不大，请使用 CQWP。
-
其他所有情况下如果希望显示基于查询的内容，请使用 CSWP。
下表提供了这两个 Web 部件之间的比较：
|
Web 部件的行为 |
内容查询 Web 部件 |
内容搜索 Web 部件 |
|---|---|---|
|
查询配置 |
简单 |
你需要了解某些搜索功能，例如 在 SharePoint Online 中管理搜索架构。 |
|
在大量内容中进行查询 |
受限 |
是 |
|
处理复杂查询 |
受限 |
是 |
|
可灵活应对内容将来的增多 |
受限 |
是 |
|
显示其他网站集中的内容 |
否 |
是 (请参阅 “使用内容搜索 Web 部件”显示下面其他网站集的内容) |
|
可自定义查询结果的设计 |
是，通过使用 XSLT。 |
是，通过使用 HTML。 |
|
复杂站点体系结构中的维护成本 |
高 |
小型 (请参阅 使用内容搜索 Web 部件将维护成本降低到) |
|
缩小 Web 部件中所显示的查询结果范围 |
否 |
是，在与优化 Web 部件结合使用时。 |
这两个 Web 部件都可以用于显示子网站中存储的内容。 内容作者和主站点访问者的用户体验完全相同，不受所用 Web 部件的影响。 这两个 Web 部件之间的区别在于各自使用的技术。 CQWP 查询数据库，而 CSWP 则查询搜索索引。
下面是这些 Web 部件的行为方式示例。 示例 A 显示一家公司正在使用 CQWP 显示其销售子网站中的内容，而示例 B 则显示一家公司使用 CSWP 显示其销售子网站中的内容。
|
图像标注 |
示例 A： |
示例 B： |
|---|---|---|
|
1 |
在列表中创作内容。 |
在列表中创作内容。 |
|
2 |
列表项立即存储到数据库中。 |
在设置的时间间隔内，列表项将自动爬网并添加到搜索索引中。 |
|
3 |
访问者查看主站点。 CQWP 自动向数据库发出查询。 |
访问者查看主站点。 CSWP 自动向搜索索引发出查询。 |
|
4 |
数据库返回查询结果并将其显示在 CQWP 中。 |
搜索索引返回查询结果并将其显示在 CSWP 中。 |
由于这两个 Web 部件使用不同技术，所以何时应选择其中一个 Web 部件，而不是使用另一个的用例有所不同。 用例通常比上一部分中显示的简单示例更复杂。 决定使用哪个 Web 部件之前，请务必注意以下事项：
-
内容有多少？
-
查询有多复杂？
-
内容将存储在哪里？
-
一段时间之后内容会增长多少？
-
一段时间之后维护成本会增加多少？
我们建议将以上所有事项作为整体解决，而不是单独解决。
注意: 如果您考虑从 SharePoint 内部网站移到 SharePoint Online 网站，并且您在 SharePoint 内部网站上使用的是 CQWP，您可能会遇到一些性能问题。 在 SharePoint Online 中，您将不能调整租户来提高性能。 此外，缓存功能在 SharePoint Online 网站中和 SharePoint 内部网站中的行为也不同。
影响内容查询 Web 部件性能的原因
在上面的示例中，如果“新闻”列表中包含的项目不到 5000 条，CQWP 的效果可能非常好。 但是，如果“新闻”列表中包含的项目超过 5000 条，而 CQWP 中的查询很复杂，该 Web 部件可能会遇到性能问题。 很难确切定义复杂查询，但是要在您的站点集中的所有站点内查询的源比查询特定列表的源更为复杂。 此外，如果查询使用“其他筛选器”，将增加查询的复杂程度。 查询的复杂程度将根据所用站点列类型和条件而增加。 下面提供了几个示例：
-
与筛选类型为“是/否”的站点列的查询相比，在多行文本的站点列上进行筛选的查询更为复杂。
-
使用包含条件的筛选器比使用等于条件的查询更为复杂。
-
或条件越多，查询的复杂程度越高。
CQWP 的性能也受内容的存储位置影响。 如果您的内容存储在多个站点中，Web 部件必须处理的列表项总量将影响其性能。 例如，在公司的主站点中，您希望显示保留在多个子站点中的列表内的最新新闻项。 每个列表中包含 1000 项。 这意味着 CQWP 必须在 3000 项中查询。
在本示例中，只要总项数低于 5000，CQWP 的性能就可能很好。 但是如果查询很复杂，即使总项数只有几千，CQWP 也可能遇到性能问题。
可能影响 CQWP 性能的另一个重要因素是内容是否增长。 目前效果很好的解决方案未必适合将来的内容。 如果您预计站点数或内容量会大大增加，则不应使用 CQWP。
这两个 Web 部件都可以用于显示基于网站导航产生的信息的内容。 例如，当访问者转到某个页面时，该页面上的 Web 部件将自动发出一个查询，该查询中包含网站导航产生的信息。 搜索结果在该 Web 部件中显示。 如果您的内容不多，查询又简单，则可以使用多个 CQWP 来显示您的内容。 但是，由于必须单独维护每个 CQWP，所以维护成本可能会迅速上升。
通过将 CSWP 与托管导航和类别页面配合使用，维护成本将不受内容增多的影响。 例如，如果向内容添加一个新导航类别，您可以使用相同的类别页面来显示属于这个新导航类别的内容。 因此，即使您的内容在增长，您也只需要维护相同的页数。
有关详细信息，请参阅以下附加文章：
在下面的示例中，您可以看到四个 CQWP 如何被类别页面上的一个 CSWP 取代。
您可以使用 CSWP 显示其他网站集中的内容。 例如，如果您希望在一个网站集中创作内容，并将创建的内容在另一个网站集中显示，则必须使用 CSWP。 CQWP 只能显示一个网站集中的内容。
如果您不确定要使用哪个 Web 部件，CSWP 在大多数情况下可能都是最佳选择。 此 Web 部件比 CQWP 更灵活，因此如果您计划随着时间的推移扩展内容，此 Web 部件可以提供更好的性能结果。
如果您决定使用 CQWP，我们建议您执行测试以了解该 Web 部件是否符合您当前和将来的性能和维护要求。
