LINQ 中的 count VS select - 哪个更快？

Question

我在整个应用程序中使用 IQueryable 接口，并推迟在数据库上执行 SQL，直到像 .ToList() 这样的方法，

我需要找到某些对象的计数列出有时不需要使用正在计数的列表中的数据。 根据我的 SQL 经验，我知道 SQL COUNT() 对数据库的工作量远少于返回所有行的等效 SELECT 语句。

所以我的问题是：从 IQueryable 的 Count() 方法返回计数比渲染 IQueryable< 在数据库上的工作会更少吗;T> 到列表并调用列表的 Count() 方法？

我怀疑它会考虑到 ToList() 将触发 SELECT sql，然后在单独的查询中计算行数。 我希望 IQueryable 上的 Count() 只是为 sql COUNT() 查询呈现 sql。 但我不确定。 你知道吗？

Answer 1

我不确定这是否是一个硬性规定，但是添加到 Iqueryable 的 linq 方法将被添加到 linq 表达式树中 - 除非它们是实际导致树被评估的方法之一（例如 ToList 和 Single ETC）。
对于 LinqToSql，您将知道它是否无法将某些内容转换为 SQL 语句，因为您将收到一个运行时异常，表明该方法不受支持。

例如，

var something = dbContext.SomeTable
  .Select(c => c.col1 == "foo")
  .Distinct()
  .ToList()
  .Count()

在上面，Select() 和 Distinct() 包含在传递给服务器的 sql 查询中，因为它们被添加到 Iqueryable 中。 Count() 只是作用于 sql 查询返回的列表。 所以你不想这样做:-)

在你的情况下，Count()肯定会比Select()更快，因为生成的sql语句确实会合并计数，所以服务器只需要返回一个数字而不是比行列表。

Answer 2

如果您使用的是 SQL Server，Count() 仍然非常昂贵，因为它会导致表扫描（或索引扫描，请参阅主要答案的评论）。 而且，默认情况下，Linq 不使用读未提交隔离级别，这会因锁定而使情况变得更糟。

如果您可以接受脏结果和总行数的近似值，则以下代码将比使用 Count() 快得多。 根据我的经验，此代码返回的值很少与真实的行数不同。

/// <summary>A very fast method for counting rows in a table.</summary>
public static long FastRowCount(DataContext context, string tableName)
{
    const string template = "SELECT rowcnt FROM sys.sysindexes WHERE id = OBJECT_ID('{0}') AND indid < 2";
    string query = string.Format(template, tableName);
    return context.ExecuteQuery<long>(query).Single();
}

Answer 3

调用 ToList() 将返回一个包含所有数据的真正的 List，这意味着获取所有数据。 不好。

调用 Count() 确实应该呈现 SQL 以在数据库端进行计数。 好多了。

然而，检查这一点的最简单方法是在您的数据上下文中启用日志记录（或针对您的特定提供商的任何等效项）并查看实际发送的查询。