この記事は、 O Paoguolai~ によるHuawei クラウド コミュニティ「GaussDB (DWS) パフォーマンス チューニング: テーブル スキャン中にフィルター処理された過剰な数の行によって引き起こされるパフォーマンス ボトルネック問題のケース スタディ」から共有されたものです。
1. 【問題の説明】
SQL ステートメントの実行中に、データ量 12 億の大きなテーブルがスキャンされ、データの 99% がフィルタリングされ、617 行のデータのみが残ります。パフォーマンスのボトルネックはテーブルのスキャンにあります。
2. 【原文】
set search_path = 'bi_dashboard';
WITH F_SRV_DB_DIM_PRD_D AS (SELECT EXTERNAL_NAME FROM ( SELECT MKT_NAME EXTERNAL_NAME
FROM BI_DASHBOARD.DM_MSS_ITEM_PRODUCT_D PRD
WHERE PRD.COMPANY_BRAND =any(array[string_to_array('HUAWEI',',')])
AND PRD .MKT_NAME =任意(array[string_to_array('Enjoy 60、Enjoy 50、Enjoy 60X、Enjoy 60 Pro、Enjoy 50 Pro、Enjoy 50z、Enjoy 10z、Enjoy 20e、Enjoy 20 Pro、Enjoy 10e、Enjoy 10 Plus、Enjoy 20 SE、Enjoy 10、 nova 11i、Enjoy 20 Plus、Enjoy 9 Plus、Enjoy 20 5G、nova Y90、Enjoy 10S、nova Y70、Enjoy Z、Enjoy 9S、nova 8 SE Active Edition、Maimang 9 5G、Y9s、Maimang 9 5G',',' )]) )
WHERE EXTERNAL_NAME<>'SNULL' GROUP BY EXTERNAL_NAME)、
V_PERIOD AS
(
SELECT PERIOD_ID AS PERIOD_ID_M,
LEAST(TO_CHAR(PERIOD_END_DATE, 'YYYYMMDD '), '20230630') AS PERIOD_ID,
PERIOD_ID AS DATES
FROM BI_D ASHBOARD.RPT_TML_ACCOUNT_PERIOD_D
WHERE PERIOD_TYPE = 'M'
AND PERIOD_ID BETWEEN 202207 AND 202306
)、
V_DATA_BASE AS
(
SELECT A.PERIOD_ID,
IFNULL(A.CHANNEL_ NAME, 'SNULL') AS DISTRIBUTOR_CHANNEL_NAME,
SUM(A.SO_QTY_MTD) AS SO_QTY,
SUM(DECODE(A. PERIOD_ID、20230630、A.SO_QTY_MTD)) AS SO_QTY_ORDER
select count(*) FROM DM_MSS_CN_PC_REP_RP_ST_D_F A
INNER JOIN F_SRV_DB_DIM_PRD_D PRD
ON A.EXTERNAL_NAME = PRD.EXTERNAL_NAME
WHERE 1 = 1
AND A.CHANNEL_ID IN ('100013388802')
および A.ORG_KEY IN (10000651)
AND A.SALES_FLAG IN ('1', '0')
AND A.PERIOD_ID IN (20220731,20221031,20220930,20220831,20221130, 20221231,20230131,20230228,20230430) 、20230331、20230531、20230630)
および (A .SO_QTY_MTD <> 0) -- 日付 SO_QTY が 0 であるすべてのデータをフィルターします
GROUP BY A.PERIOD_ID,
IFNULL(A.CHANNEL_NAME, 'SNULL' )
) ,
V_DATA AS
(
SELECT PERIOD_ID,
NVL(DISTRIBUTOR_CHANNEL_NAME, 'Total') AS DISTRIBUTOR_CHANNEL_NAME 、
SUM(SO_QTY) AS SO_QTY,
SUM(SO_QTY_ORDER) AS SO_QTY_ORDER
FROM V_DATA_BASE A
GROUP BY GROUPING SETS ((PERIOD_ID), (PERIOD_ID, DISTRI BUTOR_CHANNEL_NAME))
)
SELECT STRING_AGG(P.DATES, ',' ORDER BY P.PERIOD_ID_M) AS PERIOD_LIST,
B.DISTRIBUTOR_CHANNEL_NAME,
STRING_AGG(NVL(TO_CHAR(ROUND(A.SO_QTY)), '0'), ',' ORDER BY P.PERIOD_ID_M ) AS SO_QTY
FROM V_PERIOD P
FULL JOIN (SELECT DISTINCT DISTRIBUTOR_CHANNEL_NAME FROM V_DATA) B
ON 1 = 1
LEFT JOIN V_DATA A
ON A。PERIOD_ID = P.PERIOD_ID
および A.DISTRIBUTOR_CHANNEL_NAME = B.DISTRIBUTOR_CHANNEL_NAME
GROUP BY B.DISTRIBUTOR_CHANNEL_NAME
ORDER BY DECODE(B.DISTRIBUTOR_CHANNEL_NAME, 'Total', 0, 'SOURCE IS NULL', 2, '源空', 3, 'SNULL', 4, 1), SUM(A.SO_QTY_ORDER) DESC NULLS LAST
LIMIT
50オフセット0
3. 【性能分析】
上の図のパフォーマンス実行計画 (完全な実行計画は付録 1 にあります) からわかるように、SQL ステートメントはテーブル a (bi_dashboard.dm_mss_cn_pc_rep_rp_st_d_f_test) をスキャンする際に時間がかかります。スキャン中のフィルタ条件には、sales_flag、so_qty_mtd、channel_id、org_key、period_id が含まれます。テーブル上の元のローカル クラスタリング キー PCK には、period_id のみが含まれ、他の 3 つのフィルタ条件のいずれも含まれていません。したがって、PCK を調整して、スキャンテーブルの実行時間 a.
補足: ローカルクラスタリングキー
部分クラスター キー (PCK) は、最小/最大スパース インデックスを使用してベース テーブルの高速スキャンを実現する、列ストレージのインデックス テクノロジです。部分クラスター キーでは複数の列を指定できますが、通常は 2 列を超えることはお勧めできません。PCK は、大規模な列ストア テーブルに対するポイント クエリを高速化するのに適しています。また、view文のwhere条件にin値(12個)が多くありますが、DWSではin以降の条件はデフォルトで5個までしか指定できません。6個以上あるとフィルタリングが追い込まれません。このとき、 または を使用して12個の値の書き換えを組み合わせることができます。
A.PERIOD_ID IN (20220731,20221031,20220930,20220831,20221130) または A.PERIOD_ID IN (20221231,20230131,20230228,20230430,20230331) または A.PERIOD_ID IN (202) 30531,20230630)
現時点では、SQL ステートメントの実行時間は 487 ミリ秒に短縮されており、完全なパフォーマンス計画を付録 2 に示します。
- 添付ファイル:最適化後—パフォーマンス.txt 466.64KB
- 添付ファイル:最適化前—パフォーマンス.txt 449.47KB
クリックしてフォローし、できるだけ早くHuawei Cloudの新しいテクノロジーについて学びましょう~
Alibaba Cloudが深刻な障害に見舞われ、全製品が影響(復旧) Tumblr がロシアのオペレーティングシステムAurora OS 5.0 を冷却新しいUIが公開 Delphi 12とC++ Builder 12、RAD Studio 12多くのインターネット企業がHongmengプログラマーを緊急採用UNIX時間17 億時代に突入しようとしている (すでに突入している) Meituan が兵力を募集し、Hongmeng システム アプリの開発を計画Amazon が Linux 上の .NET 8 への Android の依存を取り除くために Linux ベースのオペレーティング システムを開発独立した規模はFFmpeg 6.1「Heaviside」がリリースされました