SQLが重いときに見るお気軽チューニング方法

SQLのチューニング方法 昔Qiitaで書いたものをzennにうつして、若干の修正、追加をしてみました。 ORACLEでの経験を元に書いていますがコストベースのリレーショナルデータべースなら大体共通の考え方だと思うので他にも使えると思います。 SQLのチューニングといえば比較的容易に済むインデックスをとりあえず作成する。といった対応を取られがちですが、数万レコード程度でのデータ量ではあまり効き目がなく（自分の経験則）、どちらかといえば、結合順が大幅に狂ってたりすることが原因のことが多かったりします。よって本当にインデックスがないことが原因なのか？を熟考する必要があります。（例えばID以外のフラグとかコードに単項目indexを貼ってるのもみたことがあります。怖いけど実話） また、インデックスを作りすぎるとオプティマイザが狂いやすくなって他のSQLにも悪影響を及ぼしたりするので結構熟慮して追加

[odakaho]

“昔はinよりexistsの方が速いなんて話があったが、今はオプティマイザが賢くて同じ模様”

[khtno73]

いいかげんトレースフラグ立ててTKPROFな作業から開放されたい。MSSQLは分離レベルやロックはORACLEに比べてアレなんだが、SSMSやプロファイラの出来には感動しちゃうよ。

[w1234567]

自分はトリガー切って参照用のテーブルにデータ突っ込んでそっちから取得しちゃうことが多いなあ、というかOracleのヒント句の書き方とかもう流石に忘れた

[Guro]

最近根本から速くなったので、あんまり気にしなくなったなー。

[quabbin]

「コストベースのリレーショナルデータべースなら大体共通」ではなく、具体的なチューンングはOracle特有の話が多かった…。

[gonsuke777]

OracleのSQLチューニングはDBMS_SQLTUNEのリアルタイム監視レポートを使えると激変するので知っておいて欲しい。 https://www.oracle.com/webfolder/technetwork/jp/ondemand/ddd2013/A-1.pdf

[buzztaiki]

統計によるアグレッシブなSQLの変形を見てOracleすごいってなった思い出。正しく設計するとオプティマイザが頑張れる余地が増える。bindpeekがない頃は実行計画が変に固定されて、それはそれで困る事もあった。

[kagehiens]

Oracleはオプティマイザが気難しすぎると思う。SQL Serverの新しめのやつは感動的にオプティマイザが良い(あとSSMSもOracleの管理/クエリ発行ツールよりGood)。IS NULLとか＜＞ぐらいは激重テーブル以外では気軽に使いたいもの。

[oakbow]

existsとinでは使いどころが違うのでどっちが速いとかじゃない気がするんだけどな。

[makun2]

　SQLのチューニングについて

[golden_eggg]

ヒント句一時期割と使ってたけどほとんど忘れてしまってる。。連キーのくだりは未だに誤解してる人よく見かける

[amatou310]

Oracleってすごく高いと思うんだけど、やっぱりそれだけいいの？

[Wafer]

SQLだけに注目するならアホの子になるのが一番手っ取り早い。SELECT * FROM table WHERE x=n の形から複雑にしない

[degucho]

ややこしいSQLを書かないといけなくなった時点でDB設計の見直しが必要。チューニングはRBOからCBOになった時点であまり意味がなくなってハード性能を上げるかクラウドのスケールアップで解決する方が結果的に安い

[OrionB312]

遅かったらとりあえずINDEX貼ろうっていう人良く見る。怖い

[stakme]

join使わず（shardingあると論理的にも物理的にも使えない）PK以外のindex指定、limit offset禁止、filesort自動検知までやっても漏れるときは漏れるし、日頃の行いが問われます（私は日頃の行いが悪いのでしばしば踏み抜く）

[ysksy]

“昔はinよりexistsの方が速いなんて話があったが、今はオプティマイザが賢くて同じ模様。” そうだったのか。でもこんなSQL書く人は性能なんて知らねーぜな率高めなので、レビューで注意することに変わりはない…

[hirose30]

ORACLE って色々便利な機能があるんやなあ

[Keisuke69]

この辺すっかり忘れてしまった