查询： 按 ID 选择 选择哪里 ColumnValue = X 按 OrderId 分组 按日期分组
SP 列表将有 6 列宽：Id、Date、OrderId（查找）、Quantity、ItemName、Title
【问题讨论】：
标签： sql-server performance sharepoint list
不要这样做。 SharePoint 不擅长处理事务性数据并且会表现不佳。
您可能需要在数据库级别提高性能的任何能力（例如添加索引）都可能对 SharePoint 安装产生不利影响（尽管可以通过 SharePoint “索引”列表中的列。
基本上，SharePoint 是为特定目的（内容/文档）而设计的，试图让它做一些与众不同的事情意味着您必须与应用程序作斗争。
幸运的是，SharePoint 有多种方法可以将交易数据集成到其中。
首先（如果您拥有更昂贵的企业许可证），您拥有业务数据目录，允许您导入与列表项类似的数据库值。
如果您没有企业许可证，我可以推荐自定义控件/webpart 或数据视图 Web 部件，以允许该数据“显示”在 SharePoint 的相关页面上。
总结： 与在传统数据库应用程序中托管数据并集成到 SharePoint 的其他应用程序设计相比，您将通过在 SharePoint 中存储事务数据来为自己做很多不必要的工作。
【讨论】：
我同意上述所有 cmets。我有丰富的客户经验，他们希望将 SharePoint 列表用于他们不适合的事情。如果您完全担心性能，那么 SharePoint 列表就不是好办法。如果它只是出于存档目的，并且您不经常对数据进行搜索，并且 SharePoint 搜索功能对您来说就足够了，那么我可能会考虑它并且不会立即将其忽略（如果您使用的是 MOSS）。
但我会仔细考虑这方面的所有方面。通过 Data Form Web Parts 和 BDC 将 SQL server 数据导入 SharePoint 环境并不太难，但将 SharePoint 数据导入其他平台或应用程序则比较困难。
再说一次，如果根本就需要性能，那就不要这样做。
有关 SharePoint 可扩展性和性能最佳实践的更多信息，请参阅： http://technet.microsoft.com/en-us/library/cc287790.aspx
【讨论】：
出于性能原因，经验法则是将 SharePoint 列表限制为 2000 个项目。
在 100k 时，性能会“从烂到爆”。
唯一可行的方法是将数据集分割成多个列表，每个列表少于 2000 个。
【讨论】：
当然，建议的方法不推荐。
但是，作为主题，here 是 WSS 中大型列表性能的好文档
【讨论】：
SharePoint 列表会变慢。
更多的开销 = 更差的性能。
【讨论】：
+1 否
SharePoint 的主要功能是协作。在您的情况下，您只需将数据列为只读。在您的情况下，我建议将数据存储到 SQL DB 中，如果您需要在 SharePoint 门户中显示它，您可以使用 BDC 或 Bamboo Data View Web 部件之类的东西。 http://store.bamboosolutions.com/p-71-data-viewer-web-part.aspx
【讨论】：
我也同意上面的人 但是 - 博客中讨论的许多性能问题都是由于未正确使用 SharePoint 对象模型造成的。
您可以在 dynaTrace 博客上查看我关于 SharePoint 列表性能的博客系列。 本系列研究 SharePoint 对象模型，重点介绍 SharePoint 服务器和内容数据库之间的实际情况
【讨论】：
我自己做了这件事，我想说尽量避免它！这是一个雷区，尤其是在大约 100,000 行之后。
最终也会让你感到痛苦的是，搜索爬虫可能会在尝试爬取非常大的列表时开始超时 - 你可以增加超时，但这是一场失败的战斗的开始。
【讨论】：