Question

在旧的数据库应用程序中，我想开始转向代码优先方法。

数据库中有很多SP，触发器，函数等，这些东西容易出错。

首先，我想进行概念验证，因此我从一个新的解决方案入手，在该解决方案中，我导入了整个数据库（添加新项-> ADO.NET实体数据模型->代码优先从数据库）

作为一个简单的第一枪，我想查询1个表的1列。该表包含约5k行，结果传递3k字符串。现在要花90秒钟以上！

这是查询的代码：

    static void Main(string[] args)
    {
        using (var db = new Model1())
        {
            var theList = db.T_MyTable.AsNoTracking()
                .Where(t => t.SOME_UID != null)
                .OrderBy(t => t.SOMENAME)
                .Select(t => t.SOMENAME)
                .ToList();
            foreach (var item in theList)
            {
                Console.WriteLine(item);
            }
            Console.WriteLine("Number of names: " + theList.Count());
        }
        Console.ReadKey();
    }

在生成的表代码中，我将列类型“ VARCHAR”添加到所有字符串字段/列属性：

    [Column(TypeName = "VARCHAR")] // this I added to all of the string properties
    [StringLength(50)]
    public string SOME_UID { get; set; }

我认为我错过了重要的一步，不敢相信代码优先查询是如此缓慢。

Answer 1

我认为根本原因是需要构建巨大的上下文，并且存在超过1000个表/文件。

我是如何发现问题的：使用探查器，我观察到预期的查询在大约90秒后命中了数据库，告诉我查询本身是快速的。然后，我在一个新项目中尝试了相同的代码，在该项目中，我仅导入了我在代码中访问的单个表。

另一个与上下文相关的证明是在同一会话中两次执行查询；第二次是在毫秒内执行的。

关键点：：如果您的旧数据库具有很多表，请不要使用包含所有表的单个DbContext（初始化数据库除外），而是使用几个较小的特定于域的那些带有给定域上下文所需的表的表。实体可以存在于多个DbContext中，控制关系（例如，在不需要时通过“忽略”表示），并在适当的地方进行延迟加载。这些东西有助于提高性能。

EF 6.2代码优先，简单查询需要很长时间

1 个答案: