EF查詢百萬級數據的性能測試--多表鏈接複雜查詢

時間 2019-11-18

原文原文鏈接

1、原由 web

上次作的是EF百萬級數據的單表查詢，總結了一下，在200w如下的數據量的狀況(Sql Server 2012)，EF是可使用，可是因爲查詢條件過於簡單，且是單表查詢，EF只是負責生成Sql語句，對於一些簡單的查詢，生成Sql語句的時間能夠基本忽略，因此不只沒有發揮出EF的優點，並且這樣的性能瓶頸基本能夠說是和數據庫徹底有關的，這個鍋數據庫得背(數據庫：怪我了)。鑑於實際項目中可能是多表的鏈接查詢，還有其餘複雜的查詢，一貫本着求真務實的思想的博主就趁此機會再次測試了一下EF的複雜的鏈接查詢什麼的。說實話，在測試以前我也不知道結果，只是爲了本身之後用起來有個參考依據，也比老是聽別人說EF性能不好，嚇得都不敢用了要好。EF的性能到底有多差，或者說能夠勝任什麼樣的場景，不吹不黑，咱們就一塊兒來看看，也好在之後的實際項目選型的時候參考一下。ajax

2、關於不少ORM框架的對比測試sql

博主最近也看了很多關於ORM框架的測試，大多數都是增刪改幾千，幾萬條的數據，這樣確實能夠看出來性能的比較，可是實際項目中真的不多有這樣的狀況，一次增刪改幾千幾萬條數據的，咱們作項目服務的都是用戶，按用戶的一次請求爲一次數據庫上下文的操做，同一個上下文在這樣的一次請求中基本不可能同時提交這麼多的數據操做，有人說那要是成千上萬的用戶同時呢，那就要考慮併發了，就不是本文所要討論的問題了。因此這些測試能代表結果，可是不能代表實際問題。另外在大多數對於EF的測試中，不少人忽略了EF對於實體的跟蹤，好比：
數據庫

這些屬性雖然我不全知道是什麼的東西，可是既然能夠設置Enabled，就說明是對性能有影響的，並且數據量越多，相信影響也越大，但其餘多數ORM應該都沒有這些功能或者設置（我不知道，哈哈），因此對於增刪改的操做，我以爲當前狀況下是徹底夠用的，因此再也不探究增刪改的性能（若是實在有朋友以爲必要，博主再找機會）。EF的初衷，也能夠說是不少ORM應該具有的出發點，就是從之前的很是不OO的數據操做方式，變成如今的OO的方式，就是爲了解放開發人員寫Sql查詢操做數據庫的方式，就是要用面向對象的思想來操做數據庫，結果倒好，有些人又要回到之前寫Sql語句，又要去回到解放前，這就比如面向過程編程效率很高速度很快，可是爲何要提出面向對象編程，由於面向過程寫起來累啊！很差維護啊！很差擴展啊！不方便啊，還有分層架構，不都是爲了這嗎，這些東西咱們應該是發揮它的優點，知道他在什麼狀況下用，什麼狀況下不用，而不是一直死死的抓住他的缺點說不行。固然，有不少狀況下是不追求生產效率，只追求性能的，那就不說了。
編程

說了這麼多，我也不是想證實什麼，我只是想知道，我該什麼狀況下用EF，怎麼用EF來發揮出他的優點，怎麼能用好EF，應用到實際生產環境中。一句話，爲何個人眼裏常含淚水，由於我對EF愛的深沉。（斜眼笑）瀏覽器

3、準備工做服務器

那確定是先建表結構和數據了，廢話很少說，上圖先。
網絡

1.關係圖架構

這是數據庫的關係圖，只有User和Role是多對多關係，其餘的是一對多，另外都加了導航屬性，博主事先用的是Code First，已經添加了導航屬性，爲的是能夠在後來的測試中使用導航屬性（EF會自動根據導航屬性生成鏈接查詢，能夠由此來作測試），這裏借用了Database First來從數據庫生成了模型圖，爲的是你們可以清楚的看錶之間的關係。

簡單說明一下：

　　一個User對應多個Order；

　　一個Order對應多個OrderDetail，對應一個City；

　　一個OrderDetail至關於一個產品，對應一個產品類型Category。

　其中因爲多對多的關係比較少見，且能夠轉化爲兩個一對多的關係（Sql Server就是這麼幹的），因此此次暫時不作多對多的測試，應該和一對多差很少。

2.表數據

這裏城市表是如今項目中用的一個，由於以前就三個字段Id，Name，ParentId，而後要找其餘數據就要遞歸查詢，很浪費時間，後來想了想既然都是死數據，就一下給寫進去，以後再用就不用查了。

附上City表的Sql文件，有須要的同窗能夠帶走：dbo.City.Table.zip

在某東首頁複製的商品類型數據。。

3.數據量

用戶表，訂單表，訂單明細表都是100w的數據，其餘兩個表按實際狀況來，類型表沒有再細分，就這樣吧。

4、開始測試

1.關於Sql語句生成的時間

因爲大多數人都說EF的性能瓶頸在生成Sql的時間和質量上，引用一位朋友的回答以下：

上邊這條評論的第二條說的應該就是質量的問題，關於EF生成Sql語句有什麼規則，或者怎樣才能生成高質量的Sql，這個內容也是一個很值得研究的問題，咱們隨後有時間研究。今天咱們就只針對生成Sql語句的時間上加以探究。

在網上搜索了一些資料，關於怎麼測試EF生成Sql的時間，博主沒有見到過相關的測試，可是怎樣獲取到生成的Sql語句仍是有辦法的，因此，博主想了想，既然能獲取到sql語句，那麼這個獲取的過程就能夠做爲生成Sql的時間，因爲沒有相關的資料說明，因此暫且用這樣的方法來測，博主使用的兩種比較笨的方法測試生成的時間，也但願園友們若是有更好的方法能夠告訴博主。

1.ToString()方法

因爲在IQueryable接口中重寫了ToString()方法，因此博主試了一下，果然能獲取到Sql語句，因此就用ToString()方法的執行時間當作生成Sql語句的時間。先來個簡單的：

能夠看出已經生成了Sql（注意：這裏並無去數據庫查詢，只是生成了Sql）涉及到了最簡的兩個表的連接，那咱們接下來看生成所用的時間。

能夠看出來，生成Sql的時間很是短，徹底能夠忽略不計，可能博友以爲Sql過於簡單，不要緊，咱們再來幾個複雜的

複雜語句一，涉及到了四個表的連接：

依舊不多時間，只是略比上一個Sql的時間長一點，畢竟複雜了一點。

複雜語句二，直接截圖了，這裏爲了生成Sql語句的複雜，隨便寫了一些Linq，可能不是咱們平常想要的結果，只是爲了複雜而已：

時間明顯變長，可是依舊不到1ms，附上生成的Sql語句，夠複雜了吧。　　　　

 1 SELECT 
 2     [Project7].[C1] AS [C1], 
 3     [Project7].[Work] AS [Work], 
 4     [Project7].[C2] AS [C2]
 5     FROM ( SELECT 
 6         [Project6].[Work] AS [Work], 
 7         1 AS [C1], 
 8         [Project6].[C1] AS [C2]
 9         FROM ( SELECT 
10             [Project3].[Work] AS [Work], 
11             (SELECT 
12                 MAX([Project5].[Amount]) AS [A1]
13                 FROM ( SELECT 
14                     [Extent11].[Id] AS [Id], 
15                     [Extent11].[Amount] AS [Amount], 
16                     [Filter4].[UserId] AS [UserId]
17                     FROM   (SELECT [Project4].[UserId] AS [UserId], [Project4].[FullName] AS [FullName], [Project4].[UserName] AS [UserName1], [Extent10].[Work] AS [Work]
18                         FROM   (SELECT 
19                             [Extent6].[UserId] AS [UserId], 
20                             [Extent7].[FullName] AS [FullName], 
21                             [Extent8].[UserName] AS [UserName], 
22                             (SELECT 
23                                 SUM([Extent9].[TotalPrice]) AS [A1]
24                                 FROM [dbo].[OrderDetail] AS [Extent9]
25                                 WHERE [Extent6].[Id] = [Extent9].[OrderId]) AS [C1]
26                             FROM   [dbo].[Order] AS [Extent6]
27                             INNER JOIN [dbo].[City] AS [Extent7] ON [Extent6].[CityId] = [Extent7].[Id]
28                             INNER JOIN [dbo].[User] AS [Extent8] ON [Extent6].[UserId] = [Extent8].[Id] ) AS [Project4]
29                         LEFT OUTER JOIN [dbo].[User] AS [Extent10] ON [Project4].[UserId] = [Extent10].[Id]
30                         WHERE [Project4].[C1] > cast(500 as decimal(18)) ) AS [Filter4]
31                     LEFT OUTER JOIN [dbo].[User] AS [Extent11] ON [Filter4].[UserId] = [Extent11].[Id]
32                     WHERE ([Filter4].[FullName] LIKE @p__linq__0 ESCAPE N'~') AND (([Filter4].[UserName1] = @p__linq__1) OR (([Filter4].[UserName1] IS NULL) AND (@p__linq__1 IS NULL))) AND (([Project3].[Work] = [Filter4].[Work]) OR (([Project3].[Work] IS NULL) AND ([Filter4].[Work] IS NULL)))
33                 )  AS [Project5]) AS [C1]
34             FROM ( SELECT 
35                 [Distinct1].[Work] AS [Work]
36                 FROM ( SELECT DISTINCT 
37                     [Extent5].[Work] AS [Work]
38                     FROM   (SELECT 
39                         [Extent1].[UserId] AS [UserId], 
40                         [Extent2].[FullName] AS [FullName], 
41                         [Extent3].[UserName] AS [UserName], 
42                         (SELECT 
43                             SUM([Extent4].[TotalPrice]) AS [A1]
44                             FROM [dbo].[OrderDetail] AS [Extent4]
45                             WHERE [Extent1].[Id] = [Extent4].[OrderId]) AS [C1]
46                         FROM   [dbo].[Order] AS [Extent1]
47                         INNER JOIN [dbo].[City] AS [Extent2] ON [Extent1].[CityId] = [Extent2].[Id]
48                         INNER JOIN [dbo].[User] AS [Extent3] ON [Extent1].[UserId] = [Extent3].[Id] ) AS [Project1]
49                     LEFT OUTER JOIN [dbo].[User] AS [Extent5] ON [Project1].[UserId] = [Extent5].[Id]
50                     WHERE ([Project1].[C1] > cast(500 as decimal(18))) AND ([Project1].[FullName] LIKE @p__linq__0 ESCAPE N'~') AND (([Project1].[UserName] = @p__linq__1) OR (([Project1].[UserName] IS NULL) AND (@p__linq__1 IS NULL)))
51                 )  AS [Distinct1]
52             )  AS [Project3]
53         )  AS [Project6]
54     )  AS [Project7]
55     ORDER BY [Project7].[Work] ASC

複雜語句三，再來一個看看，用到了分頁。

此次因爲比較複雜，因此生成Sql也花費了一些時間，能夠看出來已經到的四、5ms左右，可是生成的Sql確比上次的少。　　　

SELECT 
    [Project3].[Id] AS [Id], 
    [Project3].[UserName] AS [UserName], 
    [Project3].[Name] AS [Name], 
    [Project3].[Amount] AS [Amount], 
    [Project3].[C1] AS [C1]
    FROM ( SELECT 
        [Project2].[Id] AS [Id], 
        [Project2].[UserName] AS [UserName], 
        [Project2].[Amount] AS [Amount], 
        [Project2].[Name] AS [Name], 
        [Project2].[C1] AS [C1]
        FROM ( SELECT 
            [Project1].[Id] AS [Id], 
            [Extent5].[UserName] AS [UserName], 
            [Extent5].[Amount] AS [Amount], 
            [Extent6].[Name] AS [Name], 
            (SELECT 
                COUNT(1) AS [A1]
                FROM [dbo].[OrderDetail] AS [Extent7]
                WHERE [Project1].[Id] = [Extent7].[OrderId]) AS [C1]
            FROM    (SELECT 
                [Extent1].[Id] AS [Id], 
                [Extent1].[UserId] AS [UserId], 
                [Extent1].[CityId] AS [CityId], 
                [Extent2].[FullName] AS [FullName], 
                [Extent3].[UserName] AS [UserName], 
                (SELECT 
                    SUM([Extent4].[TotalPrice]) AS [A1]
                    FROM [dbo].[OrderDetail] AS [Extent4]
                    WHERE [Extent1].[Id] = [Extent4].[OrderId]) AS [C1]
                FROM   [dbo].[Order] AS [Extent1]
                INNER JOIN [dbo].[City] AS [Extent2] ON [Extent1].[CityId] = [Extent2].[Id]
                INNER JOIN [dbo].[User] AS [Extent3] ON [Extent1].[UserId] = [Extent3].[Id] ) AS [Project1]
            LEFT OUTER JOIN [dbo].[User] AS [Extent5] ON [Project1].[UserId] = [Extent5].[Id]
            LEFT OUTER JOIN [dbo].[City] AS [Extent6] ON [Project1].[CityId] = [Extent6].[Id]
            WHERE ([Project1].[C1] > cast(500 as decimal(18))) AND ([Project1].[FullName] LIKE @p__linq__0 ESCAPE N'~') AND (([Project1].[UserName] = @p__linq__1) OR (([Project1].[UserName] IS NULL) AND (@p__linq__1 IS NULL)))
        )  AS [Project2]
        WHERE ([Project2].[Amount] > cast(50 as decimal(18))) AND ([Project2].[Amount] < cast(500 as decimal(18)))
    )  AS [Project3]
    ORDER BY [Project3].[Amount] DESC
    OFFSET 28 ROWS FETCH NEXT 14 ROWS ONLY

2.和數據庫的時間對比

這是博主又想到的一個笨方法，就是點擊按鈕的時候記下當前的時間，而後去數據庫的Profile裏邊獲取監視到的開始時間，由於這裏考慮的網絡傳輸Sql語句的時間，可是因爲是本機傳送，因此應該不會耗費不少時間，那麼咱們就來對比一下，也就能夠大體估算出生成sql語句所用的時間了。以下圖：

下面來看統計結果：

預期結果爲差值大於後邊的生成sql的時間(確定的啊)，裏邊有兩次時間爲負，多是其餘緣由致使的客戶端開始時間記錄產生的偏差，從這裏能夠看出，由於生成sql的時間必然要小於差值，因此生成sql的時間仍是很短的。

再來看一張圖：

從下邊的結果能夠看出，傳輸時間相對於生成sql的時間仍是挺長的，這也再一次說明了，EF生成sql語句的時間很短，幾乎能夠忽略。因此EF的性能瓶頸能夠排除在生成的sql語句時間長上。

2.查詢數據

下面咱們就根據實際的業務須要查詢一波數據，看看結果到底怎麼樣。代碼以下：

需求1：查詢最近六個月下單的用戶的部分信息（用戶名，餘額，下單日期），並按照下單日期排序進行分頁（涉及到兩個100w數據表的連接User表和Order表）

生成sql語句，中規中矩。

 1 SELECT 
 2     [Project1].[UserId] AS [UserId], 
 3     [Project1].[UserName] AS [UserName], 
 4     [Project1].[Amount] AS [Amount], 
 5     [Project1].[OrderDate] AS [OrderDate]
 6     FROM ( SELECT 
 7         [Extent1].[UserId] AS [UserId], 
 8         [Extent1].[OrderDate] AS [OrderDate], 
 9         [Extent2].[UserName] AS [UserName], 
10         [Extent2].[Amount] AS [Amount]
11         FROM  [dbo].[Order] AS [Extent1]
12         INNER JOIN [dbo].[User] AS [Extent2] ON [Extent1].[UserId] = [Extent2].[Id]
13         WHERE [Extent1].[OrderDate] > @p__linq__0
14     )  AS [Project1]
15     ORDER BY [Project1].[OrderDate] DESC
16     OFFSET 2000 ROWS FETCH NEXT 20 ROWS ONLY

代碼以下：

查詢結果以下：

能夠看出來表現很不錯，時間大概在70ms左右，是很是能夠接受的。至於這裏爲何生成sql的時間長了，那是由於在生成sql的前邊作了一次Count查詢，因此這裏的生成sql的時間是無效的。前邊已經證實過生成sql的時間是能夠忽略不計的。

需求2：查詢最近六個月訂單總金額大於1000的訂單，獲取用戶和訂單詳情的部分信息，並按照下單日期排序進行分頁（涉及到三個100w數據表的連接User表和Order表、OrderDetail表）

生成的sql:

 1 SELECT 
 2     [Project4].[Id] AS [Id], 
 3     [Project4].[UserName] AS [UserName], 
 4     [Project4].[Amount] AS [Amount], 
 5     [Project4].[OrderDate] AS [OrderDate], 
 6     [Project4].[C1] AS [C1], 
 7     [Project4].[C2] AS [C2]
 8     FROM ( SELECT 
 9         [Project3].[Id] AS [Id], 
10         [Project3].[OrderDate] AS [OrderDate], 
11         [Project3].[UserName] AS [UserName], 
12         [Project3].[Amount] AS [Amount], 
13         [Project3].[C1] AS [C1], 
14         [Project3].[C2] AS [C2]
15         FROM ( SELECT 
16             [Project2].[Id] AS [Id], 
17             [Project2].[OrderDate] AS [OrderDate], 
18             [Project2].[UserName] AS [UserName], 
19             [Project2].[Amount] AS [Amount], 
20             [Project2].[C1] AS [C1], 
21             (SELECT 
22                 SUM([Extent5].[TotalPrice]) AS [A1]
23                 FROM [dbo].[OrderDetail] AS [Extent5]
24                 WHERE [Project2].[Id] = [Extent5].[OrderId]) AS [C2]
25             FROM ( SELECT 
26                 [Project1].[Id] AS [Id], 
27                 [Project1].[OrderDate] AS [OrderDate], 
28                 [Extent3].[UserName] AS [UserName], 
29                 [Extent3].[Amount] AS [Amount], 
30                 (SELECT 
31                     COUNT(1) AS [A1]
32                     FROM [dbo].[OrderDetail] AS [Extent4]
33                     WHERE [Project1].[Id] = [Extent4].[OrderId]) AS [C1]
34                 FROM   (SELECT 
35                     [Extent1].[Id] AS [Id], 
36                     [Extent1].[UserId] AS [UserId], 
37                     [Extent1].[OrderDate] AS [OrderDate], 
38                     (SELECT 
39                         SUM([Extent2].[TotalPrice]) AS [A1]
40                         FROM [dbo].[OrderDetail] AS [Extent2]
41                         WHERE [Extent1].[Id] = [Extent2].[OrderId]) AS [C1]
42                     FROM [dbo].[Order] AS [Extent1] ) AS [Project1]
43                 LEFT OUTER JOIN [dbo].[User] AS [Extent3] ON [Project1].[UserId] = [Extent3].[Id]
44                 WHERE ([Project1].[OrderDate] > @p__linq__0) AND ([Project1].[C1] > cast(1000 as decimal(18)))
45             )  AS [Project2]
46         )  AS [Project3]
47     )  AS [Project4]
48     ORDER BY [Project4].[OrderDate] DESC
49     OFFSET 2080 ROWS FETCH NEXT 20 ROWS ONLY

查詢結果：

查詢用了330ms左右，仍是能夠接受的。

需求3：查詢訂單總價格大於1000的數據，並按時間降續排列，取前10000條的用戶的部分信息，而且對着10000條按帳戶餘額排序，再進行分頁處理。

這裏能夠說是鏈接了四個表的（User表，Order表，OrderDetail表，City表），其中三個表都是100w的數據

查詢了十次，咱們來看查詢時間

已經1s多的時間，能夠說是有點慢了。（注意，這裏在查詢出來以前先是按日期排序再取10000條，這個排序是很耗費性能的，這裏也是一個咱們之後須要優化的地方）可是，對，說到可是了，因而乎，樓主把生成的sql語句複製到數據庫中直接查詢，結果也是很長的。

因此說，這應該是數據庫方面的問題的，這裏確定不是EF生成sql語句的時間問題，前邊已經說明過了，至因而不是EF生成的sql語句的質量問題，我就不知道了。

5、關於時間概念

咱們作的產品或者項目都是服務於用戶的，因此咱們要以用戶的角度看待問題，那就是用戶的體驗問題。

1.關於頁面的響應時間，引用了網上的一點資料，百度的標準是3s如下，咱們暫且定爲2s如下，以Asp.Net Mvc爲例若是咱們在控制器裏拿數據並渲染到頁面上，拿數據時間應該在1s（1000ms）如下才能夠。

2.如今愈來愈流行單頁面web應用，因此通常都是ajax請求異步拿數據，首先說明一點，拿數據最耗時的就是在數據庫裏的查詢，傳輸時間也有，可是在如今這麼高的帶寬下，徹底能夠忽略不計，可是說也是白說，你們仍是以實際中的體驗來作標準吧

園子裏的博客分頁應該是異步加載，就以此爲例看看。

1.700ms左右的體驗：

2.300ms左右的體驗：

3.200ms左右的體驗：　

4.100ms左右的體驗：

具體體驗你們能夠親自感覺一下，谷歌瀏覽器調試工具能夠設置當前網速，博主本着求真務實的思想，認爲實際項目中若是不是很是很是注重用戶的體驗，咱們的拿數據的時間能夠控制在250ms如下也是能夠接受的，100ms如下的時間已是有點浪費了，在這裏是給你們一個時間概念參考一下。

按着這個標準，我感受EF在百萬級的數據下仍是很是能夠接受的，畢竟博主測試的都是本身的電腦，實際項目運行在服務器上，服務器的配置確定是至關高的，確定也會提升很多性能。

6、總結

1.EF能夠說是不存在生成sql語句時間長方面的瓶頸，至於生成sql語句的質量，可能真的有性能影響，可是這些東西也是開發人員寫的，因此這個鍋EF仍是不能背，還應該是開發人員的鍋。

2.對於簡單的鏈接查詢，EF生成的sql語句應該不存在質量問題，應該和開發人員寫的差很少，可是對於複雜的查詢，EF確實生成了一大堆的sql語句，可是開發人員面對這麼複雜的查詢，還不必定能寫出來呢（反正我如今是寫不出來），即便花費一上午寫了出來，那麼再花費一下午調試，一天過去了，這時候你對大家經理說，我考慮到性能問題，不想用自動生成的sql語句。那麼你基本能夠捲鋪蓋走人了。（哈哈），因此基於這個角度，我以爲仍是乖乖用生成的sql查詢吧。

3.對於百萬級以上的數據，錶鏈接最好控制在3個之內，我這裏不是針對EF，是針對全部在座的數據庫。（請自動腦補星爺電影裏的橋段）

4.本文只作測試功能，可能會有一些誤差，你們用時仍是請以實際項目爲準。畢竟有博友幾百萬的數據鏈接查詢也一樣高效：

5.關於怎麼用EF寫出高效的查詢，我相信這也是一個很值得研究的話題，之後有時間的話博主還會繼續研究，關於這方面但願你們也踊躍爲博主提供一些資料，也但願有作DBA的朋友提出一些sql語句方面的優化建議，畢竟博主也是隻能一個個試來試去。

6.仍是那句話，我只是想知道，我該什麼狀況下用EF，怎麼用EF來發揮出他的優點，怎麼能用好EF，應用到實際生產環境中。也爲更多的喜歡EF的人和不瞭解EF的人提供一些幫助。

附：轉載請註明出處，樓主一個一個測試也是很不容易，感謝你們的支持。　