プロジェクトでは、書き込み SQLは主にクエリベースが、大量のデータは、それがハイライト表示されます、SQL パフォーマンスの最適化の重要性を。実際には、2000W未満のデータ量は、インデックスが考えることができるが、より2000Wよりも、ポイントテーブルのこれらのサブライブラリーを考慮する必要があります。本論文では、実際のプロジェクトで、クエリが非常に遅くする必要記録したSQL 最適化プロセスは、よりよい解決策がある場合は、以下の交換にメッセージを残してください。
多くの記事があります SQL の最適化方法は、ここでは記載しておりません。：ブログを表示する必要がある場合https://blog.csdn.net/linhaiyun_ytdx/article/details/79101122は、
SELECT T.YHBH、 （SELECT NAME FROM DIM_REGION WHERE CODE = SUBSTR（T.GDDWBM、0、4 ））GDDWMC、 （SELECT NAME FROM DIM_REGION WHERE CODE = FJMC T.GDDWBM） T.DFNY、 T.YHMC、 T.YDDZ、 （SELECT NAME FROM DIM_ELECTRICITY_TYPE CODE = YDLBMC T.YHLBDM） FROMは（SELECT DISTINCT T.YHBHを DECODE（T.GDDWBM、 NULL 、 ' 0000 ' 、 DECODE（T.GDDWBM、' 09 '、' 0000 '、T.GDDWBM））AS GDDWBM、 T.BBNY AS DFNY、 T.YHLBDM AS YHLBDM、 T.YHMC、 T2.YDDZ FROM V_TEMP_TABLE_JHCBHSTJ_HISTORY T、TMP_KH_YDKH T2 T.YHBH = T2.YHBH（+ ） AND NOT EXISTSは、（SELECT 1 FROM DJHJSL_LSB_FZ_HISTORY B B.BBNY = T.BBNY AND B.YHBH = T.YHBH AND B.GDDWBM = T.GDDWBM AND B.YHLBDM = T.YHLBDM と B.ZDCBZHS <> ' 0 ' ） ）T SUBSTR（T.GDDWBM、0、4）= ' 0946 ' AND T.DFNY = ' 201911 '
これは私のある SQLスクリプトを実行します。実際には、このスクリプトは複雑ではありません。どのV_TEMP_TABLE_JHCBHSTJ_HISTORY 、 DJHJSL_LSB_FZ_HISTORYは毎月に増加 330 百万円と、現在持っている1960年、百万を TMP_KH_YDKHのテーブルには、持っている 330 万人を。DIM_REGION と DIM_ELECTRICITY_TYPEは、二つのデータディクショナリエントリテーブルです。
インデックスがない場合には、このスクリプトを実行する必要がある 30代を、実装プロセスを参照して、今全表スキャンです。そして、最適化を開始。
1. 修正クエリスクリプトは、データの量を減らすために、外層内を照会します。
SELECT T.YHBH、 （SELECT NAME FROM DIM_REGION WHERE CODE = SUBSTR（T.GDDWBM、0、4 ））GDDWMC、 （SELECT NAME FROM DIM_REGION WHERE CODE = FJMC T.GDDWBM） T.DFNY、 T.YHMC、 T.YDDZ、 （SELECT NAME FROM DIM_ELECTRICITY_TYPE CODE = YDLBMC T.YHLBDM） FROMは（SELECT DISTINCT T.YHBHを DECODE（T.GDDWBM、 NULL 、 ' 0000 ' 、 DECODE（T.GDDWBM、' 09 '、' 0000 '、T.GDDWBM））AS GDDWBM、 T.BBNY AS DFNY、 T.YHLBDM AS YHLBDM、 T.YHMC、 T2.YDDZ FROM V_TEMP_TABLE_JHCBHSTJ_HISTORY T、TMP_KH_YDKH T2 T.YHBH = T2.YHBH（+ ） AND NOT EXISTSは、（SELECT 1 FROM DJHJSL_LSB_FZ_HISTORY B B.BBNY = T.BBNY AND B.YHBH = T.YHBH AND B.GDDWBM = T.GDDWBM AND B.YHLBDM = T.YHLBDM と B.ZDCBZHS <> ' 0 ' ） AND SUBSTR（T.GDDWBM、0、4）= ' 0946 ' AND T.BBNY = ' 201911 ' ）T
2. 3つのテーブルには、インデックスの上に構築されています
ため V_TEMP_TABLE_JHCBHSTJ_HISTORY 記載 DFNY 、 SUBSTR（T.GDDWBM、0、4）関節指数を構築します。
CREATE INDEX IDX_TMP_JHCBHSTJ_HISTORY_UNION ON V_TEMP_TABLE_JHCBHSTJ_HISTORY（BBNY、SUBSTR（GDDWBM、0、4））。
TMP_KH_YDKHのテーブル、関連付けを使用し、する必要がある yhbh インデックスを構築します
作成し たインデックス IDX_YHBH_KH 上 TMP_KH_YDKH（YHBHを）。
DJHJSL_LSB_FZ_HISTORY 表に EXISTSない内側、それは今、彼をしようとする共同のインデックスを設定し、テーブルスキャン全表になります。
CREATE INDEX IDX_DJHJSL_FZ_HISTORY_UNION ON V_TEMP_TABLE_JHCBHSTJ_HISTORY（BBNY、YHBH、GDDWBM、YHLBDM）を、
共同インデックスを確立するため、およびインデックステーブルを手放すか、全表スキャンでは、なかったが表示オラクルの実施計画問い合わせがに上げてきたナインアップ。
これらの四つのフィールドの隣には、インデックス化されています。
作成し たインデックス IDX_DJHJSL_FZ_HISTORY_BBNY 上DJHJSL_LSB_FZ_HISTORY（BBNYを）。 作成し たインデックス IDX_DJHJSL_FZ_HISTORY_YHBH 上DJHJSL_LSB_FZ_HISTORY（YHBHを）。 作成し たインデックス IDX_DJHJSL_FZ_HISTORY_GDDWBM 上DJHJSL_LSB_FZ_HISTORY（GDDWBMを）。 作成し たインデックス IDX_DJHJSL_FZ_HISTORY_YHLBDM 上 DJHJSL_LSB_FZ_HISTORY（YHLBDMを）。
観点から、実行計画は、Oracleが唯一行く IDX_DJHJSL_FZ_HISTORY_BBNYをインデックスが今最も速いいる 1.95s アップ。
それは、クエリ満たしているものの 3秒で要件を、しかし、考慮に入れた後、月次データの増加、データの量がある5000 億回または非常に遅くなりますと万人が、データのような大規模な量。
実際には、私の正式な環境試験時間、NOT このテーブル内に存在する、単一のインデックスの設立は役に立たない、共同インデックスの設立は、おそらく別のコンピュータのCPUやその他の要因のため、移動するには、このインデックステーブルを作成します。
上記の最適化は、当然のことながら、プロジェクト、ビジネス最適化の次の組み合わせのニーズを満たすことができません。監視システムとして、データは、 T + 1 、リアルタイム追跡を必要とせず、これらのデータが使用されたETL 日当たり抽出ツールタイミング抽出。そして、毎月300 データ百万円、わずか数千のユーザーのみバーを懸念。事業の組み合わせだから、我々は使用ETLをので、別のテーブルに関係するデータユーザINSERT、データを抽出した後、そのデータの月額わずか数千なので、上の数十データの数千人の前に、今年のOracle へ彼は、決定が圧力ゼロだったと述べました。
あなたが最適化するために、他の方法を持っている場合は、下記のメッセージ交換を残してください。