EF Core - 資料是否存在
ExistSQL 寫法：COUNT vs EXISTS會員有沒有下過單SQL 寫法：COUNT vs EXISTSEF Core Count vs Any複雜查詢whisper
「當我們只想確認某人是否出現過，沒必要翻遍整本通訊錄。」
在資料庫的世界裡，我們經常會遇到一個簡單卻重要的問題：資料是否存在？
不論是確認某個用戶是否曾下單、某篇文章是否已發佈，這些判斷存在與否的查詢看似簡單，卻往往決定了系統的效能與延遲。尤其當資料表龐大、條件複雜時，使用錯誤的寫法可能導致嚴重的效能問題。
今天，我們就從 SQL 與 EF Core 的角度，來聊聊「資料是否存在」
如果只是想知道「是否有訂單」
COUNT1234IF (SELECT COUNT(*) FROM Orders WHERE CustomerID = 'ALFKI') > 0BEGIN PRINT '有訂單'END
但其實效能更佳的寫法是使用 EXISTS
1234IF EXISTS (SELECT 1 FROM Orders WHERE CustomerID = ' ...
EF Core - TimeoutException (Part 1)
監控查詢資料太多，撐爆記憶體命中索引卻還是慢？複合索引中，查詢條件順序會影響是否命中索引嗎？複雜 JOIN / 多表格查詢Summary某天早上，監控系統跳出好幾個 TimeoutException，我們小組群組裡只聽到一句：「啊，應該是網路問題吧，再跑一次就好了。」
這句話讓我背脊一涼。
TimeoutException 並不是資料庫在耍脾氣，它是壓力太大在吶喊。這篇文章，要來好好梳理這些 “吶喊” 背後的真正原因有時候你只是開個後台報表，卻默默查了幾十萬筆資料。久而久之，伺服器就跟泡麵一樣——泡過頭，膨脹爛掉
1️⃣ 真的需要全部資料嗎？
商業情境：報表開發初期為求簡便，可能會習慣「全撈」資料來呈現，但實際使用者只會看最近的記錄。
1234var threeMonthsAgo = DateTime.UtcNow.AddMonths(-3);var recentOrders = await dbContext.Orders .Where(o => o.CreatedDate >= threeMonthsAgo) .ToListAsync();
2️ ...
EF Core - TimeoutException PART 2
Pre為什麼資料庫會「卡住」？—— 談 Lock方向一. 從交易層級（Transaction Isolation Level）開始說起方向二. 設計 Retry 機制方向三. 避免長時間交易連線池用盡 / 資料庫連不穩沒用 AsNoTracking()大量更新或刪除資料Summary本篇 ~ 繼續 ~ TimeoutException 可能發生的原因及改善方式，從 Lock、Isolation Level、Retry、連線池，到 Change Tracker 與批次處理
🔒 資料庫為什麼會 Lock？當兩個交易（Transaction）同時存取資料時，為了確保資料一致性，資料庫會自動幫我們上鎖。像是：
其他交易正在修改這筆資料（而還沒提交 Commit）
你要修改的資料已經被排他鎖定
這時候，後來的交易就只能等別人釋放鎖，不然就只能拋錯。等待超過 Command Timeout，就會拋出 TimeoutException 或 SqlException。
關鍵例外訊息可能會有哪些？1234567System.TimeoutExceptionMicrosoft.Data.Sql ...
EF Core - Logging
whisper為什麼要紀錄 EF Core 自動產生的 SQL 命令?調整 `appsettings.json` 的 LogLevel在程式中啟用敏感資料紀錄（選配）設定 LogTo：印出日誌到 Console 或其他地方輸出到檔案中：永久保存你的 SQL 日誌閱讀：從官方與社群學更多summary在平穩無波的資料操作背後，EF Core 為我們自動生成了大量 SQL 語法。這些語法就像資料的悄悄話，大部分時間默默運作，沒出錯就好。但一旦效能下滑、查詢遲緩，這些悄悄話就需要被「聽見」。
因此，我們需要打開 EF Core 的日誌紀錄機制，看看背後究竟在跑什麼樣的 SQL
EF Core 是一套功能強大的 ORM 框架，幫助我們用物件導向的方式操作資料。但 ORM 所產生的 SQL 並非總是最有效率的選擇。
透過 Logging，我們可以：
檢查 EF Core 實際送出的 SQL 語法
發現不必要的 JOIN 或 WHERE 條件
優化查詢速度（例如加上索引、改用 View 或 Stored Procedure）
這對效能調教與除錯都非常有幫助
12345678910&# ...
EF Core - 交易的界線
迷航實驗開航前：DBContext 的布陣實驗一：TransactionScope 實測雙 DbContext 同一資料庫實驗二：TransactionScope 跨資料庫實驗三：BeginTransaction() 建出來的交易只能用在建立它的那條 connection 上實驗四：BeginTransaction + 共用連線summary「啊…我有開 TransactionScopeAsyncFlowOption.Enabled 嗎？」「咦？這兩個 Context 是不是不同連線？」「等一下，我是不是跨資料庫了？那 MSDTC 呢？」
交易的邊界，就像洋流與領海，有時你以為你還在安全區，其實早已飄出防線。
這篇筆記，就是一趟從這場 Bug 航行而來的實驗紀錄 —— 我們用四種實際情境來測試 EF Core 的交易能力：
同資料庫、不同 DbContext
跨資料庫
共用連線 vs 不共用連線
TransactionScope vs BeginTransaction
如果你也曾在交易邊界迷航過，歡迎登船
為了這趟「交易航線實驗」，我們準備了三個 DbContext：
Adven ...
Dapper vs EF Core
如果資料存取是場人生選擇，那 EF Core 就像「全包式旅行團」：行李、住宿、行程幫你安排好，你只要準時上車；而 Dapper 則像「背包客自由行」：想去哪、怎麼走、要不要迷路，全靠你自己。
在 .NET 的世界裡，EF Core 與 Dapper 是資料存取的兩大門派，一個幫你包辦大小事，一個讓你操控每一行 SQL。
你可能常常陷入這種掙扎：
「欸現在這隻微服務要查一堆訂單、明細、客戶資料，我要不要用 EF？還是會變龜速大怪獸？」「有三層關聯欸，用 Dapper 要手動 map 到哭出來，欄位一多手都斷了吧…」
🌊 ORM
在開發應用程式時，資料通常儲存在資料庫（Database）中，而程式則是用物件（Object）在操作資料。但是資料庫與程式是兩種世界
資料庫用的是「表格」（table）來存資料，C# 用的是「物件」和「類別」
這兩個東西的結構不同、語言不同、邏輯也不同。
👉 ORM（Object-Relational Mapping）本質是什麼？
它是一座橋梁，幫你自動把「資料表」轉成「物件」，也幫你把你操作的物件轉回資料表格式，這個過程就叫做 ...
EF Core - DbContext 生命週期
blow outEF Core 的預設生命週期：ScopedScoped vs Transient：生命週期的差異為何 using dbContext()EF 會幫我們打理連線嗎？summary
「這裡的風很大，請小心 DbContext 被吹出作用域。」
開發 ASP.NET Core 應用程式時，你一定碰過這段設定
1services.AddDbContext<MyDbContext>();
這一行註冊你的 DbContext，但你知道它的 生命週期（Lifetime）是什麼嗎？Scoped、Transient 差在哪？又該怎麼選擇？今天我們就來一趟資料庫生命週期的航行
Entity Framework contexts
By default, Entity Framework contexts are added to the service container using the scoped lifetime because web app database operations are normally scoped to the client req ...
EF Core - Transaction
Using Transactions
關於 TransactionSaveChanges() 自動包成 Transaction使用 BeginTransaction() 控制交易範圍，可以包多次 SaveChanges()多個 DbContext 共用同一個交易使用 TransactionScope 自動處理多資源交易SaveChanges() 測試BeginTransaction() 測試TransactionScope 測試summary在系統開發中，最可怕的狀況不是資料存不進去，而是「資料只成功了一半」
你可能會覺得沒什麼——多一筆少一筆資料，好像影響不大。但實際上，這種「半成品」的狀態，才是造成系統錯誤與災難的根源
使用者下單成功了，庫存卻沒扣 → 超賣
客戶付款完成，但系統沒記帳 → 客訴、查帳風暴
發票開出來了，卻沒連到訂單 → 財報對不起來
這些問題不是 bug，也不是 crash，而是資料邏輯不一致，讓系統表面正常、實際混亂。這時候，就需要一種「全部成功或全部失敗」的保護機制 —— 這就是 交易（Transaction） 的存在價值。
交易就像你畫圖時的一顆橡皮擦 ...
Dependency Injection - EF Core DbContext
Constructor injection behavior
Dependency Injection - 測試
測試to Feng，這篇介紹 Autofac 觀念的文章 https://blog.darkthread.net/blog/autofac-notes-1/ ，有舉了一個範例，在完全不修改主要程式的情況下抽換不同功能的元件。如果要做單元測試，這超級重要。
例如：某個依賴 WebApi 提供內容的函式，單元測試期間需模擬不同 WebAPI 傳回結果，此時可透過 DI 將 WebAPI 服務元抽換成假元件傳回特定值以驗證不同狀況下邏輯正確。範例：https://blog.darkthread.net/blog/aspnet-core-di-practice/
