常見的最佳做法

本頁面提供最佳做法，有助您實現 Cloud SQL 的最佳效能、耐用性和可用性。

如果 Cloud SQL 執行個體發生問題，請在排解問題時查看下列項目：

執行個體設定與管理

最佳做法 更多資訊
請詳讀並遵守操作指南，以確保您的執行個體在 Cloud SQL 服務水準協議的涵蓋範圍內。
設定主要執行個體的維護期間，以便控制發生中斷型更新的時間。 請參閱維護期間。
如果您會定期刪除和重新建立執行個體，請使用執行個體 ID 中的時間戳記來提高新執行個體 ID 可用的可能性。
前一項作業完成之前，請勿開始進行管理作業。

Cloud SQL 執行個體要待到完成前一項作業後，才能接受新的作業要求。如果試圖提前啟動新作業，作業要求會失敗。重新啟動執行個體也包含在內。

Google Cloud 主控台中的執行個體狀態不會顯示作業是否正在執行。綠色勾號只代表執行個體的狀態為 RUNNABLE。如要查看是否正在執行作業，請前往「Operations」(作業) 分頁查看最新的作業狀態。
設定儲存空間，以因應重要的資料庫維護作業。

如果停用「enable automatic storage increases」(啟用自動增加儲存空間) 執行個體設定，或啟用「automatic storage increase limit」(自動增加儲存空間上限)，請確保至少有 20% 的可用空間，以便容納 Cloud SQL 可能執行的任何重要資料庫維護作業。

如要在可用磁碟空間低於 20% 時收到警告，請為「磁碟使用率」指標建立以指標為基礎的警告政策，並將「高於門檻」位置的值設為「0.8」。詳情請參閱「建立以指標為基礎的快訊政策」。
避免 CPU 使用率過高。

您可以在 Google Cloud 控制台的執行個體詳細資料頁面，查看執行個體使用的可用 CPU 百分比。詳情請參閱「指標」。您也可以使用「建立指標門檻快訊政策」監控 CPU 使用率，並在達到指定門檻時接收快訊。

為避免過度使用，您可以增加執行個體的 CPU 數量。變更 CPU 需要重新啟動執行個體。如果執行個體已達 CPU 數量上限，則必須將資料庫分片至多個執行個體。
避免記憶體耗盡。

如要尋找記憶體耗盡的跡象，主要應使用「用量」指標。為避免記憶體不足錯誤，建議這個指標維持在 90% 以下。

您也可以使用 total_usage 指標，觀察 Cloud SQL 執行個體使用的可用記憶體百分比，包括資料庫容器使用的記憶體，以及作業系統快取分配的記憶體。

觀察這兩項指標的差異，即可判斷程序使用的記憶體量，以及作業系統快取使用的記憶體量。您可以在這個快取中重新利用記憶體。

如要預測記憶體不足問題，請同時檢查這兩項指標並一起解讀。如果指標顯示高值，執行個體可能記憶體不足。這可能是因為自訂設定、執行個體大小不符工作負載，或這些因素的組合所致。

調度 Cloud SQL 執行個體資源，增加記憶體大小。 變更執行個體的記憶體大小需要重新啟動執行個體。 如果執行個體已達記憶體大小上限，您必須將資料庫分片到多個執行個體。如要進一步瞭解如何在 Google Cloud 控制台中監控這兩項指標，請參閱「指標」一文。
設定 SQL Server，確保在 Cloud SQL 中發揮最佳效能。 請參閱 SQL Server 設定。
針對測試執行程序，以最佳方式調整執行個體。 下表列出適合測試執行的設定值。
  • vCPU：40
  • 記憶體：262144 MB
  • MAXDOP：8
  • 平行處理費用門檻：120
  • tempdb 檔案：8。預先調整大小，避免自動成長。
  • 使用者資料庫檔案：自動成長設定為 64-128 MB。預先調整大小，避免自動成長。
  • 儲存空間：>= 4TB，以獲得最佳 IOPS
部署 SQL Server 前，請先判斷 I/O 子系統的容量。

測試各種 I/O 類型和大小。從 SQL Server 發送至永久磁碟儲存空間的 I/O 大小，會影響 IOPS 和總處理量。SQL Server 工作負載達到 IOPS 上限或輸送量上限時，就會受到節流。Cloud SQL 使用的儲存空間類型為永久磁碟 SSD，適合用於高效能的企業級工作負載。

請按照下列步驟自訂 VM，盡可能提升效能：

  • 磁碟大小為 4 TB 以上時，可提供更高的總處理量和 IOPS。
  • vCPU 越多，IOPS 和總處理量就越高。使用較高的 vCPU 時，請監控資料庫等待的平行處理作業，這項作業也可能會增加。
  • 如要達到最佳效能，請平行發出 I/O，以提高 I/O 佇列深度。
避免索引過於分散和缺少索引。 視資料變更頻率而定，重新整理索引或設定排程來重建索引。此外，請設定適當的填滿因數，以減少片段化。監控 SQL Server 是否有缺少的索引，這些索引可能有助於提升效能。
定期更新統計資料。 如果統計資料過時，SQL 查詢最佳化工具可能會產生次佳的查詢計畫。 更新統計資料，尤其是在大量資料變更後。使用查詢存放區監控及排解 SQL Server 的問題，這類伺服器有查詢計畫不盡理想的情況。
避免資料庫檔案變得過大。

以 MB 為單位設定 autogrow，而非以百分比為單位，並使用符合需求的增量。此外，您也可以在自動擴充功能啟動前，主動管理成長。

此外，請務必啟用 Cloud SQL 的「啟用自動增加儲存空間」功能，這樣一來，如果資料庫和執行個體空間不足，Cloud SQL 就能增加儲存空間。
每週至少執行一次 DBCC CHECKDB ，偵測資料庫完整性問題。 DBCC CHECKDB 會檢查資料庫中所有物件的完整性。 每週執行 DBCC CHECKDB，確保資料庫沒有損毀。 DBCC CHECKDB 是耗用大量資源的作業，可能會影響執行個體的效能。
請勿在正式伺服器上執行 DBCC CHECKDB。
建議您改用下列任一選項，不要在正式伺服器上執行 DBCC CHECKDB：
  • 複製資料庫，並在複製的資料庫上執行 DBCC CHECKDB。
  • 將備份還原至其他執行個體，然後在還原的執行個體資料庫上執行 DBCC CHECKDB。 如要進一步瞭解如何還原執行個體，請參閱「還原執行個體」。

使用下列程式碼片段在資料庫上執行 DBCC CHECKDB：

  • (建議) 執行 DBCC CHECKDB，並使用 EXTENDED_LOGICAL_CHECKS。 這項檢查較為全面，但會耗用更多資源。 
          USE DATABASE_NAME
      DBCC CHECKDB WITH EXTENDED_LOGICAL_CHECKS,
      DATA_PURITY,NO_INFOMSGS, ALL_ERRORMSGS
  • 使用 PHYSICAL_ONLY 執行 DBCC CHECKDB： 
          USE DATABASE_NAME
      DBCC CHECKDB WITH PHYSICAL_ONLY,
      NO_INFOMSGS, ALL_ERRORMSGS

發揮最大效能

如要確保資料安全無虞，並讓應用程式透過記憶體內 OLTP 資料表順暢運作，請考慮採用下列最佳做法：

最佳做法 更多資訊
遵循記憶體最佳化資料表的 Microsoft 最佳做法
  • 定期備份：請務必為資料庫安排定期備份。如果資料毀損，您就能將資料還原至最後一個已知的安全狀態。
  • 備份驗證：由於記憶體最佳化資料表無法使用 DBCC 修復選項，建議您定期執行還原作業，測試備份是否正常。如果記憶體最佳化資料表發生資料完整性問題，您必須從最後一個已知的安全備份還原。

如要進一步瞭解限制，請參閱不支援的 SQL Server 記憶體內 OLTP 功能。

安全性

最佳做法 更多資訊
偏好使用私人 IP 除非需要公開 IP 存取權，否則建議使用私人 IP。這有助於盡量減少未經授權的網路連線連至資料庫。
避免在授權網路中使用 0.0.0.0/0 請避免在「已授權的網路」中加入 0.0.0.0/0，因為這樣會允許從全球網際網路無限制地存取。
避免授權網路過大 請避免在「授權網路」中使用小型 CIDR 前置字串，因為這可能會允許過多的主機存取。建議使用不小於 /16 的 CIDR 前置字元，最好大於 /19。

資料架構

最佳做法 更多資訊
盡可能將大型執行個體分割為較小的執行個體。 請盡量使用多個小型 Cloud SQL 執行個體，效果會比使用單個大型的執行個體更好。大型單體式執行個體在管理上會比多個小型執行個體更困難。
請勿使用過多的資料庫資料表。

請將執行個體的表格數量控制在 10,000 個以下。資料庫資料表過多，會影響資料庫升級時間。
資料庫定序 無論是安裝新的 SQL Server 執行個體、還原資料庫備份，還是將伺服器連線至用戶端資料庫，瞭解所用資料的語言環境需求、排序順序，以及大小寫和重音符號的區分方式，都非常重要。為伺服器、資料庫、資料欄或運算式選取定序時，您會為資料指派特定特徵。這些特徵會影響資料庫中許多作業的結果。舉例來說，當您使用 ORDER BY 建構查詢時，結果集的排序順序可能取決於套用至資料庫的對照順序，或查詢運算式層級的 COLLATE 子句中指定的對照順序。進一步瞭解資料庫排序規則和 Unicode 支援。
查詢設計 為獲得最佳資料庫或查詢效能，請確保您未在同一個查詢中使用大量資料表 (十六個以上)。
查詢監控 查詢品質可能會隨時間下降。請務必持續監控應用程式和查詢效能。造成這類效能下降的原因之一是雜湊值脫逃。
遞迴雜湊聯結或雜湊救援會導致伺服器效能降低。如果追蹤記錄中出現許多雜湊警告事件，請更新要聯結的資料欄統計資料。進一步瞭解雜湊救援。

應用程式實作

最佳做法 更多資訊
使用適合的連線管理做法，例如連線集區和指數輪詢。 使用這些技術可改善應用程式的資源運用，也有助於遵守 Cloud SQL 連線限制。如需詳細資訊和程式碼範例，請參閱「管理資料庫連線」。
測試應用程式對維護更新的回應，更新在維護期間隨時可能會發生。 請嘗試自助式維護，模擬維護更新。維護期間，執行個體會短暫無法使用，現有連線也會中斷。測試維護作業推出，可協助您進一步瞭解應用程式如何處理排定的維護作業，以及系統的復原速度。
測試應用程式對於容錯移轉的回應，容錯移轉隨時可能發生。 您可以使用 Google Cloud 控制台、gcloud CLI 或 API 手動啟動容錯移轉。請參閱「啟動容錯移轉」。
避免進行大量交易。 盡量維持小型的簡短交易。如果需要更新大型資料庫，請分成多項小型交易進行，而非進行單次的大型交易。
如果使用 Cloud SQL 驗證 Proxy，請務必使用最新版本。 請參閱「保持 Cloud SQL 驗證 Proxy 的最新狀態」。

資料匯入與匯出

最佳做法 更多資訊
加速匯入小型執行個體。 針對較小的執行個體，您可以暫時增加執行個體的 CPU 和 RAM，以改善匯入較大資料集時的效能。
如果正在匯出資料以匯入至 Cloud SQL，請務必採用正確程序。 請參閱「 從外部代管的資料庫伺服器匯出資料」。

備份與還原

最佳做法 更多資訊
使用合適的 Cloud SQL 功能保護您的資料。

備份和匯出是提供資料備援和資料保護的方式。這兩種方式可在不同情境下各自提供保護，在健全的資料保護策略中下，兩者相輔相成。

建立備份既輕鬆又快速，能夠將執行個體上的資料還原至你在備份時的狀態。不過備份有一些限制。如果刪除執行個體，也會一併刪除備份。您無法備份單一資料庫或資料表。而且如果執行個體所在的地區無法使用，即使您身在可用的地區，也無法透過備份還原執行個體。

匯出所需的時間較長，因為會在 Cloud Storage 建立外部檔案，讓您用來重新建立資料。即使刪除執行個體，也不會影響到匯出的資料。此外，您只能匯出單一資料庫或資料表，視您選擇的匯出格式而定。

在 Enterprise 或 Standard SQL Server 執行個體上使用匯出備份功能時，請避免建立 GZ 封存檔案，因為系統會嘗試壓縮 SQL Server 已原生壓縮的備份檔。
避免執行個體和備份資料遭到意外刪除。

在 Google Cloud 控制台或透過 Terraform 建立的 Cloud SQL 執行個體，預設會啟用防止意外刪除功能。

使用 Cloud SQL 的匯出功能匯出資料，以獲得額外保護。搭配使用 Cloud Scheduler 和 REST API，自動管理匯出作業。如要處理更進階的情境，請搭配使用 Cloud Scheduler 和 Cloud Run functions 進行自動化。

SQL Server 設定

建議您為 Cloud SQL 採用部分 SQL Server 設定。下列主題說明一些建議。

全域設定

設定 建議
max worker threads 保留預設值 0。這項設定會根據 CPU 數量，定義 SQL Server 可用的執行緒數量。這個值會在啟動時由 SQL Server 引擎自動計算。
max server memory (mb)

這個標記會限制 Cloud SQL 可為內部集區分配的記憶體量。

建議您讓 Cloud SQL 管理這個旗標的值。如果必須手動管理這個值，請使用本節稍後說明的公式。

如果您未設定這個旗標的值，Cloud SQL 會根據執行個體的 RAM 大小自動管理值。如果您未設定旗標值，且調整執行個體大小，Cloud SQL 會自動調整旗標值，以符合新執行個體大小的建議。這項調整大小作業也會移除此標記的所有手動設定值。這有助於資料庫更有效率地運用資源，避免過度分配資源、減少因記憶體不足而當機的可能性，以及避免執行個體效能下滑。

如要管理這個旗標的值，請手動設定。因此，Cloud SQL 會停用自動管理功能。如果調整執行個體大小，系統會捨棄手動輸入的值。調整執行個體大小會重新啟用自動標記管理功能。如果要在調整大小後手動控制旗標值，請輸入新值來重新啟用手動控制。建議您重新調整值，以符合新尺寸的建議值。

如果必須手動管理旗標的值，建議使用下列公式設定 max server memory (mb) 資料庫旗標：

  • 為 OS 和代理程式保留 1.4 GB 的記憶體。
  • 如果伺服器上的 RAM 小於或等於 16 GB，則每 4 GB 的 RAM 保留 1 GB 的記憶體。
  • 如果伺服器上的 RAM 大於 16 GB，請保留 4 GB 的記憶體，並為大於 16 GB 的每 8 GB RAM 保留 1 GB 的記憶體。

舉例來說，如果執行個體的 RAM 為 104 GB
(106496 MB)，請預留：

  • 作業系統和代理程式需要 1.4 GB 的記憶體
  • 4 GB 記憶體，因為 104 GB 大於 16 GB
  • 11 GB 的記憶體，因為 RAM 為 88 GB，大於 16 GB (104-16=88)，而 88 除以 8 等於 11

在本例中，您必須保留 16.4 GB 的記憶體。因此，請為這個標記指定 89702 MB
的值 [(104 - 16.4) * 1024 = 89702]。

下表列出一些熱門虛擬機器 (VM) 層級的建議值和總 RAM 百分比：

執行個體層級 (MB) max server memory (mb) 百分比 (總計)
3840 1440 37
4096 1632 39
5792 2912 50
8192 4704 57
11584 7248 62
16384 10848 66
23168 16800 72
32768 25200 76
46336 37072 80
65568 53888 82
92704 77648 83
131136 111248 84
185440 158784 85
262272 226000 86
370880 321056 86
524544 455488 86
741792 645600 87

如要監控執行個體的記憶體用量，請使用下列指標：

  • database/memory/usage
  • database/sqlserver/memory/buffer_cache_hit_ratio
  • database/sqlserver/memory/memory_grants_pending
  • database/sqlserver/memory/page_life_expectancy

詳情請參閱「監控 Cloud SQL 執行個體」。

要修改的資料庫設定

為確保 SQL Server 資料庫效能最佳化，請按照下列建議設定 SQL Server 設定。

設定 建議
cost threshold for parallelism

這是 SQL 最佳化工具使用平行處理執行查詢的門檻。5 的預設值可能會導致過多查詢並行執行，進而增加並行執行緒的資料庫等待時間。如要減少這類爭用，請增加值。

如果 maxdop 設為 1，系統會忽略這個值。

max degree of parallelism (MAXDOP)

如要減少因平行處理而導致的資料庫等待時間，請根據有關可用邏輯處理器數量的特定建議調整這個值。如果將這個選項設為 1，請仔細評估成效。
optimize for ad hoc workloads

避免方案快取中出現大量一次性方案。 如要提升含有許多一次性臨時批次作業的工作負載的方案快取效率，請將這個選項設為 1。
tempdb

預先設定 tempdb 的大小，以免需要自動成長。 tempdb 中的所有檔案大小應相同，且檔案成長設定也應一致。

tempdb 爭用情況的資料庫等待類型會顯示為 PAGELATCH_UP。如要減少爭用情形，請新增更多檔案。

如果處理器數量小於或等於 8，請使用與邏輯處理器數量相同的檔案數。如果處理器數量超過 8 個，請使用 8 個資料檔案。如果爭用情形持續發生，請以 4 的倍數增加檔案數量，直到不再發生爭用情形為止。

視工作負載而定，您可能也想修改下列設定。

設定 建議
Close Cursor on Commit Enabled 預設值為 off，表示您提交交易時，游標不會自動關閉。
Default Cursor 這個選項可控管 T-SQL 程式碼中使用的游標範圍。 變更這項設定時，請評估應用程式程式碼是否會產生任何負面影響。
Page Verify 這個選項可讓 SQL Server 在資料庫頁面寫入磁碟前計算檢查碼，並將檢查碼儲存在頁首中。再次讀取頁面時，系統會重新計算檢查碼，以驗證頁面的完整性。建議值為 checksum。
Parameterization 預設值為 simple。簡單參數化可讓 SQL Server 將查詢中的常值替換為參數。Microsoft 提供相關指南，說明如何變更這個值並搭配計畫指南使用。

要保留的資料庫設定

為確保 SQL Server 資料庫達到最佳效能，請保留下列 SQL Server 設定的預設值。

設定 保留預設值
Auto Close False。開啟這項設定後，系統會在每次連線後開啟及關閉連線，並清除程序。這可能會導致經常存取的資料庫效能下降。
Auto Shrink False。開啟這項功能可能會導致資料庫和索引片段化，以及其他效能問題，這篇 SQL Server 網誌中討論了部分問題。
Date Correlation Optimization Enabled False。啟用這項功能後，最佳化工具就能找出兩個相關資料表之間日期關係，並進行最佳化。在 SQL Server 中追蹤這項資訊會造成一些效能負擔。
Legacy Cardinality Estimation False。在某些情況下，啟用這項設定後，SQL Server 無法準確計算基數。
Parameter Sniffing ON。從資料庫表格中嗅探參數，有助於建立可重複使用的執行計畫。如果資料表中的資料分佈不均，產生的執行計畫可能會導致效能問題。如果需要這類資料，請使用「查詢存放區」的其他選項，而非修改這項設定。
Query Optimizer Fixes False。啟用後，可能會影響 SQL Server 基數估算工具的效能。如果選擇啟用，請進行測試，確保沒有查詢回歸。
Auto Create Statistics True。這個選項可讓 SQL Server 建立單欄統計資料，進而改善查詢計畫的基數估計值。
Auto Update Statistics True。這個選項可讓 SQL Server 使用以資料表基數為準的重新編譯門檻，更新過時的統計資料。
Auto Update Statistics Asynchronously False。啟用這項選項後，SQL 查詢最佳化工具會使用目前查詢執行的過時統計資料，同時非同步更新統計資料，以利日後的工作負載。

不過，如果您預期經常執行的查詢會有可預測的回應時間，或應用程式在等待統計資料更新時，經常發生用戶端要求逾時的情況，請考慮啟用這個選項並停用 Auto Update Statistics。

Target Recovery Time (Seconds) 60。這項設定會更頻繁地將緩衝區集區中的髒頁面排清至磁碟，藉此為資料庫的復原時間設定上限。對於交易量大的工作負載，如果這項設定的值較低，且儲存空間 IOPS 接近最大值，可能會導致效能瓶頸。

追蹤記錄旗標設定

SQL Server 中的追蹤記錄旗標可用於設定特定特徵、變更 SQL Server 資料庫的行為，或偵錯 SQL Server 中的問題。

Cloud SQL 支援部分 SQL Server 追蹤記錄旗標，可使用資料庫旗標設定。建議設定如下。

追蹤旗標 建議
1204 Yes，但會產生大量死結的工作負載密集型伺服器除外。

傳回參與死結的資源和鎖定類型，以及目前受影響的指令。
1222 Yes，但會產生大量死結的工作負載密集型伺服器除外。
1224 No。這可能會導致記憶體用量增加，並對資料庫造成記憶體壓力。
2528 No。物件的平行檢查功能是預設設定，建議您使用這項功能。資料庫引擎會自動計算平行處理程度。
3205 No. 磁帶機備份是 SQL Server 適用的 Cloud SQL 功能。
3226 No，除非您需要頻繁備份，例如 TLOG 備份。
3625 No。由於根帳戶沒有系統管理員存取權，可能無法查看所有錯誤訊息。
4199 No。這會影響基數估算器，並導致查詢回歸。
4616 No。這項限制會降低應用程式角色的安全性。必須根據應用程式需求進行驗證。
7806 Yes。如果資料庫伺服器沒有回應，專屬的管理員連線 (DAC) 可能就是唯一能建立連線以進行診斷的方式。