前言：不只是防注入，更是效能利器 參數化查詢常被宣傳為「防 SQL 注入」，實則還有一個核心價值：複用執行計畫緩存。SQL Server 將編譯後的計畫存入 P

業務需求：每個分類取最新 5 筆記錄 表 table1(ID, Name, class, date) 中 class 代表分類（上千種），date 為更新時間。

業務場景：指標體系的多層級公式解析 在績效管理系統中，指標（Quota）常形成樹狀結構：父指標透過公式引用多個子指標。需求：給定一個根指標 ID，遞歸展開其所有

前言：為什麼需要 CTE？ 複雜查詢常面臨：多層子查詢嵌套難閱讀、重複計算同一中間結果、需要遞歸處理階層資料。SQL Server 2005 引入的 Commo

核心差異一句話總結 JOIN：依關聯鍵將兩表「橫向拼寬」——欄位增加，行數取決於匹配邏輯。 UNION：將多個同結構結果集「縱向拼長」——欄位不變，行數相加（

前言：為什麼圖解比文字更直觀？ JOIN 的語法雖簡單，但 LEFT JOIN、FULL JOIN、WHERE ... IS NULL 組合出的結果集常讓人困惑

前言：為什麼需要交易？ 當多條 DML 操作（INSERT/UPDATE/DELETE）構成單一業務邏輯單元時，必須保證全成功或全失敗。例如：轉帳扣款成功但入帳

前言：為什麼需要 JOIN？ 關聯式資料庫將資料正規化分散在多張表中。當業務需要跨表查詢——例如「查詢每位學生申請的大學資訊」——單表查詢無法滿足，必須透過 J

前言：資料庫優化的五大支柱 當資料庫效能出現瓶頸時，我們通常從五個維度著手優化：硬體資源調校、應用程式邏輯優化、索引策略設計、SQL 語句重寫，以及交易處理機制

整體架構圖 三大核心模塊 1. 數據如何存儲 表、約束（PK/FK/UK/CK/Default）、觸發器、文件/文件組、頁/區、IAM、系統表。

索引存儲結構：B+樹 根/中間/葉三層，葉級雙向鏈表。 平衡樹：任意葉到根深度相同，查找成本恆定。 鍵值越長 → 頁容納條目越少 →

問題現象 表 T 有復合索引 (CityId, SentDate, UserId)。查詢「大於某向量值 V0 的前 N 行」： = @u0))) SQL Ser

背景 員工表 Employee(Id, Name, DeptIds VARCHAR(1000))，DeptIds 存 1,2,3。需查詢顯示部門名稱 人事部,工

場景 Northwind Employees 表，按 City 分組，取每城市按 EmployeeID 排序的第一名員工。 步驟 1：加行號 SELECT E

語法對比 函數語法標準靈活度 CASTCAST(expr AS type[(len)])ANSI SQL基礎 CONVERTCONVERT(type[(len

使用者定義函數 (UDF) 封裝可重複使用的邏輯，分為標量函數 (回傳單一值)、內嵌表值函數 (單一 SELECT 回傳表)、多語句表值函數 (程序式建構表)。

常見需求：將 645002*01_45854_183677_12 依 _ 分割，取得第 0 段 645002*01。本文提供高效能標量函數 dbo.fGetSt

主鍵設計看似簡單，實則決定系統長期演進的靈活度。本文從三個核心原則出發，透過「主生產計劃單號作主鑰」的反面教材，展示違背原則導致的連鎖災難，並給出正確設計範例。

主鍵生成策略直接影響系統擴展性、遷移便利性與開發效率。本文對比三大主流模式：資料庫自增 (IDENTITY/Sequence)、全域唯一識別碼 (GUID/UU

索引是資料庫效能的核心。本文從 B+ 樹儲存結構出發，深入解析叢集索引 (Clustered Index) 與非叢集索引 (Nonclustered Index