【新機能】作り忘れたまとめはありませんか?31日前まで期間指定してまとめが作れる高度な検索ができました。有料APIだからツイートの漏れはありません!

ORDER BY 狙いのキーの話

有用だと思ったので一連の流れをまとめてみました。
20627view 0コメント
22
ログインして広告を非表示にする
SH2 @sh2nd 2013-09-14 22:30:36
yoku0825先生のスライドが、はてブのトップに http://t.co/3jwfF0um1X
 拡大
yoku0825 @yoku0825 2013-09-14 22:48:08
∑(゚д゚lll) エッ!? RT @sh2nd: yoku0825先生のスライドが、はてブのトップに http://t.co/5wE21En8za
 拡大
con_mame @con_mame 2013-09-14 22:50:45
@yoku0825 200ブクマさらっと超えて来ましたね!DJ形式の良かったです!
yoku0825 @yoku0825 2013-09-14 22:55:45
@con_mame ありがとうございます! 恐縮です!
con_mame @con_mame 2013-09-14 22:56:35
@yoku0825 全ページ、僕もいつも経験していることばかりなので涙が…
yoku0825 @yoku0825 2013-09-14 23:29:11
@con_mame ああ、やっぱりそうなりますよね。。こっちは息をするくらい当たり前のことだと思っていても向こうは違って、向こうが当たり前に思っていることも俺は知らなくて、あぁ…ってなります。。
con_mame @con_mame 2013-09-14 23:53:17
@yoku0825 ですね。その間を埋めるのをどうするか考えることが多いです。。
Ryuta Kamizono @kamipo 2013-09-14 22:35:58
どのインデックスを使ったらいいか人に説明するときにどういったら伝わるのかいつも困ってたけど、次からはORDER BY狙いのキーっていうことにしよう。
どぅーあき @do_aki 2013-09-14 22:37:13
@kamipo それ有効なの limit 指定の時に限られるのでは
Ryuta Kamizono @kamipo 2013-09-14 22:46:01
@do_aki Webアプリケーションでいうと、なんらかの条件(たとえばuser_idとか)で絞り込んだ結果をLIMITなしで全部取ってきて表示するようなことは経験上ないと思う。十分に絞り込めないのにWHERE狙いのキーが使われて表示するのに必要ない行も内部的にはフェッチされて
Ryuta Kamizono @kamipo 2013-09-14 22:48:02
@do_aki Using filesortになるのは悲しすぎるから、フェッチする行が最小になるようにORDER BY狙いのキーを使えるように設計レベルではアドバイスすることが多いかな僕は。
yoku0825 @yoku0825 2013-09-14 22:52:55
@kamipo @do_aki ウチでは、開発者同士の初期レビューではUsing filesortなインデックスで通してしまって、件数がかさんでくるとそれが予想以上に重くて泣きつかれるのでORDER BY狙いのキーを作ってUSE INDEXさせる感じが非常に多いです。。
yoku0825 @yoku0825 2013-09-14 22:55:26
@yoku0825 @kamipo @do_aki 件数が少ない状態でSQLレビューしてるので、Using filesortやUsing Temporaryですら「(今は)50msで返ってくる、OK!」ってなっちゃうんですよね。。
どぅーあき @do_aki 2013-09-14 23:00:56
あー。たしかに、下手に where にインデックス使われるよりも、 order に使われる方が絞り込めるな。 offset に大きい値入れられると死ねるけど。
Ryuta Kamizono @kamipo 2013-09-14 22:58:20
@yoku0825 @do_aki 僕の経験上、DBがどうがんばって結果を返してるのかに無頓着なクエリが書かれてしまうのはSQLやORMの抽象度が高すぎてデータ構造の性質を隠蔽しているからだと思ってるんですよね。
Ryuta Kamizono @kamipo 2013-09-14 23:01:05
@yoku0825 @do_aki だから、HandlerSocketみたいにどのインデックスからデータを引くのかちゃんと指定しないといけないぐらいの抽象度のほうが、参照効率が悪いクエリを書くのがたいへんになるのでいいと思ってます。
どぅーあき @do_aki 2013-09-14 23:08:06
@kamipo @yoku0825 それはそれでちと使い勝手悪いケースもありそう。データの特性が明確ならば、そうしたほうがいいと思いますけど。
Ryuta Kamizono @kamipo 2013-09-14 23:20:01
@do_aki @yoku0825 そりゃあ、なにも指定しなくてもMySQLが空気を読んで選べるインデックスの中からよさげなものを選んでくれるほうが使い勝手はいいでしょう。そのインデックスを意識しないことのトレードオフが、必要なインデックスが張られてなくてあとで死ぬことだと思う。
yoku0825 @yoku0825 2013-09-14 23:19:54
@kamipo @do_aki ORMに隠蔽されすぎてる件は最近ひしひし感じてます。FuelのORM使っててSTRAIGHT_JOINできないとかUSE INDEXできないとか。 それは概念としてのRDBに対するアプローチとしては多分間違っていないけれど、
yoku0825 @yoku0825 2013-09-14 23:21:07
@yoku0825 @kamipo @do_aki 実装としてのMySQLには最適解ではなくて、ああなんだろうモヤモヤする、って感じが拭えないんですよね。
yoku0825 @yoku0825 2013-09-14 23:22:04
@kamipo @do_aki ORMの実装者が死ぬか、コード書くプログラマーが死ぬか、DBAが死ぬかのトレードオフなんですよね。。
残りを読む(2)
ログインして広告を非表示にする
ログインして広告を非表示にする