แบบสอบถาม Entity Framework ช้า แต่ SQL เดียวกันใน SqlQuery นั้นเร็ว

Question 1

ฉันเห็นความสมบูรณ์แบบแปลก ๆ ที่เกี่ยวข้องกับแบบสอบถามที่เรียบง่ายมากโดยใช้ Entity Framework Code-First กับ. NET framework เวอร์ชัน 4 แบบสอบถาม LINQ2Entities มีลักษณะดังนี้:

 context.MyTables.Where(m => m.SomeStringProp == stringVar);

ซึ่งใช้เวลามากกว่า 3,000 มิลลิวินาทีในการดำเนินการ SQL ที่สร้างขึ้นนั้นดูเรียบง่ายมาก:

 SELECT [Extent1].[ID], [Extent1].[SomeStringProp], [Extent1].[SomeOtherProp],
 ...
 FROM [MyTable] as [Extent1]
 WHERE [Extent1].[SomeStringProp] = '1234567890'

แบบสอบถามนี้ทำงานเกือบจะทันทีเมื่อเรียกใช้ผ่าน Management Studio เมื่อฉันเปลี่ยนรหัส C # เพื่อใช้ฟังก์ชัน SqlQuery มันจะทำงานใน 5-10 มิลลิวินาที:

 context.MyTables.SqlQuery("SELECT [Extent1].[ID] ... WHERE [Extent1].[SomeStringProp] = @param", stringVar);

ดังนั้น SQL ที่เหมือนกันทุกประการเอนทิตีผลลัพธ์จะถูกติดตามการเปลี่ยนแปลงในทั้งสองกรณี แต่ความแตกต่างของความสมบูรณ์แบบระหว่างทั้งสอง สิ่งที่ช่วยให้?

Question 2

พบแล้ว ปรากฎว่าเป็นปัญหาของประเภทข้อมูล SQL SomeStringPropคอลัมน์ในฐานข้อมูลเป็น varchar แต่ EF อนุมานว่า .NET ประเภทสตริงเป็น nvarchars กระบวนการแปลที่ได้ในระหว่างการสืบค้นเพื่อให้ DB ทำการเปรียบเทียบเป็นสิ่งที่ใช้เวลานาน ฉันคิดว่า EF Prof กำลังทำให้ฉันหลงทางอยู่ที่นี่การแสดงคำค้นหาที่ถูกต้องมากขึ้นจะเป็นดังต่อไปนี้:

 SELECT [Extent1].[ID], [Extent1].[SomeStringProp], [Extent1].[SomeOtherProp],
 ...
 FROM [MyTable] as [Extent1]
 WHERE [Extent1].[SomeStringProp] = N'1234567890'

ดังนั้นการแก้ไขที่ได้คือการใส่คำอธิบายประกอบโมเดลรหัสแรกซึ่งระบุชนิดข้อมูล SQL ที่ถูกต้อง:

public class MyTable
{
    ...

    [Column(TypeName="varchar")]
    public string SomeStringProp { get; set; }

    ...
}

Question 3

เหตุผลที่ทำให้การสืบค้นใน EF ช้าลงคือการเปรียบเทียบสเกลาร์ที่ไม่เป็นโมฆะกับสเกลาร์ที่เป็นโมฆะ:

long? userId = 10; // nullable scalar

db.Table<Document>().Where(x => x.User.Id == userId).ToList() // or userId.Value
                                ^^^^^^^^^    ^^^^^^
                                Type: long   Type: long?

ข้อความค้นหานั้นใช้เวลา 35 วินาที แต่การปรับโครงสร้างเล็ก ๆ เช่นนั้น:

long? userId = 10;
long userIdValue = userId.Value; // I've done that only for the presentation pursposes

db.Table<Document>().Where(x => x.User.Id == userIdValue).ToList()
                                ^^^^^^^^^    ^^^^^^^^^^^
                                Type: long   Type: long

ให้ผลลัพธ์ที่เหลือเชื่อ ใช้เวลาเพียง 50 มิลลิวินาทีในการทำให้เสร็จสมบูรณ์ เป็นไปได้ว่าเป็นบั๊กใน EF

Question 4

หากคุณใช้การทำแผนที่แบบคล่องแคล่วคุณสามารถใช้IsUnicode(false)เป็นส่วนหนึ่งของการกำหนดค่าเพื่อให้ได้ผลเช่นเดียวกัน -

http://msdn.microsoft.com/en-us/data/jj591617.aspx#1.9

http://msdn.microsoft.com/en-us/library/gg696416%28v=vs.103%29.aspx

Question 5

ฉันมีปัญหาเดียวกัน (การสืบค้นรวดเร็วเมื่อดำเนินการจากตัวจัดการ SQL) แต่เมื่อดำเนินการจาก EF ระยะหมดเวลาจะหมดอายุ

ปรากฎว่าเอนทิตี (ซึ่งสร้างขึ้นจากมุมมอง) มีคีย์เอนทิตีไม่ถูกต้อง ดังนั้นเอนทิตีจึงมีแถวที่ซ้ำกันโดยมีคีย์เดียวกันและฉันเดาว่ามันต้องทำการจัดกลุ่มบนพื้นหลัง

Question 6

ฉันเจอสิ่งนี้ด้วยแบบสอบถาม ef ที่ซับซ้อน การแก้ไขอย่างหนึ่งสำหรับฉันซึ่งลดแบบสอบถาม ef 6 วินาทีลงในแบบสอบถามย่อยที่สองที่สร้างขึ้นคือการปิดการโหลดแบบขี้เกียจ

หากต้องการค้นหาการตั้งค่านี้ (ef 6) ให้ไปที่ไฟล์. edmx และดูใน Properties -> Code generation -> Lazy Loading Enabled ตั้งค่าเป็นเท็จ

การปรับปรุงประสิทธิภาพครั้งใหญ่สำหรับฉัน

Question 7

ฉันมีปัญหานี้เช่นกัน แต่กลับกลายเป็นผู้ร้ายในกรณีของฉันเป็น SQL เซิร์ฟเวอร์ดมพารามิเตอร์

เบาะแสแรกที่ปัญหาของฉันเกิดจากการดมพารามิเตอร์คือการเรียกใช้แบบสอบถามด้วย "set arithabort off" หรือ "set arithabort on" ทำให้เวลาในการดำเนินการแตกต่างกันอย่างมากใน Management Studio เนื่องจาก ADO.NET โดยค่าเริ่มต้นใช้ "set arithabort off" และ Management Studio มีค่าเริ่มต้นเป็น "set arithabort on" แคชแผนแบบสอบถามจะเก็บแผนต่างๆไว้โดยขึ้นอยู่กับพารามิเตอร์นี้

ฉันแคชแผนแบบสอบถามปิดใช้งานสำหรับการค้นหาด้วยวิธีที่คุณสามารถหาได้ที่นี่