提高大型数据集的搜索性能

Question

在已经投入生产的WPF应用程序中，用户有一个窗口，用于选择客户端。 它显示包含所有客户端的列表和可以搜索客户端的TextBox。

随着客户群的增加，这种速度异常缓慢。 大约1分钟的操作，每天发生约100次。

目前MSSQL管理工作室表示查询select id, name, birth_date from client需要41秒才能执行（大约130000行）。

关于如何改善这段时间有什么建议吗？ 代码上的索引，ORM或直接sql查询？

目前我正在使用框架3.5和LinqToSql

Answer 1

如果您的查询实际上是SELECT id, name, birth_date from client （即，没有where子句），那么您将能够做的很少，以加快新硬件的速度。 SQL Server必须进行表扫描才能获得所有数据。 即使覆盖索引也意味着它必须扫描与表一样大的索引。

您需要问自己的是：130000个客户列表对您的用户真正有用吗？ 我真的要滚动到列表中的第75613条，找到他们想要的用户吗？ 答案可能不是。 我只会选择搜索选项。 至少那时你可以添加对这些查询有意义的索引。

如果您确实需要整个列表，请尝试以块的形式加载它。 从前500条记录开始，然后在用户移动滚动条时添加更多记录。 这样，初始加载时间减少，用户只加载必要的数据。

Answer 2

为什么需要所有客户的清单？ 难道你不能只拥有你描述的搜索TextBox并在服务器端处理搜索查询。 在那里，您为单个客户端搜索的最大返回行数设置上限（例如，最多500个匹配）。

或者，可以通过在Web服务器上缓存客户端数据列表来获得一些效率增益

Answer 3

根据您的查询，索引应该没有帮助。 您可以使用一个缓存已排序查询的视图（假设您没有按ID排序？），但鉴于SQL Server的adhoc查询的烘焙查询缓存，您可能不会在那里看到太大的收益。 ORM确实增加了一些开销，但是有一些教程可以降低成本（例如http://www.sidarok.com/web/blog/content/2008/05/02/10-tips-to-改进你的linq-to-sql-application-performance.html ）。 适用于您的要点是尽可能使用已编译的查询，并为只读数据关闭乐观并发。

通过让您的客户端不直接访问数据库，可以实现更大的性能提升。 如果你在那里添加一个服务层（不一定是web服务，但它可能是），那么服务类或应用程序可以放置一些智能缓存，这对于像这样的只读查询有一个数量级的帮助。

Answer 4

进入SQL Server，进行新的查询。 在“查询”菜单中，单击“包括客户端统计信息”。

像在代码中一样运行查询。 它将显示结果以及名为“客户端统计信息”的结果旁边的选项卡

单击它并在“服务器回复的等待时间”中查看时间。这是以ms为单位，它是服务器实际执行的时间。

我刚刚运行了这个查询：

select  firstname, lastname from leads

在服务器上花了3ms来获取301,000条记录。

“总执行时间”类似于483ms，其中包括SSMS实际获取数据并处理数据的时间。 我的查询需要2.5-3s才能在SSMS中运行，剩余时间（2500ms左右）实际上是SSMS绘制结果等。）

我的猜测是，41秒可能没有花在SQL服务器上，因为130,000条记录确实没那么多。 在SQL Server返回结果之后，41秒可能主要用于所有内容。

如果发现SQL Server需要很长时间才能执行，请在查询菜单中启用“包括实际执行计划”，然后重新运行查询。 出现一个名为“执行计划”的新选项卡，此选项卡将显示当您对此表执行选择时SQL服务器正在执行的操作以及它花费所有时间的百分比。 在我的情况下，它在PK_Leads的“聚集索引扫描”中花费了100％的时间

编辑包含更多统计数据

Answer 5

一般来说：

1. 找出需要花费大量时间，执行查询或检索结果的内容
2. 如果查询执行，查询计划将告诉您哪些索引丢失，只需按下SSMS中的显示查询计划按钮，您将获得有关应创建哪些索引以提高性能的提示
3. 如果它是值的检索，除了升级硬件（ram，磁盘，网络等）之外，你无能为力。

但：
在您的情况下，看起来查询是全表扫描 ，这对性能来说永远不会有好处，请检查您是否真的需要一次检索所有这些数据。
因为没有条款，所以它的查询执行不太可能是问题。 意味着其他索引无济于事。

您需要更改应用程序访问数据的方式。 不是将所有客户端加载到内存中，然后在内存中从它们中搜索，而是需要将搜索项传递给数据库查询。

LinqToSql使您可以使用不同的功能来搜索值，这是一个描述其中大部分的博客： http ： //davidhayden.com/blog/dave/archive/2007/11/23/LINQToSQLLIKEOperatorGeneratingLIKESQLServer.aspx