14/05/17 10:15:29.35
俺なら精度のカラム作るな
571:NAME IS NULL
14/05/17 10:33:16.95
>>569
まあどれがいいかは今後の運用方法によるけど
変換はUPDATE文工夫すれば数十万件なら一瞬だよ
572:NAME IS NULL
14/05/17 12:08:37.27
>>570
ぜひ詳しく。
>>571
ですよね～。SQLおぼつかないから勉強しないと。
573:NAME IS NULL
14/05/17 17:56:26.38
>>572
文字型では難しくて、日付型だと簡単なのは、日付の足し算、引き算だけでは？
>>561 の文献データベースなら、日付の足し算とか引き算は
文字型でも期間指定で検索ができるよ。
PubDate >= "1853年07月08日" AND PubDate <= "1854年06月01日"
少し話は違うけど、「嘉永6年」ではなくて「癸丑」と干支だけ書かれた文献もあるよ。
574:NAME IS NULL
14/05/17 17:57:42.50
>>573
× >>561 の文献データベースなら、日付の足し算とか引き算は
○ >>561 の文献データベースなら、日付の足し算とか引き算は不要では
575:NAME IS NULL
14/05/19 22:16:03.67
(´・ω・｀)バックアップ取るとき、default-character-setにbinaryを指定するのって変？
576:NAME IS NULL
14/05/20 13:05:08.37
>>575
安全
577:NAME IS NULL
14/05/22 01:44:14.44
バイナリーが文字コード依存じゃないからよいのでわー
578:NAME IS NULL
14/05/22 17:52:03.74
Mariaさまがみてる
579:NAME IS NULL
14/05/22 22:53:46.84
会社でmysql使ってるんだけど
Dumpしたデータをリストアしようとしたら、途中から急にメモリが跳ね上がってサービスが強制終了するんだけどなんで？
どこ調べても解決しない
580:NAME IS NULL
14/05/24 01:04:48.00
>>579
インデックスの構築で死んでるのでは？
581:NAME IS NULL
14/05/26 23:37:23.25
入門本というか基礎本一冊終わらしたんですが次に買うのにオススメの本はありますか？
582:NAME IS NULL
14/05/27 00:07:18.05
本読むのも良いし止めろとは言わないけど、自分で実際にデータ入れて作業してみたら？
そこで、外部制約かけたりとかストアドプロシジャ作ってみるとか
それから自分で出来る言語でDBアプリ作ってみるとか
583:NAME IS NULL
14/05/27 12:57:46.93
phpMyAdminでインポートタブのなかのフォーマットの中にCSV load dataみたいな名前のやつがあったのに無くなってしまった
元に戻すにはどうしたらよいですか？
584:NAME IS NULL
14/05/28 01:12:02.68 t9RKPMWp
books テーブル 300万件
1 book_id int(11)
2 book_title varchar(256)
3 deleted tinyint(4)
comments テーブル 50万件
1 comment_id int(11)
2 book_id int(11)
3 comment varchar(256)
で削除されていない本のコメント数を知りたいのですが
SELECT count(*)
FROM comments
LEFT JOIN books
ON comments.book_id = books.book_id
WHERE books.deleted=0
が遅すぎるので早くする方法ありませんか？
もしくは遅い原因など知りたいです。
下のでは物凄く早いのですが。。設定値とか見直すとこや他の件数の出し方あればお願いします。
SELECT comments.comment_id
FROM comments
LEFT JOIN books
ON comments.book_id = books.book_id
WHERE books.deleted=0
585:NAME IS NULL
14/05/28 05:20:49.87
>>584
下のが早いならそれでいいじゃん。
count(*)してるからじゃないの？
586:NAME IS NULL
14/05/28 20:51:20.13
>>584
books.book_idには主キーかインデックスを作ってあると思うけど、
それを大前提として、それでも遅いならディスクI/Oかなあ。
Linuxならiostat -xm 1 で r/s と %util を見て。Windowsは知らん
587:NAME IS NULL
14/05/28 21:19:12.68
>>584
2つのクエリのEXPLAINの結果を張ってくれ
588:NAME IS NULL
14/05/29 00:49:09.08 0XuSN7uc
返信遅くてすみません。
>>585
すみません、上の結果がほしいのです。
というよりは件数がわかればなんでもいいのですが。
>>586
確認してみます。
>>587
上が2.2秒ほどで
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE comments index book_id book_id 4 NULL 500509 Using index
1 SIMPLE books eq_ref PRIMARY PRIMARY 4 test.comments.book_id 1 Using where
下が0.0027 秒
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE comments index book_id book_id 4 NULL 500509 Using index
1 SIMPLE books eq_ref PRIMARY PRIMARY 4 test.comments.book_id 1 Using where
上はSending Dataが2秒以上かかっているので
COUNTが原因なのはわかったのですが
JOINすることでtmpテーブルがつくられてしまってなど原因があるのでしょうか
数えたりしてるために遅いのでしょうか？
589:NAME IS NULL
14/05/29 01:34:48.86
>>588
プラン同じだね。
下は結果がが50万行出てくるけど、50万行垂れ流すのが0.0027秒で終わるわけがない。
何らかのGUIツールを使っていて、1画面だけ表示、暗黙的にLIMIT 100とかしてない？
つまり上が遅いのではなく、下がインチキしている(最後まで処理をしていない)と言いたい。
プラン見る限り一時テーブルは作ってない。
それで個人的な感想ですけど、50万行の集計が2.2秒というのは「十分に速い」です。
明らかにI/Oはしていない。I/Oしてたら数分かかる。
もっと速くしたいなら前段にmemcachedなどを入れて結果をキャッシュしよう。
590:NAME IS NULL
14/05/29 01:59:43.88
あと、メンテナンスがつらくなるのでおすすめはしないけど
テーブルを非正規化してcommentsテーブルにdeletedカラムを入れてもいいと思う。
それで1秒は切れると予想。