今日SQLが高いシステム負荷を占めるがあり、IO負荷が30％を占めます。ユーザーのログイン機能の後、未読メッセージの数を表示することです。このSQLをチェックするシステムのポイントとしての機能限り以来。
午前中に結果として4時間は100 000回呼び出します。
SELECTをCOUNT（1）
WORKBENCH_MES Tlの、T2 WORKBENCH_MES_REL FROM
WHERE T1.MES_ID = T2.MES_ID
AND T2.RECIPIENT_ID = '83DB7DD7505B4C90831717AB18881C69'
AND T2.IS_READ = 'N'
AND T1.SEND_DATE> TO_DATE（ '2017年8月4日を' = 'YYYY-MM-DD'）
AND T1.SEND_DATE <TO_DATE（ '2018年2月4日'、 'YYYY-MM-DD'）+ 1。
ちょうど昨日、このSQLの実行計画が変更されました。消費する前に、実装は多くの場合、問題は大きくないもののので、フル・テーブル・インデックスになるための計画の実施は、後に来ました。
-------------------------------------------------- -------------------------------------------------- ---------------
| 同上| 操作| 名前| 行| バイト| コスト（％のCPU）| 時間|
-------------------------------------------------- -------------------------------------------------- ---------------
| 0 | SELECTステートメント| | | | 258（100）| |
| 1 | SORT AGGREGATE | | 1 | 113 | | |
| * 2 | FILTER | | | | | |
| 3 | ネストされたループ| | 100 | 11300 | 258（0）| 0時00分04秒|
| 4 | ネストされたループ| | 100 | 11300 | 258（0）| 0時00分04秒|
| * 5 | INDEXのROWID BY表アクセス| WORKBENCH_MES_REL | 100 | 6800 | 58（0）| 午後十二時00分01秒|
| * 6 | INDEX RANGE SCAN | IND_WMR_RECIPIENT_ID_0905 | 128 | | 4（0）| 午後十二時00分01秒|
| * 7 | INDEX UNIQUE SCAN | PK_WORKBENCH_MES10 | 1 | | 1（0）| 午後十二時00分01秒|
| * 8 | GLOBAL INDEX ROWID BY表アクセス| WORKBENCH_MES | 1 | 45 | 2（0）| 午後十二時00分01秒|
-------------------------------------------------- -------------------------------------------------- ---------------
-------------------------------------------------- -------------------------------------------------- ---------
| 同上| 操作| 名前| 行| バイト| TempSpc | コスト（％のCPU）| 時間|
-------------------------------------------------- -------------------------------------------------- ---------
| 0 | SELECTステートメント| | | | | 161K（100）| |
| 1 | SORT AGGREGATE | | 1 | 113 | | | |
| * 2 | FILTER | | | | | | |
| * 3 | HASH JOINを| | 122K | 13M | 9544K | 161K（1）| 〇時32分17秒|
| * 4 | TABLE ACCESS FULL | WORKBENCH_MES_REL | 122K | 8111K | | 46750（1）| 0時09分21秒|
| 5 | PARTITION RANGEのイテレータ| | 2614K | 112M | | 107K（1）| 午前0時21分25秒|
| * 6 | TABLE ACCESS FULL | WORKBENCH_MES | 2614K | 112M | | 107K（1）| 午前0時21分25秒|
-------------------------------------------------- -------------------------------------------------- ---------
診断を開始します。
第一印象が失われていない二つのテーブルのインデックスは1です。RECIPIENT_ID選択性が良いので。テーブルをチェックし、インデックスがあります。
（1）WORKBENCH_MES_REL recipient_id = WHERE '83DB7DD7505B4C90831717AB18881C69'から2.SelectをCOUNT
WORKBENCH_MES_REL recipient_id = WHERE '83DB7DD7505B4C90831717AB18881C69'とIS_READ = 'N'からSELECT COUNT（1）、
2つのSQL結果は同じであるクエリは、ユーザが実質的であることを示しますメッセージを読んでいません。
3.問題が見つかりました。ユーザーは基本的にインデックスを取る前やテーブルの完全な評価の選択に、より多くのデータにつながる、未読のメッセージが表示されない、CBOは、評価指標の左より少ないデータを、
データの量が増加すると、CBOは好みますテーブル全体を取ります。
【
CBOは、「コストベースの最適化」と呼ばれる中国のコストベース最適化の略で
最適化する2つの方法がありますOracleオプティマイザ、ルールベースのある方法を最適化（ルールベースの最適化を、RBOと呼ばれる）
と、コストベースの最適化アプローチ（コストベースの最適化、CBOと呼ばれる）、
Oracle8の以降で、Oracleが強くCBOの方法を使用することをお勧めします。
]
暫定解決策：
月が前に設定されている未読のメッセージは、受信者を読み取るために、メッセージが読まれたかどうかを2つのフィールドがインデックス化され、ヒストグラムを生成します。
WORKBENCH_MES_REL指数にIND_WMR_RID_ISREAD（recipient_id、IS_READ）NOLOGGINGを作成します
。execがDBMS_STATS.GATHER_TABLE_STATS（ユーザー、 'WORKBENCH_MES_REL'、カスケード=> trueに、学位=> 8、METHOD_OPT => 'SIZE FOR ALL COLUMNS skewonly COLUMNS（recipient_id、IS_READ）FOR' 、NO_INVALIDATE => FALSE）。
ディープ思考：
この機能とにかくやっている間、明らかに使用されていない、多数のユーザは、未読メッセージを表示する習慣を持っていません。ウィルあなたは、5年前の未読メッセージあなたを読んで？
設計最適化する必要性：
この表をチェックし、メッセージの数千万を蓄積してきたが、条件を追加していない5年間のため、1のみ最新年のニュースを維持するには、それがパフォーマンスの問題出やすいです。
月未読メッセージ、ため有効性の損失の読み取りなど、デフォルトのマークを、前に2。
3.ユーザーアラカルトメニューは、このSQLをクエリの代わりに内部のユーザーのセッションでクエリ結果を入れて、セッション中に効果的なのは、当然の、また効果的なの犠牲にして、データベースを検索する必要はありませんでしたでしょう。この理由は、ほとんどのユーザーは未読メッセージ、分析から得られたデータを参照する習慣を持っていないということです。
----------------
免責事項：この記事はCSDNブロガー元の記事「深センGG」であるとBY-SAの再現著作権契約、CC 4.0に従って、元のソースと、このリンクを添付してください声明。
オリジナルリンクします。https：//blog.csdn.net/stevendbaguo/article/details/79287942