>>446
>>450にある通り、処理結果が不定になるので
レプリケーションのマスタでそんなSQL流したら俺がグーで殴りに行くけどな

じゃあ、俺はチョキで目潰しを。

おいどんはパーで張り手でごわす。

＞処理結果が不定になるので
え、update結果がバイナリログで
伝わるんじゃないの？
クエリだけが伝わって、実行内容は
不定なの？

>>453
5.1以降に実装された行ベースbinlogを使っていない限りは
マスタで実行したSQLが記録されている

スレーブはそれを再実行している

http://dev.mysql.com/doc/refman/5.1/ja/replication-formats.html

>>453
binlog-format が statment(ステートメントベース)なら query が、
row(レコードベース)なら結果が入ると思う。
mixed の場合どのように判断されるかは試していない。

ステートメントベースの場合は error_log に次のような warningが出る。
Statement may not be safe to log in statement format. Statement: query...

ちなみに、
* ver 5.1.12～5.1.28 までは default mixed
* それ以外は、default statement
5.1.29 で 5.0系との互換性のために戻されてます。
row(レコードベース)は 5.1.5以降で実装。

row は安全だが、binlog にすべて書かれるのでレプリケーションの遅れや
マスター側の書き込み量の増大などが考えられるのでオススメしない。

binary型がいまいちよくわかりません
binaryというだけあって画像なんかのデータを入れるのに使うのかなとは思ったのですが
こちらはblobを使うようなので
char型のを全てbinary型にしても問題はないですよね？
両者にどんなメリットデメリットがあるのでしょうか？

>>457
ちょっと違うかもしれないけど、自分はperlのutf8フラグ あり/なし
みたいなものと捉えてる。

例えばchar(10)としたカラムがあった場合、
UTF8では30バイト、binaryでは10バイトの領域を占有する。
で、UTF8の場合はUTF8文字で10文字分格納出来るわけだけど、
binaryの場合は10バイト(UTF8文字で3文字)までしか格納できない、
とかの違いがある。あと、照合順予やエスケープ、ソートの結果とかが異なる。

メリットとは言えないかもだけど、ウチの場合、かつて4.0系から5.0系にupした時に、
一時的に文字コード絡みの各種不具合（ってか仕様）を回避するために使ったことはある。
charset=binaryにしておけば、server/clientの文字セット指定に関らず無変換なので・・。

あと、あんまり用途はなさそうだけど、同じテーブルの同じカラムに異なる文字コードの
テキストを入れたい時になんかにも利用できる。

>>458
詳しい解説ありがとうございます
utfの例はわかりやすかったです
その例だとcharのほうが文字コード考えないでプログラムできるのでよさそうですね
照合順序、エスケープ、ソートこちらもこれから調べてみます。

基本的にあまり多用するようなものではないんですかね？
webプログラムなんかのコードを見るとあまり使ってる例はみないので
1度だけbinaryとvarbinaryを多用してるテーブル定義を見たことがありましたが
結局は設計者次第なんですかね

導出によって求められる項目を弾くのは第一正規化の基本

>>463
インサート文を書いて、mysqlに送信するといいよ。

今こそ優しさが試されるとき。

>>468
Xreaならphpmyadminが使えるからそれで。

・・・というか、その知識と検索能力のなさで、MySQLで何をするつもりなのかが気になる。

>>470
写真を掲載するサイトを作ろうと思いまして・・・

写真とその写真に関する説明文をセットでデータベースに登録しようと思っています。

でもデータベース難しそうですね('A`;)・・・
私のやろうとしてること程度でしたらデータベースなんて使わずに
ローカルにファイル名と説明文をセットにしたテキストファイルを
用意してそれをPHPとかから読むようにしたほうがいいかもしれませんね・・・

PHPでMySQLからデータを読み込むアプリを作れるのであれば、
先にファイル名と説明文を登録・更新するアプリを作ってから、
表示用のアプリを作る方が、イメージをつかみやすいと思う

>>473
・アップロード
・更新
・表示

この３つを全てPHPで作ると言うことですね。

そゆうこと。
アップロードとかサンプル見ながらやれば割と簡単にできる。
少なくとも、直接SQLを発行して管理をするくらいなら、
自分で言っていたようにDBよりテキストファイルを使う方が賢い

>>475
了解しました(・∀・)

> 自分で言っていたようにDBよりテキストファイルを使う方が賢い

やっぱりそうですよね('A` )・・・
更新したときもデータベースに修正しなおす必要もありませんし・・・

>>461-462
ありがとうございました。アドバイスのやり方に変更します。

indexについて質問なんですけど、
insertやdeleteをするとindexの再構成が発生するのは当たり前として、
indexに絡まないカラムのupdateをした場合には
indexの再構成は発生しないで済みますか？

>>478
はい。

>>479
ですよね、ありがとうございます。

一度作った行って削除しないのが普通ですか？
AUTO_INCREMENTでIDを挿入している場合
削除したらそこの部分だけポッカリ空いてしまいますよね？
現在の最終IDが100だとしてID2の行を消した後に
次に作成される行のIDが2になれば埋まりますが101になるので
IDを表示した場合歯抜けみたいでマヌケになってしまいます
削除フラグなんかをつけて表面上は削除したように見せかけてデータだけ残すなんて手もありますが
不必要な情報や個人情報なんかをユーザーが削除後も残しておくのはどうかと思うのですが
皆さんはAUTO_INCREMENTでID振ってる場合どうしますか？
削除してIDが抜けても気になりませんか？

>>481
IDが抜けてなにを気にすることがあるの？
別に１ずつ増加じゃなくて、重複しないようにランダムで振られたっていいというのに。

IDというのは単に「その行を識別するための何か」であって
必ずしも数値である必要は本来無いもの。
ただ単に、扱いやすいから数値を使っていて、
ただ単に、扱いやすいから１ずつ増加にしているだけだよ。

もし「登録順にソートしたい」なんてシステム用件があるのなら
それはそれで「登録日」とか「登録順」といった別カラムを用意すべきだし。

>>482
わかってはいるんですけど何か気になるんですよね
私みたいに気にする人はいないってことなんですかね
気にしないようにしたいと思います

>>483
>>482の言う通り、ユニークとするものだから、
必ず連番にしたいのなら、自分で空き番取る処理を入れればいいだけだよ。
気にする、しないじゃなくて、必要があればするだけ。

IDの使い回しなんかすると、いらんバグを作り込むだけだから
やめていおいた方が良いよ。
他人のデータが表示されたりとか。

>>481
>一度作った行って削除しないのが普通ですか？

ふつ～かどうかは知らんが、まあDELETEはインデックスの再編成を伴うから
比較的重い処理ではある。

ポスグレやInterbaseならDELETEでもUPDATEでも、この点同じだから気にしてもしょうがないけど。

並んだ数字に抜けがあると気持ち悪いのは良く判る
んが、残すかどうかとは関係無いのう

初心者が大抵通る道だなｗ
後で考えるとなんてバカなことを気にしてたんだろうと思うけど

LIKEの範囲をid(主キー)が1,5,7の場合という風に限定したいのですが、
どのように書けばいいでしょうか？

select * from db where foo LIKE'%test%' ... id =？？？？

普通にAND条件ではいけないの？

質問がわからんけど

select * from db where foo LIKE '%test%' and id in (1,3,5)

とか、そいうことをやりたいんだろうか？
まさかそんなことを聞いてるわけじゃないか。

さくらインターネットを使っているのですが、

↓たまにこんなエラーが出て、一度出ると１時間以上なにも出来なくなります。
何か解決方法とかはありますか？

I cannot connect to the database because: User ********* already has more than 'max_user_connections' active connections

>>494
コネクションが生きっぱなしなんだろ。
時間がかかる処理をたくさん並列動作させてしまってないか？

>>495
全てしっかり MySQL Closeしてます。

さくらの共有鯖って本当に終わってます。

他の人のプロセスが食っちゃってるんじゃね？

>>499
やっぱそうでよね。今つかってるプレミアで他のユーザ数を調べたらそれでも６０とかいましたし。