EF 延時加載與死鎖

 

 

第一種

            #region 第一種延遲加載 用到的時候就會去查詢數據。
            //用到的時候就會去查詢數據。

            //IQueryable<UserInfo> temp = from u in dbContext.UserInfo 
            //                            //where  u.UName.Contains("o") 
            //                            //&& u.UName.StartsWith("D")
            //                            select u;
          
　　　　　　　//測試一
            //foreach (var userInfo in temp)
            //{
            //    Console.WriteLine(userInfo.ID + "  " +userInfo.UName);
            //}

            //foreach (var userInfo in temp)
            //{
            //    Console.WriteLine(userInfo.ID + "  " + userInfo.UName);
            //}
            //數據庫監視發現：查詢了兩次。
            //因為IQueryable每次用到時都會重新查詢，所以查詢到的數據不可作為緩存。

　　　　　　　//測試二： linq的重用，在temp的基礎上繼續查詢得temp2
            //var temp2 = from u in temp
            //            where u.ID > 0
            //            select u;
            //foreach (var userInfo in temp2)
            //{
            //    Console.WriteLine(userInfo.ID + "  " + userInfo.UName);
            //} 
            //數據庫監視發現 temp和temp2一共只查詢了一次，兩次linq查詢只生成了一條sql語句。 相當於原生ADO時期的sql腳本拼接。
            #endregion

 

 

第二種

            #region 第二種延遲加載

            //IQueryable<UserInfo> temp = from u in dbContext.UserInfo 
            //                            //where  u.UName.Contains("o") 
            //                            //&& u.UName.StartsWith("D")
            //                            select u;
　　　　     //單表多次查詢

            //foreach (var userInfo in temp)  交互1次
            //{
            //    foreach (var orderInfo in userInfo.OrderInfo)  交互 100次
            //    {
            //        Console.WriteLine(userInfo.UName+ "  " +orderInfo.ID + "  " + orderInfo.Content);
            //    }
            //}
　　　　　　　//多表一次連接查詢 Include("OrderInfo")

            //IQueryable<UserInfo> temp = from u in dbContext.UserInfo.Include("OrderInfo")
            //                            //where  u.UName.Contains("o") 
            //                            //&& u.UName.StartsWith("D")
            //                            select u;

            //情景1：當數據量小的時候（一般不會再頁面展示所有數據，而是分頁，數據量不會特別大，那么必須減少連接數據庫的次數）

            //若采用單表查詢，若查詢100個用戶數據，共需與數據庫交互101=1+100，交互的時間就比一次"連接查詢"時間還要長。
            //所以數據量較少時直接使用連接查詢比價高效。

            //情景2：當數據量特別大時。例如： 用戶表跟訂單表數據都是10000 0000條    
            //若采用一次連接查詢：根據笛卡爾積，數據庫過濾數據實際條數是10000 0000 * 10000 0000
            //很可能會使數據庫崩潰。
            //若采單表多次查詢，內存中重組數據。可以很好的解決以上問題。

            //問題來了：             //並發訪問 多次查詢，若出現並發訪問怎么辦？
            //理解並發：
            //在操作系統中，並發是指一個時間段中有幾個程序都處於已啟動運行到運行完畢之間，且這幾個程序都是在同一個處理機上運行，但任一個時刻點上只有一個程序在處理機上運行。
            //在關系數據庫中，允許多個用戶同時訪問和更改共享數據的進程。SQL Server 使用鎖定以允許多個用戶同時訪問和更改共享數據而彼此之間不發生沖突。
            //在這里訪問由於鎖的存在，並發問題轉換成了計算能力問題，計算能力可以通過添加服務器來講解決。

            //3死鎖問題：
            //理解死鎖
            //死鎖是指兩個或兩個以上的進程在執行過程中，由於競爭資源或者由於彼此通信而造成的一種阻塞的現象，若無外力作用，它們都將無法推進下去。此時稱系統處於死鎖狀態或系統產生了死鎖，這些永遠在互相等待的進程稱為死鎖進程。
            //出現情況 
            // 表連接查詢出現： 進程X占用A表，X想連接B表，必須等B表釋放； 但同時y又占用了B表，y想有連接了A表，在等A表釋放。 結果x、y都在等待，二A、B表同時被占用着。
            // 連接的表越多，死鎖問題越突出。
            //解決方案： 臨時表
            //為什么能解決？因為此時鎖定的是臨時表，而原始表處於釋放狀態。
            //臨時表有兩種類型：本地表和全局表。在與首次創建或引用表時相同的 SQL Server 實例連接期間，本地臨時表只對於創建者是可見的。當用戶與 SQL Server 實例斷開連接后，將刪除本地臨時表。全局臨時表在創建后對任何用戶和任何連接都是可見的，當引用該表的所有用戶都與 SQL Server 實例斷開連接后，將刪除全局臨時表。
            //詳情可百度臨時表用法
            #endregion

 

怎么看生成的sql語句的？

1）數據庫里

詳情可百度：  SQL Server Profiler （事件追蹤）

2）斷點調試時
查詢數據后，快速監視如下。查詢數據前是沒有這些內容的。

 

 

 致博客園

1）傻逼的150字數限制！

2）范圍竟然不包括代碼！

3）添加成功修改失敗，似乎對修改很有意見！

 

致網友：如有錯誤，望立刻指正。