単にユニークなのを保証するだけだし
順番が必要なら別に項目作った方が・・・
Closeじゃなくてトランザクションで挟んでもよさそう。

現在は数千くらいのデータ量なんですが この先、数万→数十万は行きそうなので
ちゃんとインデックスを作っておこうと思いました。

DBにあんま詳しくないもんでよく分からないんですが
例えば特定のフィールドでLIKEで部分一致させるような場合
インデックスの種類はどのようなものが良いんでしょうか？

例えば、対象フィールドに PRIMARY として作っておくだけでも全然効果あるんでしょうか？

初歩的な質問ですみません。

あぁ…部分一致だとFULLTEXTになるんですか…
しかも色々と面倒そうですね…
やっぱあらかじめ自分で検索用単語データを別途作っておいた方が良いのかなぁ。

う～ん。よくわかんないけど…

何か検索された場合
単語とヒットしたデータの位置を格納したテーブルをまず検索する
そこでヒットしなければ改めて大元のデータ全部を検索する
ヒットしたら前述の単語とヒットしたデータの位置を格納するテーブルに
その情報を追加して行く…

みたいなのが一番効率と労力の軽減のバランスが良い気がするんですが。


FULLTEXTのインデックス化ってどんくらい使えるものなんでしょうか？

いやいやダメだ汗
ヒット数が多すぎるとデータ書き込みのコストがバカにならない…
検索する機会が少ないと問題ない気がするけど
一分に一回とかされたらもうダメ…

どこの図書館のシステム作ってるんだよｗ

>>853
今のところ、MySQLでは部分検索は前方一致しかINDEXが使えないので注意。
LIKE 'hoge%'の形ね。
LIKE '%hoge'やLIKE '%hoge%'だとINDEXはあっても使えない。

あと、FULLTEXT INDEXは今のところ日本語の検索には向かない。
あれは格納されているデータが半角スペースで単語に区切られている(=英文)と想定して
部分一致検索にINDEXを使える、というもの。

日本語でFULLTEXT INDEXを使える様にするにはmroongaとかがあるよ。

>>855で言っているやり方は転置インデックスと呼ばれるやり方で、
"MySQL 転置インデックス フルテキストインデックス"とかでググるとちらほら情報が出てくる。

がんばって。

>>858
うー なかなか部分一致を効率よくするには大変そうですね…
とりあえず言われた通り色々ググってがんがってみます。

基本的な話しで恐縮ですが
テーブルの件数が多くなってパフォーマンスが落ちた場合
エンジンがInnodbなら、InnodbBufferPoolをでっかくすると思うんだけど
エンジンがMyisamの場合、どこをいじればいいの？

>>866
ありがとう！
参考にしてやってみます！

genre_tbl
genre_id nt(5) PK
genre_kind varchar(30)
genre_idの99990,99999は特別な項目として予約
genre_idの99990,99999以外で使用している最大値を返す関数を作ろうとしています

select max(genre_id) from genre_tbl where genre_id not in (99990,99999);
で127が返ってきてるんで、これを
delimiter //
create function
sf_return_max_genre_id()
returns int
begin
return (select max(genre_id) from genre_tbl where genre_id not in (99990,99999) );
end //
delimiter ;

としたんですが、
+--------------------------+
| sf_return_max_genre_id() |
+--------------------------+
| 127 |
| 127 |
～と複数の行が返ってきてます。ストアドファンクションって戻り値は一つだけではないんですか？

>>871
それ、SELECT sf_return_max_genre_id() FROM genre_tblってやってない？
FROM指定すると、genre_tblの件数と同じだけ結果が返ってくるよ。
SELECT '0'だと1行だけ返ってくるけど、SELECT '0' FROM ..ってやると
テーブルの行数だけ返ってくるのと一緒。

>>873
あぁっやってましたorz
そうだったんだ。ありがとうございます！

>>872
なるほど、ちょっと確認してみます
ありがとうございました

ありがとうございました
メモリの設定を見直して様子を見てみます

適切なインデックスが設定されてるとして
億レベルのレコードがあるテーブルを
複数のテーブルに分ける(例えば1千万レコードずつ)のって検索速度的に意味ある？

>>890
あるよ。
パーティショニングの方が良いと思うけど。

>>891
横からで申し訳ないが、どのへんに効果があるのだろうか？
テーブルロックの影響範囲？(でも、ロックしたい時困りそう)
index 肥大化軽減？

ログテーブルなどは過去のデータを消しやすいように日付での
レンジパーティショニングしてるどそれ以外に
どういうメリットがあるか知りたいです。

上で早さだと言ってるじゃないかｗ

テーブル分割だと、連続していて欲しいデータが分断されちゃわない？

連続していて欲しいデータって、例えばどういうものかな？

エンジンにmroongaを使った場合、optimize　tableやanalyze tableに対応してないみたいで
mroongaの公式ページにもそのあたりの情報が乗ってないんだけど、やらなくていい仕組みになってるのかな
それとも、専用のメンテコマンドがあるんでしょうか。