SQL Server 連線字串完整指南：關鍵字對照、Windows 驗證 vs SQL 驗證、最佳實務建議

ADO.NET 連線字串關鍵字繁多且同義詞多，本文整理核心關鍵字對照表，對比 Windows 整合驗證與 SQL Server 驗證的寫法與優劣，提供安全、效能、維護三大面向的最佳實務建議，助你寫出正確、穩健的連線字串。

核心關鍵字同義詞對照表

兩種驗證模式連線字串範例

1. SQL Server 驗證 (帳號密碼)

// 標準寫法
string connStr = "Server=localhost;Database=Northwind;User ID=sa;Password=P@ssw0rd;";

// 簡寫 (同義詞)
string connStr = "Data Source=.;Initial Catalog=Northwind;UID=sa;PWD=P@ssw0rd;";

缺點：密碼明文出現在程式碼/設定檔，需額外加密保護 (如 web.config aspnet_regiis -pe 或 Azure Key Vault)。

2. Windows 整合驗證 (推薦)

// 寫法一：Integrated Security
string connStr = "Server=localhost;Database=Northwind;Integrated Security=SSPI;";

// 寫法二：Trusted_Connection
string connStr = "Server=localhost;Database=Northwind;Trusted_Connection=Yes;";

// 寫法三：明確指定 True
string connStr = "Server=localhost;Database=Northwind;Integrated Security=True;";

三者等效，SSPI 為標準值，相容性最佳。

Windows 整合驗證 4 大優勢 (生產環境首選)

1. 零密碼管理：無密碼輪換、洩漏、硬編碼風險。
2. Kerberos/NTLM 單一登入：使用者登入網域後無感存取，體驗最佳。
3. 連線池效能更好：同一 Windows 身分共用連線池，減少重新驗證開銷。
4. 審計追蹤精確：SESSION_USER / ORIGINAL_LOGIN() 直接對應真實人員，非共用 sa。

連線字串最佳實務清單

常見錯誤與除錯

• Keyword not supported: 'xxx' → 關鍵字拼寫錯誤 (如 DataSource 缺空格)。
• Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON' → 雙躍點問題，需設定 Kerberos 委派或改用 SQL 驗證。
• SSL Provider: The target principal name is incorrect → TrustServerCertificate=True 或部署有效憑證。

正確的連線字串是應用程式與資料庫穩定溝通的基石，遵循「Windows 驗證優先、關鍵字標準化、設定檔加密、監控可觀測」四原則，能省去 90% 的連線相關故障。