ログっつーもんはないのか

>ファイルをDBに格納する場合、BLOB型ならbase64エンコードをしなくて
>そのまま突っ込んでもいいという事ですか？

いいですよ。そのための BLOB です。なお、prepared statement 使って下さい。

>BLOBにしておいて文字のデータ入れたりTEXTにしておいてバイナリ入れたりするのは邪道ですか？

compare しないなら、どっちも同じ。
compare するなら、text の方は characte set が効いてくるので、予期しない結果になるかも。

>>394
もちろんkillで殺すんですが知りたかったのは
クエリだけを停止するのは何のシグナルかということです

検索結果が1行だとわかっているときって LIMIT 1 付けたほうが速いのかな

誰も実験したこと無いなら実験してみる

>>407
ありがとうございます。BLOBでデータ入れる事にします。

とりあえずPCの中にエロ画像が20万枚位あるので全部放り込んでみます。
一つのテーブルに20万枚入りますか？
テーブル分けたらいいんだけど、一つのテーブルってどの位のレコードが限度なんですか？
PCの能力に左右されるんですかね？
知ってる人教えて

あの、すいません。
MYSQLに画像を入れようとして、BLOB型で入れたんですが
WINDOWSのコマンドで確認してみると、エラー音とともに
バイナリ文字が大量に出てきました。
それをPHPで取り出して、ヘッダー(Content-type: image/gif)を
入れると画像として表示されるんですが
どこかおかしいですか？

どこもおかしくないんじゃない

>>408
http://dev.mysql.com/doc/refman/5.0/en/kill.html

内部的にこんなふうに動いてるみたい。
select * from Sample_TB where id = cast('' as decimal);

で、
mysql> select cast('' as decimal);
+---------------------+
| cast('' as decimal) |
+---------------------+
| 0 |
+---------------------+
1 row in set, 1 warning (0.00 sec)

mysql> show warnings;
+---------+------+---------------------------------------+
| Level | Code | Message |
+---------+------+---------------------------------------+
| Warning | 1292 | Truncated incorrect DECIMAL value: '' |
+---------+------+---------------------------------------+
1 row in set (0.00 sec)

警告が出る。
ちなみにOracleだと''はNULL扱い、'a'とかやるとエラー。

select文とexplainの結果を食わせて
どうしたらいいかのヒントまでくれるような
そんなソフトってないかな

インデクスがあるのに何で使ってくれないんだー、ばかー、というとき、理由の explain が欲しいことはあるな。

whereで分散とかダメ？

>>424
さっそくのレスありがとうございます。
whereで分けるというアイデアは気づきませんでした。
で、先ほどやってみました。
で、うまくいきました、とご報告したかったのですが、
こんどは別のSQLのGROUP BYで同じくOut Of Memoryで落ちました。

結局、相当な数のSQL文に手を入れることになりそうです。
もう、テストも終わりを迎えておりまして、
これを全部対応しようとすると、再度テストをやり直す羽目になりそうです。

パラメータを変更するなどの運用でなんとかするというのは難しいでしょうか。
数万件でOut Of Memoryが多発すると考えていなく、誤算でした。

数十万件のソートは普通にできますが、僅か数万件のソートで問題が生ずるのなら、
むしろソートする1レコード（キーとか色々含む）が巨大で、それが sort_buffer_size を
上回るとかの問題ではないかという気がします。(ソート自体はtemp fileを使うはず)。

「Needed 2095128 bytes」と言われたなら、素直に my.cnf に
sort_buffer_size=10MB
とか書いておけばよいのではないかと思いますが…。

ただ、もし本当にレコードが巨大なら、それを丸ごとソートする事自体を考え直す方がいいかも。

>ソートする列は、単純な6桁の番号や5文字のCHARなので、大丈夫だと思っていましたが、
>ソートする場合は、該当する列だけではなく、その他のデータも含まれるんですね。

いや、一行目の理解で正しいんじゃないでしょうか。
なんだか、ソート以外の処で引っ掛かっているような気がします。

>>429
> なんだか、ソート以外の処で引っ掛かっているような気がします。
ありがとうございます。それなら、まだ改善の見込みは少し残っているかもしれませんね。


ちなみに、これ、もし、宜しよろしければ、
どなたか、コメント頂けると嬉しいです。

今回のエラーに関係がある部分を抜き出しました。
*****で書いてあるのが、かなりいじった所です。
チューニングについて書いてある色々参考にしたため、
つじつまが合わなくなっているかも知れません。

[mysqld]
key_buffer = 64M　*****
tmp_table_size = 64M　
table_cache = 1024　*****
sort_buffer_size = 2M　*****
read_buffer_size = 2M　*****
read_rnd_buffer_size = 4M　*****
myisam_sort_buffer_size = 64M　*****
thread_cache_size = 8
query_cache_size = 32M
max_connections = 200　*****

default-table-type=InnoDB

innodb_buffer_pool_size = 256M　*****
innodb_log_file_size = 64M　*****
innodb_log_buffer_size = 32M　*****

[isamchk]
key_buffer = 128M　*****
sort_buffer_size = 4M
read_buffer = 4M
write_buffer = 4M

[myisamchk]
key_buffer = 128M　*****
sort_buffer_size = 4M
read_buffer = 4M
write_buffer = 4M

ほんと、なんどもすみません。積んでいるメモリーは2GBです。
innodb_buffer_pool_size + key_buffer_size + max_connections * (sort_buffer_size + read_buffer_size) + max_connections * 2 MB
で計算すると1520MBで、Apacheと共存して使っています。

OSは何？
Windows 32bitだと普通に限界近いよね。

ふつうに32bitの壁っぽいね。
64bitにするとか、
上位層からの同時接続数を絞ってもらうよう
交渉するとか。

MySQLのレコードの処理は4万件でも10万件でも100万件でも
基本的に問題ないよね？チューニングしてれば。

でも、エラーになりやすい事を考えると、
レコードが増えていったら、テーブルを分ける方が良いのだろうか？

問題ないすよ。

エラーになりやすいかどうかは一般化できないし、
それに対してテーブル分割が適しているかどうかも一般化できないと思うけど。

テーブル分割のメリットって、検索範囲を絞る必要が軽減されて
SQLやインデックスで考えるパラメータが減りますよね、とか
インデックス張り直す速度が向上しますよね、って程度しか思い付かない。
その代わりに柔軟性が落ちて、出来ない検索が増える、と。
あんまメリット無くない？

2chのように1日に何万回も書き込みが発生する規模の掲示板を作っているのですが、こういったことにデータベースは不向きでしょうか？
レンタルでの運営なので全体では2ch規模になると思われます。

検索機能もほしいのでできればデータベースでレス１つ１つを保持したいのですが莫大なログの読み書きは現実的に可能でしょうか？
ロードバランスなどの負荷対策は行います。

>>438
板毎にテーブルを作成するの？

2ch規模だと、板毎にサーバが必要になるだろうけど、
まぁそんなアクセスは無いと思うから、普通に大丈夫だと思うけど。

板をまたいだスレタイ検索ならともかく、
板をまたいだスレの内容（レス）検索って、あっても相当使いにくそうな気がする。

>>439さん

レスありがとうございます。
同一テーブル内で一意な掲示板IDをふって分ける形になります。
携帯のレンタル掲示板なのですべてのアクセスを合算すれば２ch規模になることもありえます。
負荷対策はプロキシかませてごちゃごちゃやることになると思います。

ログ自体はdatファイルで保存して検索されうるデータだけDBに入れておいてDBは検索の時のみ使うのが最適でしょうか？
すべてのレスが同じテーブルに格納されているのでビジーになってしまう気がして…
ご教示お願い致します。

>440さん

レスありがとうございます。
全体検索はスレタイのみでもごまかせると思いますが、
画像や着うたの投稿も実装するのでできればレス検索も想定しておきたいです。

おそらくレス検索は別サーバに全レスデータいれてsennaでぶんまわす感じになるとは思います。

>ログ自体はdatファイルで保存して検索されうるデータだけDBに入れておいてDBは検索の時のみ使うのが最適でしょうか？

俺もそれでいつも悩むんだけど、ログ＝検索されうるデータじゃないのか？
例えば、スレタイ・レスと登録日のテーブルを分けるとしても
結局、必要なデータなわけだから、DBに入れるのもdat化するのも
同じ事のように思うんだが。

DATのほうが使いやすいと思う・・・。データベース鯖のこと考えなくて済むし。
掲示板レンタルならなおさらじゃない？

でも、ログを検査する時、大量に読み込まなきゃいけないだろ？
実質無理じゃないか？負荷がかかりすぎて。

書き込みをdatにしまうときに、senna に掛けて検索用キーだけDBに入れる、という意味じゃないの？

検索用キーを入れても、取り出す時に
ファイルを読み込まないといけないのでは？俺の知識不足かな。

>>447
そりゃそうだが、読む必要があるのは表示する分だけだから、ごく少量でしょ。

>読む必要があるのは表示する分だけだから

ってことなら、やっぱりDBでいいんじゃないか？