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