本当にあったやらかしDB設計④【テストチューニング】 - Qiita

どうも、GWのほうが用事が詰まって忙しかった人です(外出はしていないのですが…) 今日は本当にあったやらかしDB設計③【ロジカルクエリー】に続いてびっくりしたことを紹介します テストチューニング 案件説明とかを受けると出会うことが意外と多いです どういうことかというと、本番より明らかにレコード数の少ないテーブルに対してチューニングを行う、ということです 何が悪いの？？ データベースではとある計算に基づいてオプティマイザー(DBの脳みそのような部分)が実行計画を立てます 今主流なのはコストベースオプティマイザーです コストベースオプティマイザーでは、レコード当たりの平均容量や、テーブルのレコード数に基づいて計算を行い、実行計画を立てます レコード数が全く違うテスト用テーブルに対してチューニングを行うとどのようなことが発生するでしょうか 問題 まず、チューニングといっても種類があります ①クエ

[nakag0711]

インデックスを貼らないという選択をするのもチューニングでは

[saiid]

カーディナリティとか占有サイズとか、この辺は割と運用の中で沼ってくるやつ

[chikurou]

ルールベースの方が実行計画が想定外にならないからヒント句使う方に行きがち。カーディナリティでインデックス貼るかどうかわかるはずで、なんか記事に書いてることが腹に落ちない。

[noseld]

何も考えずに全カラムにindex貼るとか多分そういうレベル感の人の話をしてるんだろうけど、こう一般化した記事で「チューニングしない」と堂々と書かれるとなんだかなぁと思う。

[kenzy_n]

アチャー

[denimn]

はい！本番と同じデータ量です！（同一レコードコピー）

[pavlocat]

選択・追加・削除それぞれ実運用でどんくらい実行されるかでインデックスどう張るか決めるのがええんじゃないですか知らんけど

[quabbin]

ヒント句で必ずindexを使わせる手法もありましてですな…