2021/05/08 15:29
Keisuke69
この辺すっかり忘れてしまった
2021/05/08 18:12
hirose30
ORACLE って色々便利な機能があるんやなあ
2021/05/08 18:21
odakaho
“昔はinよりexistsの方が速いなんて話があったが、今はオプティマイザが賢くて同じ模様”
2021/05/08 18:35
khtno73
いいかげんトレースフラグ立ててTKPROFな作業から開放されたい。MSSQLは分離レベルやロックはORACLEに比べてアレなんだが、SSMSやプロファイラの出来には感動しちゃうよ。
2021/05/08 20:17
ysksy
“昔はinよりexistsの方が速いなんて話があったが、今はオプティマイザが賢くて同じ模様。” そうだったのか。でもこんなSQL書く人は性能なんて知らねーぜな率高めなので、レビューで注意することに変わりはない…
2021/05/08 20:50
stakme
join使わず（shardingあると論理的にも物理的にも使えない）PK以外のindex指定、limit offset禁止、filesort自動検知までやっても漏れるときは漏れるし、日頃の行いが問われます（私は日頃の行いが悪いのでしばしば踏み抜く）
2021/05/08 21:45
Guro
最近根本から速くなったので、あんまり気にしなくなったなー。
2021/05/08 21:51
mame_moyashix
snowflake使えば何も考えなくても良い
2021/05/08 22:03
pkcnst
データ消してみると驚くほど速度改善するからマジオススメ
2021/05/09 00:03
itmammoth
ポスグレはマルチカラムインデックスは普通使わないよ
2021/05/09 00:10
OrionB312
遅かったらとりあえずINDEX貼ろうっていう人良く見る。怖い
2021/05/09 01:52
quabbin
「コストベースのリレーショナルデータべースなら大体共通」ではなく、具体的なチューンングはOracle特有の話が多かった…。
2021/05/09 02:21
oakbow
existsとinでは使いどころが違うのでどっちが速いとかじゃない気がするんだけどな。
2021/05/09 04:14
degucho
ややこしいSQLを書かないといけなくなった時点でDB設計の見直しが必要。チューニングはRBOからCBOになった時点であまり意味がなくなってハード性能を上げるかクラウドのスケールアップで解決する方が結果的に安い
2021/05/09 05:23
w1234567
自分はトリガー切って参照用のテーブルにデータ突っ込んでそっちから取得しちゃうことが多いなあ、というかOracleのヒント句の書き方とかもう流石に忘れた
2021/05/09 05:32
kagehiens
Oracleはオプティマイザが気難しすぎると思う。SQL Serverの新しめのやつは感動的にオプティマイザが良い(あとSSMSもOracleの管理/クエリ発行ツールよりGood)。IS NULLとか＜＞ぐらいは激重テーブル以外では気軽に使いたいもの。
2021/05/09 05:52
Wafer
SQLだけに注目するならアホの子になるのが一番手っ取り早い。SELECT * FROM table WHERE x=n の形から複雑にしない
2021/05/09 07:11
amatou310
Oracleってすごく高いと思うんだけど、やっぱりそれだけいいの？
2021/05/09 07:14
buzztaiki
統計によるアグレッシブなSQLの変形を見てOracleすごいってなった思い出。正しく設計するとオプティマイザが頑張れる余地が増える。bindpeekがない頃は実行計画が変に固定されて、それはそれで困る事もあった。
2021/05/09 09:12
gonsuke777
OracleのSQLチューニングはDBMS_SQLTUNEのリアルタイム監視レポートを使えると激変するので知っておいて欲しい。 www.oracle.com
2021/05/09 09:14
golden_eggg
ヒント句一時期割と使ってたけどほとんど忘れてしまってる。。連キーのくだりは未だに誤解してる人よく見かける