SQL Server 記憶體壓力下大量資料分頁查詢實戰：實體類 SqlMap 解決方案

案例背景

資料同步程式需從外網資料庫一次查詢 50 萬筆 FundYield 資料。伺服器記憶體緊張，SQL Server 佔用 500 MB+，單次查詢逾時失敗。原邏輯以 ZHXGRQ (最後修改日) 為增量標記，但 51 萬筆資料同為 1999-01-01，無法增量，須全量抓取。

解決策略：利用非主鍵唯一欄位 ID 進行分頁

發現資料表含 ID (bigint) 欄位，雖非 PK 但唯一不重複，可作為分頁游標，每次查 10-20 萬筆，避免記憶體暴衝。

實作步驟

1. 調整實體類：指定 SqlMap 映射模式

namespace WFT_DataSyncModel {
    [Serializable()]
    public partial class FundYield : EntityBase, WcfMail.Interface.IDataSyncEntity {
        public FundYield() {
            TableName = "FundYield";
            EntityMap = EntityMapType.SqlMap;  // 關鍵：使用自訂 SQL 對應
            PrimaryKeys.Add("jjdm");
            PrimaryKeys.Add("FSRQ");
            PropertyNames = new string[] { "ID", "jjdm", "jjmc", /* ...其餘 60+ 欄位...*/ };
            PropertyValues = new object[PropertyNames.Length];
        }
        // 屬性略...
    }
}

EntityMapType.SqlMap 告訴框架不直接對應資料表，而是讀取 EntitySqlMap.config 中的自訂查詢 SQL。

2. 建立 EntitySqlMap.config 設定檔

命名空間 與 Map name 必須與實體類完全一致。

3. 執行流程

1. 編譯專案、重新部署同步程式。
2. 每次執行前修改 config 中的 WHERE 條件，例如：
   WHERE ID >= 600000 AND ID < 800000
3. 啟動程式，完成後調整下一區間，直到覆蓋全表。

核心優勢

• 零程式碼修改查詢邏輯：僅調整設定檔即可改變分頁範圍。
• 記憶體平滑：單次查詢量可控，避免 LOH (Large Object Heap) 壓力與 Timeout。
• OO 封裝：資料仍以強型別實體物件流轉，保持業務邏輯清晰。

總結

面對記憶體受限的大量資料查詢，**「分頁游標 + 外部化 SQL 映射」** 是輕量、可維護的解法。將 SQL 從程式碼剝離至設定檔，配合實體類的 SqlMap 模式，達到「不改程式碼、只改設定」的運維彈性，正是物件導向處理純資料問題的優雅體現。