迷思 #15：Checkpoint 只會將已提交的交易寫入磁碟 錯誤。 此迷思源於對記錄與復原系統缺乏全面理解。 Checkpoint 真實行為 Checkp

迷思 #14：清除記錄後會將相關 LSN 填零初始化 錯誤。 關鍵區別：檔案成長 vs 記錄截斷 記錄檔手動/自動成長、建立時：會執行填零初始化。 定期清除

迷思 #13：SQL Server 2000 相容模式（80）下不能使用 DMV 錯誤。 相容模式真正影響的範圍 僅影響 T-SQL 語法、查詢計畫行為等語

迷思 #12：TempDB 檔案數需與 CPU 核心數保持 1:1 錯誤。 迷思來源 這是微軟「官方」早期建議，大量部落格持續傳播，成為老生常談。SQL CA

迷思 #11：鏡像在偵測到故障後瞬間就能故障轉移 錯誤。 故障轉移觸發方式 自動： 由鏡像伺服器執行（非見證伺服器）。見證與鏡像皆發現無法與主體交換資訊（「

迷思 #10：資料庫鏡像在故障發生後，馬上就能發現 錯誤。 市面宣傳 vs 實際偵測速度 廠商大肆宣傳「立即偵測並故障轉移」，但實際偵測速度取決於故障類型。

迷思 #9：資料庫檔案收縮不會影響效能 錯誤！ 唯一不影響效能的情況 檔案尾端有剩餘空間，且收縮指定 TRUNCATEONLY 選項時。 收縮過程的三大效能

迷思 #8：線上索引操作不會使相關索引加鎖 錯誤！ 線上索引操作並非想像那麼完美。 兩個關鍵階段會加鎖，可能造成嚴重阻塞 階段 1：操作開始 — 共享資料表

迷思 #7：一個資料庫可以存在多個鏡像 錯誤。 鏡像架構限制 每一個主體伺服器僅允許一個鏡像伺服器。若需多個主體副本，請使用交易記錄傳送，它允許每個主體對應多

這也能減少 CPU 快取失效問題（點此了解 CPU 快取運作與 MESI 協定）。以下揭穿三個關於 NULL 位圖的普遍迷思。 迷思 #6a：NULL 位圖並

迷思 #5：64 位元 SQL Server 必須開啟 AWE 錯誤！ 市面流傳的 AWE 設定版本眾多，極易造成困惑 關於如何設定生效、失效、32/64 位

前言：為何記憶體管理是效能調校的關鍵？ 理解 SQL Server 記憶體管理是解決問題與效能調優的基礎。電腦儲存體系呈階層式：離 CPU 越近速度越快但容量越

迷思 #4：DDL 觸發器（SQL Server 2005 引入）就是 INSTEAD OF 觸發器 這是錯誤的。 本質：DDL 觸發器 = AFTER 觸發

迷思 #3：即時檔案初始化特性可以在 SQL Server 中 a) 開啟 和 b) 關閉 a) 不允許　　b) 允許 什麼是即時檔案初始化？ 這是 SQL

迷思 #2：DBCC CHECKDB 會引起阻塞，因為預設會加鎖 這是錯誤的！ 演進歷程：從 SQL Server 7.0 到 2005+ SQL Serve

迷思 #1：伺服器故障轉移後，正在執行的交易會繼續執行 這是一個絕對錯誤的觀念！ 每一次故障轉移都伴隨著某種形式的資料庫復原。當正在執行的交易尚未 Commit

為什麼備份到 Azure Blob？ 靈活、可靠、無限線下存儲，提升災難恢復能力（異地冗余可選）。 替代磁帶歸檔：即時、高可用、持久，無物理運

事故現場 新上線項目第 2 天，DB 與 IIS 服務器 1Gbps 網卡跑滿 70-100%。 DB 內存飆升至 21GB，IIS CPU

DDL：庫/表結構操作 -- 庫 CREATE DATABASE MyDB; USE MyDB; DROP DATABASE MyDB; -- 表 CREATE

場景 訂單表 Orders 有 BuyerId 和 SellerId 兩字段，均關聯 Users(Id, Name)。需一次查詢顯示買家名、賣家名。 解決方案