返回包含博客文本的整个表而不是选择特定列的性能

时间:2010-08-02 03:32:27

标签: sql sql-server entity-framework orm

我认为这是一个非常常见的情况:我有一个网页,它返回了最近10个博客条目的链接和摘录。

如果我只查询整个表,我可以使用我的ORM映射对象,但我会下载所有博客文本。

如果我将查询限制在我需要的列中,我将定义另一个只包含那些必填字段的类。

如果我查询整行,性能有多糟糕?是否值得选择我需要的东西?

3 个答案:

答案 0 :(得分:2)

这取决于,但它永远不会像只返回你需要的列那样高效(显然)。如果行数很少且行大小很小,那么网络带宽不会受到太大影响。

但是,仅返回您需要的列会增加可用于满足查询的覆盖索引的可能性,这可能会使查询执行的时间产生很大差异。

答案 1 :(得分:2)

答案是“它取决于”。

就列选择而言,有两件事会影响性能:

  1. covering indexes吗?例如。如果有一个索引包含较小查询中的所有列,那么较小的列集将是非常有益的性能,因为索引将被读取而不会自己读取任何行。

  2. 列的大小。基本上,计算整行的大小,与较小查询中的列的大小相比。

    • 如果比率很高(例如,整行的数量大3倍),那么您可能会大大节省IO(用于检索)和网络(用于传输)成本。

    • 如果这个比例更像是10%的好处,那么就DB性能的提升而言,它可能不值得。

答案 2 :(得分:1)

,由于你指定它是10个记录,答案从“它取决于”变为“不要花费一秒钟担心这个”。

除非您的服务器在拨号连接上位于其他国家/地区,否则10条记录的连线时间将为零,无论您每行扫描多少字节。这根本不是值得优化的东西。

因此,对于这种情况,您可以将ORM设置为以最低效的方式获取这些记录。如果您的情况发生变化,并且您突然需要超过1000条记录,那么您可以回来,我们会因为没有指定列而取笑您,但现在您可以获得免费通行证。

要获得额外的功劳,一旦您开始以每秒10x以上的速度发布此主页查询,您就可以在服务器上添加缓存以避免反复访问数据库。与优化查询相比,这将为您带来更多好处。