常見的最佳做法

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

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

執行個體設定與管理

最佳做法 更多資訊
請詳閱並遵循操作指南，確保執行個體符合 Cloud SQL 服務水準協議的涵蓋範圍。
為主要執行個體設定維護期間，控管中斷性更新的執行時間。 請參閱「維護期間」。
如果您經常刪除及重新建立執行個體，請在執行個體 ID 中加入時間戳記，提高新執行個體 ID 可用的可能性。
請勿在前一項作業完成前啟動管理作業。

Cloud SQL 執行個體必須先完成先前的作業，才會接受新的作業要求。如果試圖提前啟動新作業，作業要求會失敗。包括重新啟動執行個體。

Google Cloud 控制台中的執行個體狀態不會反映作業是否正在執行。綠色勾號僅表示執行個體處於 RUNNABLE 狀態。如要查看作業是否正在執行，請前往「Operations」(作業) 分頁，查看最近一次作業的狀態。
設定儲存空間，以便進行重要的資料庫維護作業。

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

如要在可用磁碟空間低於 20% 時收到警告，請針對磁碟使用率指標建立指標式警告政策，並將位置設為高於門檻，值設為 .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：

  • (建議) 使用 EXTENDED_LOGICAL_CHECKS 執行 DBCC CHECKDB。 這項檢查較為全面，但會耗用更多資源。 
          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 修復選項不適用於記憶體最佳化資料表，建議您定期執行還原作業來測試備份。如果記憶體最佳化資料表發生資料完整性問題，您必須從上次已知的安全備份還原。

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

安全性

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

資料架構

最佳做法 更多資訊
盡可能將大型執行個體分割成較小的執行個體。 如果可以，建議使用多個較小的 Cloud SQL 執行個體，而非單一大型執行個體。管理大型單體式執行個體時，會遇到一組小型執行個體不會遇到的挑戰。
請勿使用過多的資料庫資料表。

請將執行個體的資料表數量控制在 10,000 個以下。資料庫資料表過多可能會影響資料庫升級時間。
資料庫定序 無論是安裝新的 SQL Server 執行個體、還原資料庫備份，還是將伺服器連線至用戶端資料庫，都必須瞭解所處理資料的語言代碼需求、排列順序，以及大小寫和重音符號區分。為伺服器、資料庫、資料欄或運算式選取定序時，您會為資料指派特定特性。這些特性會影響資料庫中許多作業的結果。舉例來說，使用 ORDER BY 建構查詢時，結果集的排序順序可能取決於套用至資料庫的定序，或查詢運算式層級中 COLLATE 子句指定的定序。進一步瞭解資料庫定序和 Unicode 支援。
查詢設計 為確保資料庫或查詢效能達到最佳狀態，請勿在同一查詢中使用大量資料表 (16 個以上)。
查詢監控 查詢效能可能會隨著時間降低。請務必持續監控應用程式和查詢效能。造成這種降級的原因之一是雜湊救援。
遞迴雜湊彙整或雜湊緊急救援會降低伺服器效能。如果您在追蹤記錄中看到許多雜湊警告事件，請更新要彙整的資料欄統計資料。進一步瞭解雜湊救援。

應用程式實作

最佳做法 更多資訊
採用良好的連線管理做法，例如連線集區和指數輪詢。 使用這些技術可改善應用程式的資源使用情形，並協助您遵守 Cloud SQL 連線限制。如需更多資訊和程式碼範例，請參閱「管理資料庫連線」。
測試應用程式對維護更新的回應，維護更新可能在維護期間的任何時間發生。 請嘗試自助式維護，模擬維護更新。維護期間，執行個體會短暫無法使用，現有連線也會中斷。測試維護作業推出作業，可讓您進一步瞭解應用程式如何處理排定的維護作業，以及系統復原的速度。
測試應用程式對容錯移轉的回應，容錯移轉隨時可能發生。 您可以使用 Google Cloud 控制台、gcloud CLI 或 API 手動啟動容錯移轉。請參閱「啟動容錯移轉」。
避免大型交易。 保持交易簡短。如需更新大型資料庫，請分批進行，不要一次完成。
如果您使用的是 Cloud SQL Auth Proxy，請確認您使用的是最新版本。 請參閱「將 Cloud SQL Auth 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 的記憶體，並為每 8 GB 的 RAM (大於 16 GB) 保留 1 GB 的記憶體。

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

  • 1.4 GB 記憶體，用於 OS 和代理程式
  • 4 GB 記憶體，因為 104 GB 大於 16 GB
  • 11 GB 記憶體：因為 88 GB RAM 大於 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，請仔細評估成效。

詳情請參閱 max degree of parallelism (MAXDOP)。

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。這項限制會降低應用程式角色的安全性。必須根據應用程式需求進行驗證。