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）添加成功修改失敗，彷佛對修改頗有意見！

 

致網友：若有錯誤，望馬上指正。