どうも、GWのほうが用事が詰まって忙しかった人です(外出はしていないのですが…)
今日は本当にあったやらかしDB設計③【ロジカルクエリー】に続いてびっくりしたことを紹介します
テストチューニング
案件説明とかを受けると出会うことが意外と多いです
どういうことかというと、本番より明らかにレコード数の少ないテーブルに対してチューニングを行う、ということです
何が悪いの？？
データベースではとある計算に基づいてオプティマイザー(DBの脳みそのような部分)が実行計画を立てます
今主流なのはコストベースオプティマイザーです
コストベースオプティマイザーでは、レコード当たりの平均容量や、テーブルのレコード数に基づいて計算を行い、実行計画を立てます
レコード数が全く違うテスト用テーブルに対してチューニングを行うとどのようなことが発生するでしょうか
問題
まず、チューニングといっても種類があります
①クエリーを変える
かんたんに言うと、同じ結果が得られる軽量なクエリーに書き換えることです
このチューニング方法はテーブル構造は変えずに、クエリーを変えるだけで速くすることができます
ただし、このやり方では限界があります
②インデックスを貼る
インデックスを貼ると予めデータをソートしておいてくれます
それから検索をするため、インデックスを貼っていないカラムよりも速く検索を行うことができます
ただし、オプティマイザーがそのインデックスを利用するかどうかはわかりません
コスト計算に基づいて実行計画が変わるため、いくらインデックスを貼っても利用されないことがあります
つまり、本番と類似したデータ、レコード数を持ったテーブルに対してチューニングを行わないと、実行計画が変わる可能性があるため意味がありません
原因
これが起きてしまう原因は単純明快です
- 本番データでは量が多いため、一部を抜き出してテスト用データとした
解決方法
本番データと同じ量のテスト用データを用意しよう！
テスト環境でインデックスをテストしてみて、速くなったから同じインデックスを本番環境に適用しよう！というのは、本番データとテスト用データが同じでないと意味がありません
個人情報など、一部をマスキングする場合は容量が大きく変わらないように注意してください
チューニングしない！
これは意外と重要です
インデックスを貼るのはノーコストではありません
データを更新するときにはインデックスにも更新がかかります
そのため、無駄にインデックスが貼られているとパフォーマンスが悪くなります
本気でチューニングをしたいのであれば、テスト環境をケチるべきではありません
まとめ
- 意味の無いチューニングをするな
- テスト環境をケチるな
最適化に対する最善の行動は「最適化しない」です
もしチューニングをする場合には慎重に行わないと意味がないどころか害になります
もし本番環境と同様のテスト環境を用意できないのであればチューニングは諦めたほうが身のためです