14/06/18 20:49:53.47
>>17
それはそうと、リプライ(reply) と リプレイ(replay) は違うよ。
>>20
joinでもいいと思う。
22:NAME IS NULL
14/06/18 21:08:16.67
>>20
inとexistsはオプティマイザによる変換難しいけど
existsとjoinはオプティマイザが簡単に変換するから
読みやすいほうで良いでしょ
23:NAME IS NULL
14/06/18 22:29:34.81
なんか、in exists join 関連の話よくループするね。
テンプレ入りするかも?しないかも?
24:NAME IS NULL
14/06/18 22:40:29.77
>>20
mysqlのexplainを読めないなら黙ってても良いんだよ?
25:17
14/06/19 05:02:55.31
不手際が多く色々と混乱させてしまったみたいで申し訳ありません
ご指摘どおり joinへの置換えを行った所
10000ms→4000ms→0.04msまで落ちました
本当にありがとうございました
26:NAME IS NULL
14/06/19 05:04:09.29
>>24
じゃああなたが>>20の疑問点に解説を
27:NAME IS NULL
14/06/19 12:12:14.69
おめでとー
28:NAME IS NULL
14/06/19 12:15:07.32
>>17が最初に質問した元スレで話題になってたんだけど
468 名前:nobodyさん[sage] 投稿日:2014/06/19(木) 11:53:09.08 ID:???
彼は解決したって書いてるけどjoinを使うことでサブクエリが先に消化されてソート対象がメモリ上に乗るサイズになっただけで結局もっと数が増えたらメモリに乗らなくなってまた遅くなるよ
10万件程度のデータでもメモリに載り切らなくなるのはわかりきってるしTwitterみたいに大きくないから大丈夫なんて言える問題じゃない
みたいな書き込みがあったんだけどそうなの?
29:NAME IS NULL
14/06/19 12:25:50.89
お察しレベル。
元スレどこなの?
30:NAME IS NULL
14/06/19 12:27:21.34
>>29
やっぱレベル低い争いなのか
スレリンク(php板)
31:NAME IS NULL
14/06/19 12:42:55.77
>>28
INは全表をメモリに載せようとするけど
JOINやEXISTSはしないで(HASH) SEMI JOINやINDEXで精査しようとするから速いんだよ
ただ、JOINやEXISTSの方式でも件数が影響するので
桁がかなり増えれば、当然遅くなる
最近オプティマイザも賢くなったがな
32:NAME IS NULL
14/06/19 13:01:52.81
あんまりORM批判はしたくはないが
INはORMで簡単に実装できるからよく使われるのに対して
テンプレに載せようかって話す位の常識を知らないやつが増えたね
33:NAME IS NULL
14/06/19 16:41:08.52
>>31
それMySqlの話?
なんかググっても、MySqlにはネステッドループとその変形しか実装されてないって書いてあるんだが
一般論なら、今時はINもEXISTSと同様に展開するんじゃね
まあ、結局はオプティマイザの出来次第なんだが
34:NAME IS NULL
14/06/19 16:44:02.06
SQLServer2005です
数年分のログを2週間ずつページングして表示させたいです
取り敢えず最初のページのケツの日付を次ページの先頭条件としてみましたが、当然前ページのと被ってしまいます
各ページの先頭行を取得するにはどのようにすればよいでしょうか?
35:NAME IS NULL
14/06/19 16:56:24.54 TW0nEEQA
ページ番号から計算すればよさそうなもんだけど。
36:NAME IS NULL
14/06/19 17:06:36.77
>>33
existsはjoinの変形とできるけど、inは違うから一概には一緒にはできないよ
オプティマイザが賢ければやってくれるんだけどね
MYSQLは5.6.5からNEST以外のjoin方法が実装されたよ
37:NAME IS NULL
14/06/19 20:53:12.43
カラムの値を11倍にして格納したいんですが、どう書けばよろしいでしょうか?
検索しても2000を10000に置き換えるといった置換ばかりかヒットして思うように見つけられません
ご教示お願いいたします
38:NAME IS NULL
14/06/19 20:53:59.97 TW0nEEQA
update tbl set col = col * 11where ~
39:NAME IS NULL
14/06/19 21:04:07.09
>>38
ありがとうございます!
たすかりました!
40:NAME IS NULL
14/06/19 21:29:26.50
>>34
> 取り敢えず最初のページのケツの日付を次ページの先頭条件としてみましたが、当然前ページのと被ってしまいます
被るの嫌なら、ケツの次の日にすればいいだけじゃないのか?
そもそも要件が2週間毎なら、>>35 の言うようにページ番号から計算すればいいだけだろ。
41:NAME IS NULL
14/06/19 21:57:39.98
日付に時間が含まれてるかどうかとかいろいろ細かい考慮点はあるにはあるけど
開始を<=じゃなくて<にするとか、そんな程度の話じゃないの