• 検索結果がありません。

⇒ UNION ALL 句

4. 同一項目の二重管理

親表 子表

要約項目

表A

項目1

表B

項目

1

明細表 サマリ表

伝票番号 年月 地域 商品 売上額

年月 地域 商品

合計売上額

明細表

合計売上額 伝票番号 商品 単価 数量

性能観点から対策を検討する

要約化による性能最適化

受注番号 商品番号 発注数

1 1 1

2 1 3

2 2 1

3 3 2

4 2 1

受注番号 受注日

1 2/3

2 2/4

3 2/4

4 2/5

SELECT文による集計結果を格納

受注項目表 受注表

受注番号 受注日 総発注数

1 2/3 1

2 2/4 4

3 2/4 2

4 2/5 1

•受注番号ごとの発注数を要約した要約表の追加

要約表

要約化

<Insert Picture Here>

データベースの機能を使用した対処案

クラスタ表による冗長化

マテリアライズドビューによる要約化

複数の表を1つの領域

(

セグメント

)

に格納し、同じデータブロックを共有する 表のグループみたいなもの

 クラスタ表のメリット

論理的な関係を変更することなく物理的に同じ場所(同じブロック)に格納できる

クラスタキー(親表のプライマリキー)

親表のデータ データブロック

別々にアクセスされることの多い表にはクラスタ表を使用しない!

クラスタ表による冗長化

クラスタ表とは

クラスタキーに属する 子表のデータ

クラスタ表による冗長化

クラスタ表の構造

受注番号 商品番号 発注数

1 1 1

2 1 3

2 2 1

3 3 2

4 2 1

受注番号 受注日

1 2/3

2 2/4

3 2/4

4 2/5

+

非クラスタ化表

クラスタ化表(クラスタ化キー受注番号)

受注番号 受注日

1 2/3

受注番号 受注日

2 2/4

受注番号 受注日

3 2/4

受注番号 受注日

4 2/5

関連データを まとめて格納できるため

効率がよい 関連データを

別々に格納するため 必要領域も増大

商品番号 発注数

1 1

商品番号 発注数

1 3

2 1

商品番号 発注数

3 2

商品番号 発注数

2 1

受注番号 商品番号 発注数

1 1 1

2 1 3

2 2 1

3 3 2

4 2 1

受注番号 受注日

1 2/3

2 2/4

3 2/4

4 2/5

SELECT文による集計結果を格納

SELECT a.受注番号, b.

受注日

,

SUM(a.

発注数

)

総発注数

FROM

受注項目表

a,受注表 b WHERE a.

受注番号

=b.

受注番号 受注項目表 受注表

受注番号 受注日 総発注数

1 2/3 1

2 2/4 4

3 2/4 2

4 2/5 1

受注番号ごとの発注数を要約した要約表の追加

要約表

マテリアライズドビューによる要約化

要約表の追加例

• リモート・データベース上に存在するデータをローカル・データベース上 に定期的にコピーするもの(スナップショット)

• データの集計や結合処理の結果を実体として持たせるもの

• 結合処理など、複雑な検索処理のパフォーマンス向上のために用いら れる

リモートコピー 結合 集計(要約)

sum count

sum count

マテリアライズドビュー マテリアライズドビュー マテリアライズドビュー

マテリアライズドビューによる要約化

マテリアライズドビューの構造

<Insert Picture Here>

まとめ

【解決編

Part1~2】

• SQL単体の最適化

定型的な

SQL

チューニング

非定型的なSQLチューニング

SQL パフォーマンス問題解決へのアプローチ

本日の範囲

オプティマイザへの インプット情報は妥当か?

自身で実行計画を検討 オプティマイザが生成した

実行計画は適切か?

インプット情報を修正できるか?

NO YES

YES NO

NO NO YES

YES

チューニング完了 NO

パフォーマンスは妥当か?

SQL単体以外のチューニング

アプリケーション チューニング

SQL単体

システム全体

Part3

~】

システム全体の最適化

• SQL単体を最適化しても発生する(解

決しない)パフォーマンス問題がある

設計 チューニング 多重処理

チューニング

• SQL 単体では問題ないが性能がでないケース・・・

① 設計時に考慮が足りないことがある

② システム開発の前フェーズでスルーされてしまうことがある

③ 運用中に問題が発覚して策がないことがある

データ主観の設計(正規化と統合化)

/ 業務を最適化する設計 / 性能を最適化する設計

について考慮された設計が行われている必要がある。

設計の知識と性能への関連性について(①)開発者が知識を持つことで、設計の不備を

SQL観点から逆引きで指摘し改善することができる。

運用時に問題が発生した場合、どのような点に着目して設計を確認すべきかが整理できて いる。1つの案として、データベースの機能を使用した解決案も提示できること。

設計時の不備を SQL の観点から改善できるようになる

SQL パフォーマンス問題解決へのアプローチ

まとめ

<Insert Picture Here>

関連したドキュメント