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

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

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

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

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

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

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

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

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

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

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

>>611
別にコンソールから出なくても
phpMyAdminとかでも普通に設定できるんだけどね。

phpmyadminていうのは、
もしかして、データーベースの設計はできるけど
その中にデータ-を突っ込むのはｐｈｐのコードを
書かないとできないの？

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

下の様なテーブル構成のテーブルがあったとしてsubjectとbodyが同じカラムデータをもっているので
まとめようかと考えています。

user(id,name)
subject(id,text)
body(id,text)

下の様にtextカラムをtypeでsubjectなのかbodyなのかを判別する形になります。
user(id,name)
text(id,type,text)

こういったテーブルの結合は結合前と比べてselect,update,insert時の速度にどんな影響が出るでしょうか？

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

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

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

質問です。
掲示板のデータを格納するようなテーブルを作ってデータを300万件ほど格納し、
以下のようなSQLを発行すると処理に40秒ほどかかってしまうのですが、
もっとデータの抽出に速度を上げる方法などはないのでしょうか？

SELECT * FROM Messages ORDER BY primary LIMIT 1000000, 30

尚、テーブルはMyISAMで設定は以下の通りです。

key_buffer = 512M
sort_buffer_size = 8M
read_rnd_buffer_size = 8M

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

>>630
レス有難うございます。
その方法も考えたのですが、DELETE文は流せなくなる（連番に空きが出来る為）のと、
他のカラム（書き込み時間など）でのソートが出来なくなると思います。

DELETE文は当初から流すつもりはないのでいいのですが。
他のカラムでのソートは結構ありえます。
INDEXが張られている他のカラムでも迅速に結果を抽出できたらと思っています。

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

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

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

>>632
レス有難うございます。
最初に記述しておくべきでしたね、以後気をつけます。

やはりどうにもならないですか…。
有難うございます、勉強になりました。

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

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

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

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

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

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

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

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

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

>>645
RDBMSにはそういった順番の概念はない。
順番が必要なら必ずORDER BYすること。

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

インデックスが使われたときはインデックス順、使われなければ格納順な気がする。
後者はpkを順番につけることが多いのでしばしばpk順に見えるが、順番につけなかっ
たときは一致しない。

動作としては自然だよね。ただし仕様はあくまでorder byなしのときの順序は保証しない
なので、依存したプログラムを書いてはいけません。

mysql> create table order_test (pk int primary key, c varchar(100));
Query OK, 0 rows affected (0.08 sec)

mysql> insert into order_test values (1,'a'),(10,'b'),(5,'c'),(3,'d');
Query OK, 4 rows affected (0.05 sec)
Records: 4 Duplicates: 0 Warnings: 0

mysql> select * from order_test;
+----+------+
| pk | c |
+----+------+
| 1 | a |
| 10 | b |
| 5 | c |
| 3 | d |
+----+------+
4 rows in set (0.02 sec)

mysql> select * from order_test where pk >= 3;
+----+------+
| pk | c |
+----+------+
| 3 | d |
| 5 | c |
| 10 | b |
+----+------+
3 rows in set (0.03 sec)

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

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