這個系列文主要是我個人經驗與我看待DB的角度出發
然後因為現在有 AI，語法、datatype 那些很基礎的東西網路上都很多了，所以就不會出現在這裡
系列文主要會分成兩個階段，基礎 & 效能調校。
因為都是我個人經驗，如有錯誤請多指教。

從微軟的官方網站下載安裝應用程式。如果去載這個，會得到一個簡單的「安裝小幫手 (install helper)」程式，而不是一開始就直接下載幾 GB 的完整安裝媒體。

這個小幫手應用程式會提供一個「基本 (Basic)」安裝選項，它會將 SQL Server 的所有功能直接安裝在當前的伺服器上。通常應該避免這種做法，因為它會最大化攻擊面 (attack surface)。 也可以選擇在目前的伺服器上執行「自訂 (Custom)」安裝。最後，還有一個選項是單純「下載媒體 (Download Media)」，這允許將完整的安裝檔下載下來後，複製到另一台伺服器上進行離線安裝 (offline install)。

安裝中心

SQL Server 安裝中心是一個「一站式 (one-stop shop)」的服務介面，負責處理所有與規劃、安裝以及升級 SQL Server 執行個體相關的活動。當執行 SQL Server 安裝媒體時，首先映入眼簾的應用程式就是它。安裝中心包含了七個索引標籤 (tabs)，下面我會說明這些標籤的內容。

計劃

1. 裡面有很多連結到MSDN網頁的連結，是關於SQL Server的重要文件，例如完整的軟硬體需求、SQL Server安全文件。基本也沒什麼在用。
2. 但是除此之外有還一個System Configuration Checker。 這是用來判斷在安裝過程中，是否存在任何會阻止SQL Server安裝的東西。檢查包含domain controller、Windows Management Instrumentation的服務是否正在執行。所以可以預先警告任何可能導致安裝失敗的問題。原則是直接按下去用就好了，有問題再針對那個問題去處理，至於他是什麼原理去測試什麼不需要知道。
3. DMA是資料移轉的工具，用來偵測升級版本的相容性問題，不是要升級版本的話就不用了。例如2016 > 2022。

安裝

1. 要安裝全新的獨立的個體就選最上面的。
2. 除了安裝獨立執行個體、將新功能加入至執行個體，以及將現有執行個體升級至最新版本之外，這裡也提供了安裝 SQL Server 容錯移轉叢集執行個體 (failover clustered instance)，以及將新節點加入至現有容錯移轉叢集的選項。
3. 容錯移轉叢集 (failover cluster) 是一個由 2 到 64 台伺服器共同運作的系統，旨在提供備援 (redundancy)，並防止因一台或多台伺服器故障而導致服務中斷。參與該叢集的每一台伺服器被稱為一個節點 (node)。
4. SQL Server Database Engine 跟 Analysis Services都是叢集感知的程式，所以他可以安裝在Windows 叢集上，而且可以利用他的容錯移轉功能。
5. 當安裝在容錯移轉叢集上時，資料庫和交易紀錄檔會放置在共用儲存設備上，叢集中的任何結點都可以使用他，但程式本體則是安裝在每個node的本機上。
6. SSRS、SSMS、SSDT在這裡只是個連結，有需要的話去GOOGLE找就可以。

維護

維護包含版本升級、修復損壞的Instance、叢集移除Node工具。

1. Edition Upgrade 這個版本升級是只從開發人員版升級成企業版的意思，不是2022升級到2025那樣。
2. Repair 是用來解決 SQL Server安裝損壞的問題，如果登錄檔項目或主程式損壞，就可以用這個。
3. Remove node from a SQL Server Failover cluster 可以移除叢集node。

工具

1. System Configuration Checker 可分析本機伺服器所有已安裝的SQL Server功能元件。主要是用在你要完整移除SQL Serever的話，它會讓你知道這台電腦裝了哪些東西。
2. Microsoft Assessment and Planning Toolkit For SQL Server他是一個連結，會導到微軟一個下載map工具的地方。這工具它會在整個網路內搜尋 SQL Server、Oracle 與 MySQL 的安裝。然後產生一份詳細的報表，其中針對 SQL Server，會包含元件的名稱、年份版本 (version) 與發行版本 (edition)。針對 Oracle，它會包含每個結構描述 (schema) 的大小與使用情況，包含移轉時的複雜度估計。您也可以使用此工具來規劃移轉與整併 (consolidation) 策略，並稽核整個企業內的授權需求。

資源

這就一些連結沒什麼用，google都有。

進階

1. 首先其實每次安裝SQL Server的時候，系統都會自動建立一個設定檔。這個設定檔也是可以手動建立的。
2. 如果今天有多個instance 的需求，在公司內可以全部都用這個設定檔去安裝，達到全公司SQL Server的一致性。
3. 如果想用這種方式安裝，就要到進階這邊的 Install based on configuration file 選這個來安裝。
4. 用這個方式去安裝對於 command-line會非常有用，至於有什麼用以後再講。
5. 此外，如果想用這個設定檔也可以用來裝node，但一樣要來進階這邊選 Advanced cluster completion。
6. 要用這個方法的話第一次還是得先手動建立一個node，之後再從這個node上面去產生一個設定檔，接下來其他的node都用這個設定檔去安裝就可以。
7. 補充一點node 相關的東西，SQL Server會自動偵測子網路之間的關聯性，並會提示每個子網路選一個ip位址。他同時也適用多子網路叢集。
8. 安裝的時候會將這些ip位址個別作為叢集角色的相依姓，使用OR 或是 AND 條件約束。
9. 一旦叢集個體擁有者的節點上執行過進階叢集準備精靈後，就可以執行進階叢集完成精靈，然後整個叢集執行個體就能全面運作。
10. 關於5~9點的叢集，名詞很難懂，所以用以下舉例。
    1. 容錯移轉叢集 : 就是把A、B甚至更多台伺服器，綁在一起，如果A掛了，B會馬上接手，這樣AB綁再一起的一個整體叫做叢集。
    2. Node : 上述的每一個伺服器都叫做Node。
    3. 多子網路叢集 : 意思是跨網段的叢集，例如 A在台北，B在高雄，那他們用的網段就有可能不一樣，甚至不用跨區域，一家公司就有可能防火牆分配不同網段，而SQL Server可以將這些不同網段的節點，作成一個叢集。
    4. OR / AND 條件約束 :
       1. OR : A IP、B IP 對使用者來說，只要A OR B 其中一個有通，系統就活著。
       2. AND : 所有IP 都有通才活著。
    5. 所以整個操作方式就是
       1. 在Node A上跑進階叢集準備，跑完之後會給一份設定檔。
       2. 然後到Node B、Node C上面也跑進階叢集準備，但這次用第一步給的設定檔去跑。
       3. 隨便挑一台在上面跑進階叢集完成，這樣就好了。
11. SQL Server Sysver 這個他會用SQL Server的Sysprep 來安裝一個純淨的 SQL Server instance，她會不包含任何帳戶、電腦、網路資訊。
12. 最大的用途就是他可以跟Windows Sysprep結合使用，如果公司有很多虛擬機，就可以把SQL Server 封裝到一個Windows Template裡，以後只要開新的虛擬機就直接裝好SQL Server省時間又確保資料庫的一致性。

選項

這是選安裝媒體的路徑，他是下載的那個ISO檔問你要放哪裡。

這個東西最好保留，雖然他平常根本不會用到，但是如果有一天要新增某個功能，或是要用前面說的修復，那他一定要讀這個當初的原始安裝檔，所以雖然沒有用，但是最好留著他容量也沒有很大。

雖然原始檔不見了還是可以有辦法把原始檔弄回來，但是很麻煩所以最好還是留著。

重新下載，要載年份版本一模一樣的，cu那些都要完全一樣。

這就很難找，所以還是原始那份留下來好。

如果你真的按照我的操作跟著我一起做，那你要保留它，後面某個地方，我會用到這個東西。

安裝獨立的 Database Engine Instance

所有的安裝功能我都會寫，但該功能真正的功用我會擺在其他篇，太長了這樣這邊會寫不完。

準備

前面都是一路下一步

每一個版本的順序可能會不同，所以如果你不是安裝2025的話，你看到的順序跟我的可能會有差異，但沒有關係都是一樣的，例如我的一開始就是跳出下面那張圖

第一個這個圖，強烈建議不要勾自動更新，微軟更新什麼你不知道或是他在妳業務巔峰的時候更新你也不知道，所以不要自動更新，自己以後手動更新就好。

然後跑檢查，這邊防火牆跳驚嘆號是正常的，一開始裝，什麼都沒設定過，這是正常的
根據預設Windows 防火牆還沒被設定允許SQL Server流量通過，所以要去建立規則，以便使用者應用程式可以跟這個Instance通訊，這邊直接下一步就好，之後會在說明這個防火牆設定。

然後一路下一步

特徵選取

到這裡就不要再無腦下一步了
只需要勾
資料庫引擎服務
SQL Server 複寫 就好

下面還有三個選根目錄的地方，那是選Instance 跟 共用功能的目錄，最好把他們放在別的槽不要跟作業系統共用硬碟。

Database Engine 相關聯的資料夾將會被命名為 MSSQL17.[InstanceName]，其中 instance name 就是執行個體名稱，或者是預設執行個體的 MSSQLSERVER。

此資料夾名稱中的數字 17 與 SQL Server 的版本有關，對於 SQL Server 2025 而言就是 17。這沒有什麼特別的意思

重點是這個資料夾裡面會是預設的mdf、ldf、backup放的地方，雖然以後都可以改路徑，但是最好一開始就把他放到上一篇安裝前規劃說的準備好的 RAID 上，比較簡單。

其他的不勾是因為沒有用到，如果以後有要用再來安裝就好，保持這個好習慣。

執行個體組態頁面

這邊是讓你設定Instance名字的，名字最好跟自己的開發團隊或公司討論過，取一個有意義的名字，盡量不要用預設的。

當公司規模越來越大，一個Instance不夠用的時候，你又都取預設名稱，會讓人不知道這個是用來幹嘛的。

補充說明一下，一個伺服器最多可以裝50個Instance；如果是node 在SMB之下也是50個，但如果是叢集磁碟的話就只剩下25個。

最後預設Instance 名稱雖然事後也可以改，但這是不好的實務做法，因為這個 ID 除了給使用者看以外，他還是用來識別登錄檔機碼與安裝目錄的。

伺服器組態

這裡有兩個頁籤，先講服務帳戶

服務帳戶

這個東西有點超出 SQL Server 的範圍，如果你只是要學習用好 SQL Server，那這你會看不太懂，所以如果你是 RD，寫後端的就直接跳過吧。
因為這是 Windows Server 的東西。
但以一個 DBA 的角度來說，這東西是有必要去了解一下的，最好配合你的 IT 團隊。
這個在 HA 的時候會很重要。

因為這裡是在寫 SQL Server，所以帳戶名稱實際上代表什麼我就不提了，我只說一些微軟的建議和我的看法。

微軟的最佳實務做法是為每個服務使用獨立的帳戶，並確保環境中的每台伺服器都使用一組獨立的服務帳戶。這目的是徹底強制執行最低權限原則。

就安全而言這是好事，但是現實中你要為了一個Instance 就開好幾個帳號，然後每一個Instance 一樣的東西都再重複開一次，會亂到一個不行，另外如此嚴謹的帳號分級，在災難復原的時候會有增加停機時間的風險。

但另一方面，我曾經看過服務帳戶非常粗糙的SQL Server，他甚至只有一組帳號，那在一整個組織裡全部都用這組帳號，有一天這組帳號需要90天更換密碼，或是這組帳號有什麼問題，這會導致全組織的SQL Server停機。

所以這個問題沒有一個標準答案，最好的解決方案取決於每一個公司或是專案的需求與限制。

我個人建議為每個資料層應用程式設定一個獨立的服務帳號。

意思是假如今天有一個應用程式環境如下

兩個節點的叢集  —2

一個ETL伺服器 —1

兩個災難復原伺服器 —2

那麼這種情況這五個 Instance 都共用一組服務帳號，但是另外一個新的應用程式就再給他開一組新的帳號，並且跟原本這組不互通，用這種方式去分帳號。

但是這種做法如果有一天要進行整併，就會需要檢閱並修改這個規則，所以沒有一個做法是完美的。

基於這個原因 ( 密碼原則等等 )，微軟引入虛擬帳戶與 MSA

1. 虛擬帳戶
2. MSA

但是上述這兩種帳號都有一個限制就是只能在單一伺服器上使用，所以如果遇到高可用性、多伺服器的狀況就沒辦法用了。

這個問題可以透過 gMSA 來解決，不過得在Windows Server 2012 以上才能使用。

因為這邊都是在講SQL Server，所以Windows 帳號不會細講，但額外補充一點

1. 虛擬帳戶的意思是電腦本機會自己產生一組帳號，不需要密碼也不需要被設定密碼，自然也沒有密碼過期這件事。但他只能本機使用。
2. MSA是AD發出的帳號，他一樣類似虛擬帳號，更像是一個會自己換密碼的機器人帳號，使用者一樣不需要知道密碼是什麼。同樣的他只能綁定在單一台特定伺服器上。
3. gMSA他就是MSA，只不過他可以發給一群伺服器了，所以Node A、Node B可以共用這個帳號。

你還會注意到，他最下面有一個打勾的選項，叫做執行磁碟區維護工作權限，這東西就是我在上一篇安裝規劃裡面講過的即時檔案初始化，就打勾吧。

定序

這是用來決定 SQL Server 如何排序資料，還有定義accents、kana、width、case的字元比對行為。

1. accent 是重音法文、西班牙文那種才會有問題，中英文環境不用管。
2. kana 是日文平假名、片假名問題，中英文環境不用管。
3. width 是全半形對應。
4. case 是大小寫對應。
   所以感謝我們是中英環境不用在意這些，只需要在意大小寫這件事有沒有需要就好。
   不過我還是稍微說明一下這是什麼東西
   
   這個查詢範例第一個是依照拉丁文去排，第二個是依照西班牙文去排
   如果你按照西班牙文去排 ch 就會被排在 cz 之後，因為 ch在西班牙文裡面是一個獨立的字元。

上面那種做法是一般定序，另外還有兩種類型的二進位排序可以選，BIN與BIN2。

BIN是直接拿硬碟底層的位元圖案 (01010110101) 這種來比對，但是在處理多國語言的時候會有Bug，這只是微軟為了相容很舊的系統才保留到現在的東西，建議不要用。

BIN2是新版的，他是去看每一個字母在Unicode裡面的編號，而去排序的，目前微軟官方建議使用這個排序。

排序的部分以後會再說明這邊簡單講一點。
1. CS_AI : 認為大小寫是不同的字，大寫排前面。
2. CI_AI : 認為大小寫是同一個字，順序無所謂。
3. BIN2 : 認Unicode 編碼。
定序這東西，一定要在一開始就決定好，因為他事後更改會非常困難，而他會影響到整個日後應用程式排序的問題與效率，所以如果是全新的環境，建議一定要跟使用者和開發團隊討論這個問題。

但是如果不幸現在一定得要更改定序的話，這邊提供修改定序的方法。

1. 重新建立所有的資料庫。
2. 將所有資料匯出到新建立的資料庫副本中。
3. 刪除原始資料庫。
4. 使用想要的定序來重建 Master (主) 資料庫。
5. 重新建立這些資料庫。
6. 從建立的副本，將資料匯回資料庫中。
7. 刪除資料庫的副本。

最後補充，除非有相容性的需求，否則要避免使用 SQL 定序，應該要用Windows 定序；因為SQL 定序已被棄用，而且不是完全跟Windows 相容。

資料庫引擎組態

這裡總共有六個 TAB，這裡也是安裝的最大重點。

伺服器組態

這邊可以選Windows 驗證或是混和驗證。

Windows 驗證是當使用者登入 Windows 時所提供的認證，將會被傳遞給 SQL Server，且該使用者不需要任何額外的認證即可獲取對該執行個體的存取權。

記得要點加入目前使用者，就是下面那個加入目前使用者，現在應該都會自己帶入了但就檢查一下。

混和驗證是除了Windows驗證以外，額外多一個SQL Server 在執行個體內部自行保管使用者的使用者名稱與密碼。

最安全的方式是只開Windows 驗證，但是在某些情況確實必須開混和驗證，例如應用程式不支援Windows、應用程式寫死使用第二層及驗證。

但是要注意，SQL Server自己的帳號密碼，他不像 Windows 一樣可以設定錯誤幾次就鎖定，他是沒有阻擋機制的，所以他是有可能被暴力破解，因此密碼要複雜一點。

資料目錄

這是設定資料庫預設要放在哪裡，這裡面會包含mater 等等，根據前面的安裝規劃，這裡應該要把它改成對應的儲存位置。

TempDB

這是一個非常重要的設定
TempDB 跟第一篇說的一樣，TempDB在大型資料庫中非常重要，他會是效能調教的其中一大重點，微軟甚至為他單獨做一個tab出來，所以這裡的數值要慎重考量。

但是除非是大型專案，否則預設的參數就足夠應付。

首先是檔案位置，前面提到過有人會建議放在RAID 0，但我也說過為什麼我不認同，所以這邊自行選擇。

再來是檔案數目，這個檔案數量非常重要，因為檔案太少會導致系統分頁發生爭用，例如GAM和SGAM。

Page 與 Extent 已經說過是什麼了就不再提，這邊說明一下GAM跟SGAM

假設現在有1000筆指令湧入資料庫，SQL Server要知道硬碟哪裡有空的Page 可以寫資料，還要知道那他要放在硬碟上的哪一個 Extent ? 哪一個Page ? 不可能從頭到尾掃描一次硬碟，那太慢了。

所以SQL Server 會在資料庫檔案的最前面幾頁保留幾個特殊的目錄分頁也就是
1. GAM ( Global Allocation Map) : 他就類似停車場入口的電子看板，專門記錄哪一個區塊 ( Extent ) 是空的，然後只要指令去看這個看板，他就能馬上知道要去哪一個硬碟空間。
2. SGAM ( Shared Global Allocation Map ) : 這是另一種看板，他記錄的是哪一個區塊還有剩下零星的空位。

回到一開始假設的狀況，如果一次 1000 筆查詢湧進TempDB，第一步動作都是去搶看同一面 GAM/SGAM電子看板想找空位，但是你設定的檔案數量又很少，假設只有一個，那麼大家就得排隊，後面的查詢排隊，前面的還在看看板，就造成分頁爭用，你的效能就低落。

所以只要把他的看板，也就是檔案數變多就可以有更高的效率，通常來說，最佳的檔案數量是 : SMALLEST( 核心數, 8)

按照上面的說法，看起來會變得很像只有寫入的時候才會影響；但其實很複雜的查詢其實也是有寫入暫存表的動作發生。例如 ORDER BY、GROUP BY、JOIN
假設一次SELECT * 然後會有一萬筆資料，接下來還要進行ORDER BY，那SQL Server 其實會把這些資料都寫進TempDB，然後才在裡面慢慢挪動、排好。
所以其實只是SELECT 的話，也是會受到TempDB這個寫入的影響。

為什麼最佳檔案數是 SMALLEST( 核心數, 8) ?
你可能會想，那我把這個檔案數量條的越高，效率不就越好? 但其實不是。
SQL Server 有一個叫做 Proportional Fill 演算法的東西，每當有資料要寫入TempDB時，為了避免某一個檔案被塞爆，SQL Server會強迫把寫入的工作，平均分配給所有TempDB檔案。
基於這個演算法所以給TempDB的檔案不是越多越好，如果一次就開64個檔案，那SQL Server 每次寫入的時候都要去問一次這64個檔案，確認哪裡還有空位，再把資料分成64份，分別送過去，效率就大減。
選最小核心數是因為一個核心配一個檔案是非常剛好；如果核心數超過8，檔案分成8份是微軟建議，他們發現8個檔案已經足以應付絕大多數情況。

一般來說預設都會是8，但在安裝的時候最好檢查一下，如果今天已經正在運行的系統，可以用以下語法查詢TempDB檔案數量。

這邊我想吐槽一下，為什麼不給我直接貼 SQL 語法 ==

接下來如果想新增檔案就用下面這個

這裡有一個小細節
大小全部都一樣的原因是因為，如果今天大小不一樣，那根據剛剛說的SQL Server那個等比例分散寫入的演算法，他會把資料全部都塞進那個空間最大檔案的地方，那你有新增跟沒新增就一樣了，因為還是一樣全部卡在最大的檔案那裏。
以後如果有要新增任何檔案，也最好遵循這個做法。

如果想確定到底有沒有發生分頁爭用，在查詢發生的時候，用下面這個

然後我簡單示範一下什麼叫做分頁爭用


這個結果可以解釋

1. 等待類型 pagelatch_sh 代表在搶SGMA的控制權。
2. 2:1:16 代表 2 = TempDB、1 = 第一個資料檔、16 = 第16號分頁。
3. 2:1:16 (LATCH 0x0000021E83CD9ED8: Class: BUFFER KP: 1 SH: 0 UP: 0 EX: 1 DT: 0 Sublatch: 0 HasWaiters: 1 Task: 0x0000021AAF6EF828 AnyReleasor: 0)
   1. EX : 1 代表目前有一個人獨佔鎖定
   2. HasWaiters : 1 有人正在排隊
4. 如果說實際情況8個檔案真的還是發生了爭搶，那再去加TempDB檔案，一次4個4個慢慢加。

檔案數量確定好之後，再來是講初始大小，我通常會遵循這個經驗法則：SUM(所有使用者資料庫的資料檔案大小) / 3，但這會根據需求以及使用者資料庫的工作負載而有所不同。

MaxDop & 記憶體

在這裡可以指定分配給Instance 的最大最小記憶體數量跟核心數量。微軟會給建議值直接用就好了
最佳化記憶體以後再寫。

但原則不是硬體有多少就給多少，要預留一點buffer。

我會在之後的篇章裡面寫平行處理跟記憶體最佳化，那個篇幅很大這裡放不下了。

Filestream

這東西是當你有超大檔案要存取的時候用的，例如圖片、影片、pdf等等。

一般會用的作法是SQL Server 存路徑，然後應用程式去跟資料庫要這個路徑，然後再去資料夾裡面拿資料。

但這會有一個問題就是，如果資料夾裡的東西被刪除了，然後資料庫又沒有把這筆路徑刪除，那就會造成資料庫跟真實情況不相符的狀況。

還有一點是當你要備份的時候，除了資料庫本身要備份之外，這個資料夾也要一起備份。

最後就是還源的時候路徑必須一模一樣，C或D 槽那種路徑。

FileStream是用來解決這個問題的東西，你一樣是在SQL 裡面下INSERT 把圖片存進去，但他會直接把圖片丟到實體資夾裡，而不是MDF，如果今天是在sql 下delete 指令，那實體的圖片也會跟著刪除。

然後就下一步開始安裝
下一篇開始設定 INSTANCE