Hacker News
This article explains how the default mapping of C# strings to nvarchar in Dapper can cause implicit conversions and full index scans on varchar columns, leading to severe performance degradation.
AI 生成摘要
這篇文章解釋了 Dapper 預設將 C# 字串映射為 nvarchar 的行為，如何導致 varchar 欄位發生隱式轉換與全索引掃描，進而造成嚴重的效能下降。
在 .NET 開發環境中，Dapper 是一款廣受歡迎的輕量級 ORM 工具，但其預設行為可能在不經意間拖垮資料庫效能。本文探討了當 C# 字串透過 Dapper 傳遞至 SQL Server 時，若資料庫欄位類型為 varchar，Dapper 預設會將其映射為 nvarchar，進而觸發隱式轉換（Implicit Conversion），導致索引失效並引發嚴重的 CPU 負載問題。
針對此現象，Hacker News 社群展開了多層次的討論。許多資深開發者指出，這本質上並非 C# 或 Dapper 的特定缺陷，而是 SQL Server 處理 Unicode 與非 Unicode 字元集時的經典效能陷阱。當查詢參數的優先級高於資料表欄位時，資料庫引擎為了確保資料完整性，會選擇將欄位內容逐筆轉換以進行比對，這種「收窄轉換」的代價就是無法利用索引尋找（Index Seek），轉而執行代價高昂的全索引掃描。
部分留言者對現代開發環境中是否仍應堅持使用 varchar 提出質疑。支持全面轉向 nvarchar 的觀點認為，在 2026 年的今天，支援 Unicode 已是處理人類語言的基本要求，且儲存空間的節省在多數應用場景下已不再是首要考量。然而，另一派意見則從底層效能與儲存效率出發，強調在處理如訂單編號、代碼或純英文字元時，varchar 僅需一半的空間，能有效提升記憶體分頁的利用率與 I/O 效率。此外，雖然 SQL Server 近年推出了 UTF-8 支援，但其穩定性與實作方式仍讓部分開發者持保留態度，認為這只是另一種形式的 varchar 定義。
關於解決方案，社群也提供了原文之外的實務建議。有開發者分享可以透過 Dapper 的全域設定，在應用程式啟動時統一修改字串映射規則，避免在每個查詢中手動指定類型。也有人提倡使用儲存程序（Stored Procedures），認為這能將資料庫類型的定義權交還給資料庫專家，避免應用程式端的類型誤判影響執行計畫。值得注意的是，討論中也出現了對文章風格的批評，部分讀者認為其敘述方式帶有強烈的 AI 生成痕跡，缺乏具體的基準測試數據，僅以模糊的量級描述效能差異，這反映出技術社群對於內容真實性與嚴謹度的日益重視。
nvarchar 會強制 varchar 進行轉換。nvarchar 的同時優化儲存空間。