Amazon Redshift Advisor 建議 - Amazon Redshift

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

Amazon Redshift Advisor 建議

Amazon Redshift Advisor 提供有關如何最佳化 Amazon Redshift 叢集以提高效能並節省營運成本的建議。如前所述,您可以在主控台找到各項建議的解釋。您可以在以下章節中找到這些建議的進一步詳細資訊。

壓縮以 COPY 載入的 Amazon S3 檔案物件

COPY 命令利用 Amazon Redshift 中的大規模 parallel 處理 (MPP) 架構,以 parallel 讀取與載入資料。它可從 Amazon S3、DynamoDB 資料表讀取檔案,以及從一或多個遠端主機讀取文字輸出。

載入大量資料時,強烈建議您使用 COPY 命令從 S3 載入已壓縮的資料檔案。壓縮大型資料集可節省上傳檔案至 S3 的時間。COPY 亦可在讀取檔案時解壓縮檔案,以加速載入程序。

分析

載入大型未壓縮資料集的長時間執行 COPY 命令,通常有機會大幅提升效能。Advisor 分析可識別載入大型未壓縮資料集的 COPY 命令。在此情況下,Advisor 會產生在 S3 中的來源檔案實作壓縮的建議。

建議

確定載入大量資料或長時間執行的每個 COPY 皆從 S3 擷取已壓縮的資料物件。您可以用超級使用者的身分執行以下 SQL 命令,識別從 S3 載入大型未壓縮資料集的 COPY。

SELECT wq.userid, query, exec_start_time AS starttime, COUNT(*) num_files, ROUND(MAX(wq.total_exec_time/1000000.0),2) execution_secs, ROUND(SUM(transfer_size)/(1024.0*1024.0),2) total_mb, SUBSTRING(querytxt,1,60) copy_sql FROM stl_s3client s JOIN stl_query q USING (query) JOIN stl_wlm_query wq USING (query) WHERE s.userid>1 AND http_method = 'GET' AND POSITION('COPY ANALYZE' IN querytxt) = 0 AND aborted = 0 AND final_state='Completed' GROUP BY 1, 2, 3, 7 HAVING SUM(transfer_size) = SUM(data_size) AND SUM(transfer_size)/(1024*1024) >= 5 ORDER BY 6 DESC, 5 DESC;

如果在您載入資料之後,暫存資料仍留存在 S3 (資料湖經常出現此情況),以壓縮形式儲存此資料可降低您的儲存空間成本。

實作提示

  • 壓縮之後的理想物件大小為 1—128 MB。

  • 您可以用 gzip、lzop 或 bzip2 格式壓縮檔案。

隔離多個作用中資料庫

作為最佳實務,建議您隔離 Amazon Redshift 中的各個資料庫。查詢執行於特定資料庫,而且無法存取叢集上其他資料庫的資料。但是,您在叢集上所有資料庫執行的查詢,將共用相同的底層叢集儲存空間與運算資源。當單一叢集包含多個使用中資料庫時,其工作負載通常是不相關的。

分析

Advisor 分析會檢閱叢集上的所有資料庫,以找出同時執行的使用中工作負載。如果有同時運行的活動工作負載,Advisor 會提供建議,建議您考慮將資料庫遷移至獨立的 Amazon Redshift 叢集。

建議

考慮將經常被查詢的資料庫移至個別的專屬叢集。使用個別的叢集可減少資源爭奪並提升查詢效能。這是因為它能讓您設定各個叢集的儲存空間大小、成本,以及各個工作負載所需的效能。同時,不相關的工作負載通常會受益於不同的工作負載管理組態。

若要找出最常用的資料庫,請以超級使用者身分執行此 SQL 命令。

SELECT database, COUNT(*) as num_queries, AVG(DATEDIFF(sec,starttime,endtime)) avg_duration, MIN(starttime) as oldest_ts, MAX(endtime) as latest_ts FROM stl_query WHERE userid > 1 GROUP BY database;

實作提示

  • 因為使用者必須特別連接至各個資料庫,而查詢只能存取單一資料庫,因此將資料庫移至個別叢集對使用者的影響很小。

  • 移動資料庫的選項之一是執行以下步驟:

    1. 暫時將目前叢集的快照還原至相同大小的叢集。

    2. 從新的叢集刪除所有資料庫,要移動的目標資料庫除外。

    3. 調整叢集大小以符合適當的節點類型,並計算資料庫的工作負載。

重新配置工作負載管理 (WLM) 記憶體

Amazon Redshift 將使用者查詢路由到實作手動 WLM以進行處理。工作負載管理 (WLM) 可定義將查詢路由至隊列的方式。Amazon Redshift 會為每個隊列配置叢集的一部分可用的記憶體。佇列的記憶體再分配給佇列的查詢槽。

當佇列設定的插槽多於工作負載的需要時,配置到這些未使用插槽的記憶體將無法充分利用。減少設定的插槽以符合尖峰工作負載需求,可將未使用的記憶體重新分配給使用中的插槽,並藉此提升查詢效能。

分析

Advisor 分析將檢閱工作負載並行需求,以識別具有未使用插槽的查詢佇列。Advisor 發現以下情形時將會產生建議,建議您降低佇列中的插槽數量:

  • 在整個分析過程中有完全未使用之插槽的佇列

  • 擁有四個以上插槽,而且在整個分析過程中至少有兩個未使用插槽的佇列

建議

減少設定的插槽以符合尖峰工作負載需求,可將未使用的記憶體重新分配給使用中的插槽。針對其插槽不曾完全充分利用的佇列,考慮減少其設定的插槽數量。若要找出這些佇列,您可以用超級使用者的身分執行以下 SQL 命令,比較各個佇列的每小時尖峰插槽需求。

WITH generate_dt_series AS (select sysdate - (n * interval '5 second') as dt from (select row_number() over () as n from stl_scan limit 17280)), apex AS ( SELECT iq.dt, iq.service_class, iq.num_query_tasks, count(iq.slot_count) as service_class_queries, sum(iq.slot_count) as service_class_slots FROM (select gds.dt, wq.service_class, wscc.num_query_tasks, wq.slot_count FROM stl_wlm_query wq JOIN stv_wlm_service_class_config wscc ON (wscc.service_class = wq.service_class AND wscc.service_class > 5) JOIN generate_dt_series gds ON (wq.service_class_start_time <= gds.dt AND wq.service_class_end_time > gds.dt) WHERE wq.userid > 1 AND wq.service_class > 5) iq GROUP BY iq.dt, iq.service_class, iq.num_query_tasks), maxes as (SELECT apex.service_class, trunc(apex.dt) as d, date_part(h,apex.dt) as dt_h, max(service_class_slots) max_service_class_slots from apex group by apex.service_class, apex.dt, date_part(h,apex.dt)) SELECT apex.service_class - 5 AS queue, apex.service_class, apex.num_query_tasks AS max_wlm_concurrency, maxes.d AS day, maxes.dt_h || ':00 - ' || maxes.dt_h || ':59' as hour, MAX(apex.service_class_slots) as max_service_class_slots FROM apex JOIN maxes ON (apex.service_class = maxes.service_class AND apex.service_class_slots = maxes.max_service_class_slots) GROUP BY apex.service_class, apex.num_query_tasks, maxes.d, maxes.dt_h ORDER BY apex.service_class, maxes.d, maxes.dt_h;

max_service_class_slots 欄位表示該小時查詢佇列中 WLM 查詢插槽的最大數量。如果存在未利用的排列,請以修改參數資料組,如內所述Amazon Redshift 叢集管理指南。

實作提示

  • 如果您的工作負載量變化很大,請確定分析有擷取到尖峰使用期間。如果變化不大,請重複執行先前的 SQL 以監控尖峰並行需求。

  • 如需有關從先前的 SQL 程式碼解讀查詢結果的詳細資訊,請參閱 GitHub 上的 wlm_apex_hourly.sql script

在 COPY 期間跳過壓縮分析

當您以 COPY 命令聲明的壓縮編碼,將資料載入空的資料表時,Amazon Redshift 會應用儲存空間壓縮。此最佳化可確保叢集中的資料有效地儲存,即使是由最終使用者載入。需要套用壓縮的分析可能需要很長的時間。

分析

Advisor 分析會檢查因自動壓縮分析而延遲的 COPY 操作。此分析會在資料載入時取樣資料以判斷壓縮編碼。此取樣類似 ANALYZE COMPRESSION 命令所執行的取樣。

當您在結構化程序中載入資料時,例如隔夜擷取、轉換、載入 (ETL) 批次,您可以預先定義壓縮。您也可以最佳化您的資料表定義,以永久跳過此階段,而不產生任何負面影響。

建議

為藉由跳過壓縮分析階段以提升 COPY 反應速度,請實作以下兩個選項之一:

  • 當您建立使用 COPY 命令載入的資料表時,請使用欄位 ENCODE 參數。

  • 通過提供COMPUPDATE OFF參數。

最佳解決方案通常是在資料表建立期間使用欄位編碼,因為此方法也同時保有將壓縮資料儲存於磁碟的好處。您可以使用 ANALYZE COMPRESSION 命令以建議壓縮編碼,但您必須重建資料表以套用這些編碼。若要自動執行此程序,您可以使用AWSColumnEncodingUtility,在 GitHub 找到它。

若要識別最近觸發自動壓縮分析的 COPY 操作,請執行以下 SQL 命令。

WITH xids AS ( SELECT xid FROM stl_query WHERE userid>1 AND aborted=0 AND querytxt = 'analyze compression phase 1' GROUP BY xid INTERSECT SELECT xid FROM stl_commit_stats WHERE node=-1) SELECT a.userid, a.query, a.xid, a.starttime, b.complyze_sec, a.copy_sec, a.copy_sql FROM (SELECT q.userid, q.query, q.xid, date_trunc('s',q.starttime) starttime, substring(querytxt,1,100) as copy_sql, ROUND(datediff(ms,starttime,endtime)::numeric / 1000.0, 2) copy_sec FROM stl_query q JOIN xids USING (xid) WHERE (querytxt ilike 'copy %from%' OR querytxt ilike '% copy %from%') AND querytxt not like 'COPY ANALYZE %') a LEFT JOIN (SELECT xid, ROUND(sum(datediff(ms,starttime,endtime))::numeric / 1000.0,2) complyze_sec FROM stl_query q JOIN xids USING (xid) WHERE (querytxt like 'COPY ANALYZE %' OR querytxt like 'analyze compression phase %') GROUP BY xid ) b ON a.xid = b.xid WHERE b.complyze_sec IS NOT NULL ORDER BY a.copy_sql, a.starttime;

實作提示

  • 請確定在您 ETL 程序中建立的所有大容量資料表 (例如,臨時資料表與暫存資料表) 宣告所有欄位的壓縮編碼 (第一個排序索引鍵除外)。

  • 估算前述 SQL 命令識別之各個 COPY 命令所載入資料表的預期生命週期大小。如果您有信心資料表將保持極小,請以COMPUPDATE OFF參數。否則,請在以 COPY 命令載入資料之前,以明確的壓縮建立資料表。

分割以 COPY 載入的 Amazon S3 資料件

COPY 命令利用 Amazon Redshift 中的大規模 parallel 處理 (MPP) 架構,從 Amazon S3 上的檔案讀取與載入資料。COPY 命令從多個檔案平行載入資料,並將工作負載分散至您叢集中的各個節點。若要達到最佳傳輸量,強烈建議您將資料分割為多個檔案來善加利用平行處理。

分析

Advisor 分析可識別載入包含於暫存在 S3 少量檔案中的大型資料集的 COPY 命令。從少量檔案載入大型資料集的長時間執行 COPY 命令,通常有機會大幅提升效能。當 Advisor 發現這些 COPY 命令花費大量時間,將會建立建議,藉由將資料分割至 S3 中的其他檔案以增加平行處理。

建議

在此情況下,建議採取以下依照優先順序排序的動作:

  1. 最佳化載入檔案數量少於叢集節點數量的 COPY 命令。

  2. 最佳化載入檔案數量少於叢集分割數量的 COPY 命令。

  3. 最佳化檔案數量不是叢集分割數量倍數的 COPY 命令。

某些 COPY 命令會載入大量資料或長時間執行。對於這些命令,建議您從 S3 載入資料物件的數量等於叢集中分割數量的倍數。若要識別每個 COPY 命令已載入多少個 S3 物件,請以超級使用者身分執行以下 SQL 程式碼。

SELECT query, COUNT(*) num_files, ROUND(MAX(wq.total_exec_time/1000000.0),2) execution_secs, ROUND(SUM(transfer_size)/(1024.0*1024.0),2) total_mb, SUBSTRING(querytxt,1,60) copy_sql FROM stl_s3client s JOIN stl_query q USING (query) JOIN stl_wlm_query wq USING (query) WHERE s.userid>1 AND http_method = 'GET' AND POSITION('COPY ANALYZE' IN querytxt) = 0 AND aborted = 0 AND final_state='Completed' GROUP BY query, querytxt HAVING (SUM(transfer_size)/(1024*1024))/COUNT(*) >= 2 ORDER BY CASE WHEN COUNT(*) < (SELECT max(node)+1 FROM stv_slices) THEN 1 WHEN COUNT(*) < (SELECT COUNT(*) FROM stv_slices WHERE node=0) THEN 2 ELSE 2+((COUNT(*) % (SELECT COUNT(*) FROM stv_slices))/(SELECT COUNT(*)::DECIMAL FROM stv_slices)) END, (SUM(transfer_size)/(1024.0*1024.0))/COUNT(*) DESC;

實作提示

  • 節點中的分割數目取決於叢集的節點大小。如需各種節點類型中的切片數量的詳細資訊,請參Amazon Redshift 中的集羣和節點中的Amazon Redshift 叢集管理指南。

  • 您可以透過為集合指定通用字首或字首索引鍵,或在資訊清單檔案中明確列出檔案來載入多個檔案。如需有關載入檔案的詳細資訊,請參閱 從壓縮和未壓縮文件加載數據

  • 在分割工作負載時,Amazon Redshift 不會考量檔案大小。分割您的載入資料,使檔案皆有相同的大小,在壓縮之後介於 1 MB 至 1 GB。

更新資料表統計資訊

Amazon Redshift 使用成本型查詢最佳化工具來為查詢選擇最佳執行計畫。成本估算是根據使用 ANALYZE 命令產生的資料表統計資訊。當統計資訊已過時或遺失時,資料庫可能會選擇效率較低的查詢執行計畫,特別是複雜的查詢。維護最新統計資訊有助於複雜的查詢以可能的最短時間執行。

分析

Advisor 分析會追蹤統計資訊 out-of-date 或遺失. 它會檢閱與複雜查詢相關聯的資料表存取中繼資料。如果經常以複雜模式存取的資料表遺失統計資訊,Advisor 會建立重大建議以執行 ANALYZE。如果經常以複雜模式存取的資料表具有 out-of-date 統計數據時,顧問會創建建議建議運行分析。

建議

無論何時,當資料表內容有大幅變更時,請以 ANALYZE 更新統計資訊。當有大量新資料列以 COPY 或 INSERT 命令載入至現有資料表時,我們建議執行 ANALYZE。當有大量資料列以 UPDATE 或 DELETE 命令進行修改時,我們也建議執行 ANALYZE。若要找出遺失或 out-of-date 統計資訊,請以超級使用者身分執行以下 SQL 命令。其結果將從最大到最小的資料表進行排序。

若要找出遺失或 out-of-date 統計資訊,請以超級使用者身分執行以下 SQL 命令。其結果將從最大到最小的資料表進行排序。

SELECT ti.schema||'.'||ti."table" tablename, ti.size table_size_mb, ti.stats_off statistics_accuracy FROM svv_table_info ti WHERE ti.stats_off > 5.00 ORDER BY ti.size DESC;

實作提示

預設 ANALYZE 閾值為 10%。此預設值表示特定資料表自上一次 ANALYZE 後,如果變更的列數少於 10%,則 ANALYZE 命令會略過此資料表。因此,您可以選擇在每個 ETL 程序結尾時發出 ANALYZE 命令。採取此方法意味著通常會跳過 ANALYZE,但也能確保 ANALYZE 會在需要時執行。

ANALYZE 統計資訊對於聯結中使用的欄位 (例如,JOIN tbl_a ON col_b) 或做為述詞的欄位 (例如,WHERE col_b = 'xyz') 最有影響。根據預設,ANALYZE 會收集指定資料表中所有欄位的統計資訊。如有需要,您可以針對 ANALYZE 最有影響的欄位來執行 ANALYZE,以減少需要執行 ANALYZE 的時間。您可執行下列 SQL 命令來識別做為述詞使用的欄位。您也可以讓 Amazon Redshift 選擇要分析哪些欄,方法是指定ANALYZE PREDICATE COLUMNS

WITH predicate_column_info as ( SELECT ns.nspname AS schema_name, c.relname AS table_name, a.attnum as col_num, a.attname as col_name, CASE WHEN 10002 = s.stakind1 THEN array_to_string(stavalues1, '||') WHEN 10002 = s.stakind2 THEN array_to_string(stavalues2, '||') WHEN 10002 = s.stakind3 THEN array_to_string(stavalues3, '||') WHEN 10002 = s.stakind4 THEN array_to_string(stavalues4, '||') ELSE NULL::varchar END AS pred_ts FROM pg_statistic s JOIN pg_class c ON c.oid = s.starelid JOIN pg_namespace ns ON c.relnamespace = ns.oid JOIN pg_attribute a ON c.oid = a.attrelid AND a.attnum = s.staattnum) SELECT schema_name, table_name, col_num, col_name, pred_ts NOT LIKE '2000-01-01%' AS is_predicate, CASE WHEN pred_ts NOT LIKE '2000-01-01%' THEN (split_part(pred_ts, '||',1))::timestamp ELSE NULL::timestamp END as first_predicate_use, CASE WHEN pred_ts NOT LIKE '%||2000-01-01%' THEN (split_part(pred_ts, '||',2))::timestamp ELSE NULL::timestamp END as last_analyze FROM predicate_column_info;

如需詳細資訊,請參閱 分析資料表

啟用短期查詢加速

短期查詢加速 (SQA) 可排定讓短期執行的查詢優先於長期執行的查詢。SQA 會在專用空間中執行短期查詢,所以 SQA 查詢不會被迫在佇列中排在長期查詢後面等待。SQA 只優先處理短期執行且位於使用者定義佇列中的查詢。SQA 可讓短期執行的查詢更快開始執行,使用者會更快看到結果。

如果啟用 SQA,您可以減少或去除短期查詢執行專用的工作負載管理 (WLM) 佇列。此外,長期執行的查詢不需要與短期查詢爭奪佇列中的槽,因此,您可以將 WLM 佇列設定為使用較少的查詢槽。使用較低的並行性時,就大部分工作負載而言,查詢傳輸量會增加,且整體系統效能會改善。如需詳細資訊,請參閱 使用短期查詢加速

分析

Advisor 會檢查工作負載模式,並報告 SQA 可減少延遲的最近查詢數目,以及符合 SQA 資格的查詢的每日佇列時間。

建議

修改 WLM 資料表以啟用 SQA。Amazon Redshift 採用機器學習演算法來分析每一個合格查詢。隨著 SQA 從查詢模式中學習,預測會越準確。如需詳細資訊,請參閱設定工作負載管理

啟用 SQA 時,根據預設,WLM 會將短期查詢的最長執行時間設為動態。建議維持 SQA 最長執行時間的動態設定。

實作提示

若要檢查是否已啟用 SQA,請執行下列查詢。如果查詢傳回一列,表示 SQA 已啟用。

select * from stv_wlm_service_class_config where service_class = 14;

如需詳細資訊,請參閱 監控 SQA

更改資料表上的分佈索引鍵

Amazon Redshift 會根據資料表分佈樣式將資料表列分佈至整個叢集。含有 KEY 分佈的資料表需要將一個資料欄做為分佈索引鍵 (DISTKEY),而系統會根據 DISTKEY 資料欄值來指派資料表列給叢集的節點分割。

適當的 DISTKEY 會在每個節點分割上放置差不多數量的資料列,且聯結條件經常會參考該資料欄。當系統在 DISTKEY 資料欄上聯結資料表時,就會產生經過最佳化的聯結,以加速查詢效能。

分析

Advisor 會分析叢集的工作負載以找出最適合資料表的分佈索引鍵,其可從 KEY 分佈樣式獲得諸多優勢。

建議

Advisor 所提供的 ALTER TABLE 陳述式可根據分析結果來更改資料表的 DISTSTYLE 和 DISTKEY。請確保在建議群組內實作所有 SQL 陳述式,以發揮顯著的效能優勢。

使用 ALTER TABLE 重新分佈大型資料表會耗用叢集資源,且會不定時鎖定暫時資料表。因此,請在其他叢集工作負載較輕時實作每個建議群組。如需最佳化表格分佈屬性的詳細資訊,請參Amazon Redshift 工程公司的高級桌面設計行動手冊:分配方式和分發鍵

如需 ALTER DISTSYLE 和 DISTKEY 的詳細資訊,請參閱 ALTER TABLE

注意

如果沒有看到建議,並不一定表示目前的發佈樣式是最合適的。如果沒有足夠的資料或重新分配的預期益處很小,Advisor 不會提供建議。

Advisor 建議適用於特定資料表,且不一定適用於含相同資料欄名稱的資料表。欄位名稱相同的資料表,其各欄特性仍可能不同,除非資料表中的資料也相同。

如果您看到由 ETL 任務建立或刪除的暫存資料表建議,則需修改 ETL 程序以使用 Advisor 建議的分佈索引鍵。

變更資料表上的排序索引鍵

Amazon Redshift 會根據表格對表格列進行排序排序索引鍵。表格列會根據排序鍵欄值進行排序。

透過適當的排序索引鍵排序表格可以加速查詢效能,特別是有範圍限制述詞的查詢,因為需要從磁碟讀取的表格區塊較少。

分析

Advisor 會分析您叢集在幾天的工作負載,為您的資料表找出有益的排序索引鍵。

建議

Advisor 會提供兩組 ALTER TABLE 陳述式,此陳述式會根據分析來變更排序索引鍵:

  • 改變當前沒有排序鍵以添加複合排序鍵的表的語句。

  • 將排序鍵從交錯更改為複合鍵或無排序鍵的語句。

    使用複合排序索引鍵大幅降低維護額外負荷。使用複合排序索引鍵的資料表不需要交錯排序所需的高成本 VACUUM REINDEX 操作。實際上,對於絕大多數 Amazon Redshift 工作負載,複合排序索引鍵比交錯排序索引鍵更有效果。但是,如果表很小,則不使用排序鍵來避免排序鍵存儲開銷會更有效。

使用 ALTER TABLE 排序大型表格時會消耗叢集資源,您需要在各種不同時間鎖定表格。當叢集的工作負載不高時,請實作每個建議。如需最佳化表格排序索引鍵配置的詳細資訊,請參Amazon Redshift 工程公司的高級桌面設計行動手冊:複合排序索引鍵和交錯的排序索引鍵

如需 ALTER SORTKEY 的詳細資訊,請參閱ALTER TABLE

注意

如果您沒有看到表格的建議,這並不一定表示當前配置是最好的。當沒有足夠的資料或排序的預期益處不大時,Advisor 不會提供建議。

Advisor 建議適用於特定表格,且不一定適用於含有相同名稱和資料類型的表格。根據表格中的資料和工作負載,共用欄名稱的表格可能會有不同的建議。

更改列上的壓縮編碼

壓縮是欄層級操作,可降低資料存放時的大小。Amazon Redshift 中使用壓縮來節省存儲空間並通過減少磁盤 I/O 量來提高查詢性能。我們建議根據每列的數據類型和查詢模式對其進行最佳壓縮編碼。通過優化壓縮,查詢可以更高效地運行,並且數據庫佔用最小的存儲空間。

分析

Advisor 不斷分析集羣的工作負載和數據庫模式,以確定每個表列的最佳壓縮編碼。

建議

Advisor 會提供 ALTER TABLE 陳述式,此陳述式會根據分析來變更壓縮編碼。

更改列壓縮編碼ALTER TABLE會消耗叢集資源,並在不定時鎖定資源。因此,最好在叢集工作負載較輕時實作建議。

作為參考,ALTER TABLE 範例會顯示若幹更改資料欄編碼的語句。

注意

當沒有足夠的資料或更改編碼的預期益處不大時,Advisor 不會提供建議。

資料類型建議

Amazon Redshift 有一個 SQL 數據類型庫,用於各種使用案例。這些包括整數類型,如INT和類型來存儲字符,如VARCHAR。Redshift 以優化的方式存儲類型,以提供快速訪問和良好的查詢性能。此外,Redshift 還為特定類型提供函數,您可以使用這些函數對查詢結果進行格式化或執行計算。

分析

Advisor 不斷分析集羣的工作負載和數據庫模式,以確定可從數據類型更改中顯著受益的列。

建議

Advisor 提供ALTER TABLE語句,該語句添加了一個帶有建議數據類型的新列。一個伴隨UPDATE語句將數據從現有列複製到新列中。創建新列並加載數據後,請更改查詢和引入腳本以訪問新列。然後利用專門針對新數據類型的特性和功能,SQL 函數參考

將現有數據複製到新列可能需要一些時間。我們建議您在羣集的工作負載較輕時實施每個顧問建議。請參考可用數據類型列表,請訪問資料類型

請注意,當沒有足夠的資料或更改資料類型的預期益處不大時,Advisor 不會提供建議。