Look at the complex paging SQL statements generated by Entity Framework 4.

Previously, the COUNT query statement generated by Entity Framework 4 was found, and the paging SQL statement generated by Entity Framework 4 was found today, but this problem does not exist in LINQ to SQL.

>>> Let's take a look!

Code:

Check the generated SQL statement:

1. SQL statement generated by Entity Framework:

One TOP, three FROM.

2. the SQL statements generated by LINQ to SQL:

No TOP, two FROM.

The gap between the two is clear at a glance.

>>> Let's take a look at the following:

Change the Where query condition in the code above to a constant, that is, Where (coder => coder. Age> 20). For details, see:

Then look at the generated SQL.

1. SQL statement generated by Entity Framework:

It is obviously different (color). In fact, only exec sp_executesql is missing, but it will affect the performance (sp_executesql will use cached plan to get more performance, which is mentioned here ).

2. the SQL statements generated by LINQ to SQL are the same as those before.

 

Entity Framework considers multi-database support and stored procedure support, but ignores this.

FromDataContextTo the Entity FrameworkObjectContextAnd then launch ADO. NET Entity Framework Feature CTP5.DbContextDbContext does not solve this problem, and Microsoft's thinking is a bit messy.

Currently, if Entity Framework 4 is used and performance is concerned, there are only two options: 1. you do not need to write SQL statements or stored procedures without using LINQ to Entities. 2. write your own Entity Framework ADO.. NET provider for SQL Server.

Update: From the execution plan, the SQL statements generated by Entity Framework seem to have no impact on performance.

Supplement:

Comparison of execution plans of two SQL statements:

A) SQL statement generated by Entity Framework:

B) the SQL statements generated by LINQ to SQL: