のくす牧場
コンテンツ
牧場内検索
カウンタ
総計:127,644,914人
昨日:no data人
今日:
最近の注目
人気の最安値情報

元スレMySQL 総合 Part14

mysql覧 / PC版 /
スレッド評価: スレッド評価について
みんなの評価 :
タグ : - 1 + - mysqldump + - rXBUq5sa + - share + - utf8_bin + 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。
←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitter

601 = :

>>595
結局インデックス貼って順次phpで書き換えました。

604 = :

>>603
それだと片方重複でNGになっちゃう。

条件分岐はSQLではやらないほうがいいと思うけど。

605 = :

>>604
NGって?
エラー無視しておけば良いだけでは?

606 = :

>>603-605
あくまでも「両方共に一致する場合」なんです。
例えばidが2でnameがaaaだと登録出来るようにしたいのです。
primaryだとそれは無理なのではないでしょうか?

PHPを使って、1回毎にSELECTで登録されているか否かを判定して
対処しようとも思ったのですが、件数が増えると負荷がかかりすぎるので
なんとかSQLで対処出来ないものか?っと悩んでいます。

607 = :

存在するかどうかを判定する部分と挿入する部分はアトミックにしておかないと。
存在しないと思っている間に、
   他の人が存在しないから挿入。
挿入しようとして、、、エラーか二重挿入か。。。
となるよ。

608 = :

そんなものは、書き込みロックだコノヤロウ。
読み取りは複合インデックスで間に合うだろ。常識的な量なら。

611 = :

複合キーが使えるとは限らないのでは?
直接SQL叩くわけじゃなからろうから。

612 = :

みなさん、ありがとうございます!複合キーの存在を知りませんでした。

複合キーを指定すれば、双方に一致する重複キーは登録出来ませんでした。
ソースも提示していただき、ありがとうございました。勉強になりました。

615 = :

>>614
できるよ
CSVぶっかけとかもいける

622 = :

間違えた。
>>621>>620 宛て。

625 :

質問です。
内部結合と外部結合のどちらもできる場合どちらを使うべきでしょうか?

626 = :

状況によるでしょ、適切な方を使えばいい。

628 = :

連番ふってインデックス用意すれば?

632 = :

条件の後出しは嫌われるよ。

LIMIT対象が10万とか100万になったら今のmysqlでは遅いのはどうにも
なんないと思う。whereで適切に対象を絞れるようなデータの持ち方を
工夫しろとしかいえないな。

633 = :

そのLIMIT の数値が少ないときは速くなるの?
EXPLAINとってみた?
まあ構造考えた方がいいかもね。

635 = :

っと、リロードしてなかったー

637 = :

結局、「limit の offset が百万というのを、何か別のindexの掛ったキーから取り出せないか」ということに尽きるのでは。
offsetきっかり百万から30個欲しいというシチュエーションが、どういうものか、想像が付かないけど。

639 = :

探すのが人間だとそれはちょっと苦しいかな

640 = :

念のため、MySQL以外でも厳しいクエリなので誤解なきよう

641 = :

全てをDBに載せるんじゃなくてハッシュと併用すれば?

642 = :

しょっちゅう更新されるならあれだが、そうじゃないなら、delete のたびに
連番を振り直して primary キーと対応させたテーブルを作って join するとか。

645 :

あるテーブルの主キーを別な列に変えました。
そのときの新しいカラムが後ろにあるのですが、これをテーブルの先頭側に移動するには
どうしたらいいでしょうか?

またこの変更から気になったのですが、MySQLは必ず主キーの順で取り出されると
どこかで目にしたと思っていたのに、適当なselectだと元の主キーの順っぽく出てきます。
どこかにこの情報が格納されててanalyzeとかするとこういうのはきれいになったりするのでしょうか。
多少のキーワードでもいただければうれしいです。

>>638
同じような理由で、うちはwordpressっていうブログのデータベースにそれなりの数の記事突っ込ん
だら管理画面からじゃ管理できなくなりました。
しょっぱすぎるpkey直接指定の管理画面を用意してほぼ手作業(フィールドの直接編集っぽいやつ)
で編集してます。

647 = :

>>646
どこでこんな間違いを覚えてきたのか、某okwaveにも書いてありました。
> マニュアルにも「order by指定がない場合は、順序保証しない」ことは明記されています。
postgresql出身で、初めて知ったときはpkey順に保証されてるんだーmysqlってふしぎーとか思ってました。
ひどい思い違い乙。

649 = :

>>648
なるほど、インデックスを利用しているか否かによって違うってのは
意識したこと無かったです。そして感覚的に納得できます。

650 = :

>>647
RDBMSにはそういう概念が無いと言っている
実際、キミは困っているんだろ?


←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / mysql一覧へ
スレッド評価: スレッド評価について
みんなの評価 :
タグ : - 1 + - mysqldump + - rXBUq5sa + - share + - utf8_bin + 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。

類似してるかもしれないスレッド


トップメニューへ / →のくす牧場書庫について