元スレMySQL 5.0
mysql覧 / PC版 / みんなの評価 : ○
前へ
402 = :
>>401
ありがと
ばっちりできました
404 = :
他のSQLにも色々あるしなぁ。
シンプルなselectひとつ取っても、
例えばSQLiteでは使えるカラム名が
MySQLでは予約語だったりするしなぁ。
405 = :
>>404
キーワードじゃない語は全部ちゃんと
クォートすれば。
406 = :
気本棚
410 :
便乗質問です。
mysqlってダンプファイルの中身見て、ロード先のDBに必要な
データベースがなかったら自動的に作成してくれるもんじゃないの？
411 = :
ダンプファイルってつまり単なる普通のSQLの塊だから
データをINSERTする前にテーブルをDROPしてCREATEするだけ。
それがダンプしたSQLの先頭にあるかないかの問題で、
MySQL側がどうこう言うことではないと思うが。
ダンプするツールが対応するか、もしくは手書きすべきだ。
413 = :
>>412
まったく問題ないと思うけど。。。
単なるPHPコードだよ？ 何かあるわけない。
414 = :
助言をいただきたいのですが…。
SELECT t1.id, t1.data, t1.update FROM table_name t1
WHERE t1.update = (SELECT MAX(t2.update) FROM table t2 WHERE t1.id = t2.id)
これは、重複するidを持つレコードが複数あるテーブルから、
更新日updateの一番大きいレコードだけをかいつまんで取得するSQL文です。
ここにさらに条件を加え、各idの「一番小さいupdate」をキーにソートしたいのですが、
効率の良いSQL文が書けません。
アドバイスをいただければありがたいです。
（グループ化とかいいつつ、結局GROUP BY使わない方法でやってますが…;）
415 = :
idと更新日のペアがタブっていたらどうするの?
416 = :
SELECT
t1.id, t2.data, t1.max_update AS update
FROM
(SELECT
id, MAX(update) as max_update, MIN(update) as min_update
FROM table_name GROUP BY id) t1,
table_name t2
WHERE
t1.id = t2.id AND t1.max_update = t2.update
ORDER BY
t1.min_update
417 = :
>>415
idと更新日のペアは一意になるようになっています。
>>416
ありがとうございます！
とても勉強になります。
418 = :
PHP から MySQL を使っています。
SELECT で varchar(2000) の値を取得するときのことなのですが、
PHP 側ではこの値の冒頭200文字程度しか利用しないと分かっているとき、
はじめから SUBSTRING で値を削って取得するメリットは小さいでしょうか？
一般に MySQL で余計な関数を使うと処理が遅くなると聞きますので、
こういった文字列処理は値を取得しておいてPHP側でしたほうがよいですか？
なんとなく、あらかじめ削っておけばメモリの消費が抑えられるのではないかという考えがよぎって迷っています。
419 = :
グループ化についてもう一つ助言をいただきたいのですが…。
GROUP BY AAA, BBB
これは、AAAとBBBが同一のものをグループ化すると理解しています。
そうではなく、AAAでグループ化して、さらにそれをBBBでグループ化する、
のようにGROUP BYを入れ子にするには、どのようなクエリを書けば実現できるのでしょうか？
420 = :
>>418
考え方による。
大規模なwebアプリなら、圧倒的にPHP側で処理すべきと思う。
あなたの力量にもよるけど、突き詰めると、DB側で処理するメリットは無い。
DB側で処理すれば、結果セットが巨大でもデータ転送が速く、かつ省メモリ。
しかし、データが永続的に増える条件下での削減量はたかが知れてる。
DB側で処理すれば、PHPコードがシンプルになる。
しかし、マルチバイト文字の扱いが微妙だし、潰しが聞かない処理(リクエスト、関数、etc)が増える。
DB側で処理すれば、クエリキャッシュが効けば1回限りの処理で済む。
しかし、処理済みデータをオンメモリキャッシュしたほうが、もっと速い。
DB側で処理すれば、PHP側の処理が軽くなる。
しかし、DBよりPHPのほうが簡単にスケールできる場合が多い。
こんな感じでいかがかしら。
421 = :
>>419
SELECT * FROM (SELECT * GROUP BY AAA) GROUP BY BBB
ただしAAAでグルーピングした時点でBBBの内容は不定になっている。
これで目的が達成できているか、不明。
422 = :
>>419
不可能。
423 = :
>>419
＞AAAとBBBが同一のものをグループ化
えー、そうだっけ？
425 = :
>>419
GROUP BYを入れ子にって、いったいどういう結果を期待してんの？
勝手な言葉で質問しても解釈がまちまちだからごらんの有様だよ。
426 = :
>>420
ありがとうございます!!
428 = :
データ型そんなに互換性ないだろう
全部見直さないとダメ
429 = :
access使うようなのがトランザクション処理が必要なのだろうか…
myisamでいい気がするがなあ
430 = :
>>428
大幅に見直すのはcreateのところだけじゃ不十分かな？
select,insert,updateの構文は;つければ使えない？
431 = :
selectで、○番目と○番目のレコードを取得、ってしたいんですが、
limitで複雑な指定できませんよね？
サブクエリを駆使するしかありませんか？
イメージとしては、こんな感じに指定したいんです。
SELECT * FROM table LIMIT (0, 1 AND 5, 1)
432 = :
>>430
見直しが極めて望ましい。
DBは意外と互換性がないので。
433 = :
>>431
UNIONがおすすめ。
(１つ目のクエリ LIMIT 0,1) UNION (２つ目のクエリ LIMIT 5,1)
いくつ繋げてもindex効くし、綺麗。
434 = :
>>433
ありがとうございます！
各クエリともLIMIT部分以外が同一であっても、
やはりクエリの数だけ走査しなおしてしまうのですよね？
435 = :
SELECT SUM( p.point )
FROM point_table p
GROUP BY p.id
ORDER BY SUM( p.p.point ) DESC
LIMIT 100
これは、各idのもつpointの合計値を、pointの多い順に上位100件取得するクエリです。
ここで得られるpointの合計値を求めたいのですが、
上のクエリをどのように修正すれば良いのでしょうか？
436 = :
>>434
つ EXPLAIN
また、一時テーブルをつくる方法も。
437 = :
>>436
なるほど、一時テーブルですか。検討してみます。
ありがとうございます！
438 = :
>>430
そのまま移植して動かして見てエラーが出たらなおせばいい
439 = :
MySQL を勉強中なのですが、クエリの最適化について悩んでいます。
SELECT d.date, i.ip, n.name
FROM update_log d
LEFT JOIN update_log i USING(id)
LEFT JOIN update_log h USING(id)
WHERE d.id = 100
AND i.ip IS NOT NULL
AND n.name IS NOT NULL
ORDER BY d.date DESC, i.date DESC, n.date DESC
LIMIT 1
『条件』
・update_log テーブルから、指定した id に該当するレコードのdate, ip, nameを取得する
・ただし、ip, name の各項は NULL 値が入っている可能性がある
・NULL 値ではない、もっとも date が大きいレコードを各項について取得する
上記クエリだと、取得にかなり時間がかかってしまうため、
よりよいクエリを発行したいのですが、よいアイディアが生まれません。
助言いただけましたらうれしいです。
440 = :
nとhが混ざってね？
それは置いといて、クエリよりインデックスの張り方の問題じゃないかな。
それぞれのテーブルに複合インデックスを張れば
普通に激速になりそうな気がする。
441 = :
いや、よく見るとクエリも変？
LEFT JOINいらなくね？ 違うか？
442 = :
それ自己結合する意味あんの？
条件の1つ目と3つ目なんて違う話だし
443 = :
レスありがとうございます。
>>440
すみません、一個所 n が h になっていました。
インデックスは EXPLAIN 見ながら貼り直したりしてみたのですが、
特に変化はみられませんでした。
>>441
>>442
それぞれの値を取得するために、
3つばらばらにシンプルなクエリを発行したほうが良いということでしょうか？
444 = :
すみません、そもそもクエリが条件に合致していませんでした。
SELECT d.date, i.ip, n.name
FROM update_log d
LEFT JOIN update_log i ON (i.id = d.id)
LEFT JOIN update_log n ON (n.id = d.id)
WHERE d.id = 100
AND i.ip IS NOT NULL
AND n.name IS NOT NULL
ORDER BY d.date DESC, i.date DESC, n.date DESC
LIMIT 1
445 = :
サブクエリ使ってください
select l1.date, l1.ip, l1.name
from update_log l1
where id = <入力値>
and date = (
select max(l2.date)
from update_log l2 where l1.id = l2.id
and l2.ip is not null
and l2.name is not null
)
446 = :
>>445
それだと全フィールドがnullのレコードが選択されるんじゃね
447 = :
アドバイスありがとうございます。
いろいろ試した結果UNIONでつなげることで落ち着きました。
はじめのクエリだとなぜだめなのかが、よくわかりません。
500行のテーブルに対して10秒近くかかってしまっていました。
クエリのどこに原因があるのか、おわかりになる方いましたら、
ぜひ教えてください。m(_ _)m
448 = :
二つのDATETIME型の差をTIMEDIFF関数を使って求めたのですが、838時間以上は丸められてしまいます。
正確な秒数を求める方法はありますか？
449 = :
>>448
time型ではそれ以上の時間は扱えない。
450 = :
あるレコードを DELETE するのと
あるレコードの主キーを UPDATE するコストっていうのはあまり変わらないですか？
みんなの評価 : ○
mysql一覧へ類似してるかもしれないスレッド
- MySQL 総合 Part20 (995) - [14%] - 2011/10/17 4:48
トップメニューへ / →のくす牧場書庫について