>>903
デフォルトではそう。

オプションで
「あるDBのみレプリケーション」
「あるDBのみ除外」
「あるテーブルのみレプリケーション」
「あるテーブルのみ除外」
が設定できる。

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


そういえば5.5のマニュアル全然日本語化されないねぇ。

>>904
おお、これは
詳しい解説ありがとうございます

show tables; では確かに一覧の中に表示されるテーブルが、
select * from TABLENAME; では表示されません(Table 'database.TABLENAME' doesn't exist)。
原因は何が考えられるでしょうか。

具体的には…
データを同期させているノートPCとデスクトップPCでWordPressをいじってまして、当該テーブルは wp_* の各種テーブルです。
ノートPCでインストール・作成したWordPressが、同期したデスクトップPCではテーブルにアクセスできないために動きません。

両PCのDBはファイル単位(\xampp\mysql\data\database)で同期しています。
両PCから見える phpMyAdmin の表示は、当該データベースも特権ユーザー周りも同じに見えます。
WordPressのようなアプリケーションからではなく、自分で作成したテーブルは、両PCでこれまで問題なく動いてきました。

たぶんこれらの報告も同じ症状のように見えます。
http://okwave.jp/qa/q7544736.html?sort=datetime:ASC
http://hatomugi.sakura.ne.jp/forum/topic.php?id=108
http://aki.adam.ne.jp/bbs/question/detail.php?rt=683&id=683

>>908
ALTER TABLE testtbl AUTO_INCREMENT = 1;

ただしALTER TABLEは暗黙のコミットを引き起こすので注意。
http://dev.mysql.com/doc/refman/5.1/ja/implicit-commit.html

あと、必ず毎回空にするのであれば、
TRUNCATE testtblで中身をからっぽ＆AUTO_INCREMENTを1に戻してくれる。

>>904
＞そういえば5.5のマニュアル全然日本語化されないねぇ。
オレはとっくにあきらめてる。orz

5.6では、正式リリースと同時とか
期待してるんだぜ。

>>914
ストアドファンクションでできるよ。

空白の制御とか細かいところ作ってないけど、
20文字くらいを処理させるのに大体1ミリ秒弱だった。

>>916
あ、INSERT部分じゃなくて文字列をパースして分かち書きにするところまで。。

>>920

レスありがとうございます。

他にも checkとpriceとか、checkとnoとか
色々な組み合わせで検索したりするんですが

それらも全部それぞれの組み合わせで
複合インデックスを作成しておいた方がいいという事でしょうか？
要するに、(`check`,`date`)、(`check`,`price`)、(`check`,`no`) とかで。

それとも全部纏めての複合インデックスの方がいいんでしょうか？
要するに、(`check`,`date`,`price`,`no`) とかで。

質問ばかりすみません。

>>921
検索と更新の割合次第…としか言えないかなぁ。

インデックスは基本的に
・無駄なインデックスでも検索には基本的に影響が出ない
・有効なインデックスでも更新には常に影響が出る
ものだから、
更新が日に1回しかないのならがっつり作っちゃえば良いし、
更新が断続的に続くなら検索頻度が高い組み合わせだけで
複合インデックスを作った方が良い。

全部まとめて複合インデックスにするのは多分NG。
複合インデックスは順番どおりに使わないといけないってルールがあるから。

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

がんばれ。

>>923
`check`のカーディナリティが2だから、
複合インデックスにしてもORDER BY分しか速くならないからね。。

残しておくかどうかの基準は>>922といっしょ。
本気で見極めるなら、検索と更新のターンアラウンドタイムを取って確かめるしかない。

>>922
あっ、書いてる間にレスしてくれてたんですね（汗）
すみません。

そうですかー、全部纏めて作るのはＮＧなんですか。
そうなるとやっぱり組み合わせの分だけ作った方がいいような気がしますね。

データの追加とか更新はそこまで頻繁にはないので
検索重視のシステムを構築したいと思います。
ですのでやっぱりインデックスをがっつり作っておきたいと思います。

外部ページなんかも紹介してくださってありがとうございました。
非常に参考になりました。助かりました。どうもです。

あっカーディナリティっていうのは
checkには二通りの種類しかない＝カーディナリティが２という事なんですかね。
確かにインデックス作ってもこれは効果が薄そうではありますね… う～ん。

>>929
それは良かった！

LIMITで指定するのが遠くなると遅くなる訳は少し長くなるけど、

・複合インデックスを指定する前
　⇒WHERE `check` = '1'で多分インデックスが使えない
　　（期待値的にインデックスを利かせるよりテーブルスキャンのが速いとオプティマイザが判断してると思う）
　　⇒20万行(レコード全部)テーブルからフェッチ。
　⇒ORDER BYでもインデックスが使えない。
　　（`date`にインデックスが無いから）
　　⇒取り出した20万行をテンポラリファイルに全て詰め込んでfilesort。
　⇒LIMITでテンポラリファイルの先頭からn*p行を取り出して、n行クライアントに返す。
結局、20万行スキャンしてる。

・複合インデックスを指定した後
　⇒WHERE `check` = '1'でインデックスが利く。
　　⇒仮に10万行スキャンとする。
　⇒ORDER BYでもインデックスが使える。
　　⇒10万行(=WHERE句でHITした行数)をメモリ上でソート。
　⇒LIMITでメモリ上のソート結果の先頭からn*p行だけをテーブルからフェッチして、
　　n行をクライアントに返す。

n*pが小さければ小さい程実際にテーブルからフェッチする件数が減るから速い。
n*pがレコードの全件数に近くなれば近くなるほどテーブルからフェッチする件数が
全件スキャンに近くなるから差がほとんどなくなる。

て感じ。

やっと書き込めた！お礼遅くなりごめんなさいです！
>>930
非常に丁寧に細かい説明ありがとうございます。
やっぱり遠くにあるものを取り出す時は
処理コストが掛かるのはMySQLの仕様として仕方がないんですね。
安心しました。

とりあえずこの方向性でシステム調整して行こうと思います。

例えば曲テーブルとジャンルテーブルがあって
一つの曲は複数ジャンルをもてる場合

音楽テーブルは
music_tabe
id(pk)
として、ジャンルテーブルは
music_genre_table
music_id(fk)
genre_id(pk)
と
music_genre_table
id(pk) auto_inclement
music_id
genre_id
みたいに持つのはどっちがよいですか。
音楽IDとジャンルIDで一意に特定できるので、上でもいいかと思うのですが
検索とか考えると下のほうが早いのかもと考え始めたらよく解らなくなりました。

似たようなもん作っていて（音楽データではないけど）、下の作りでやってる

>>932
上は音楽IDとジャンルIDで一意、じゃなくてジャンルIDだけで一意だがそれでいいのか？
下は音楽IDとジャンルIDでも一意じゃないがそれでいいのか？

ライセンスがよくわからんのだけど、
受託でWEBアプリケーションを納品するときって、ソース公開しないといけないの？

それとも、MySQLの派生物じゃないから公開義務は発生しないの？

>>935
俺もそんなに詳しくはないけど、
MySQL(や、その他GPLが適用されたプログラム)に含まれる
ソースコードそのものを取り込んで(改変して)いなければGPLは適用されない。

WEBアプリケーションを外部からアクセス可能にするだけでは
「再頒布」に当たらない(GPLなソフトウェアからの出力、と看做されたと思う)ので
GPLv2の再頒布にかかる規定(ソースコードの公開etc.)に従う必要はない。

ただ、客先への納品は再頒布だから、
・GPLが適用される　⇒　客先へのソースコード公開が必要
・GPLが適用されない　⇒　客先との契約次第
になる。いずれも客先への公開の問題で、世間一般に公開する必要はないはず。

>>935
「MySQLの派生物じゃない」部分だけ納品するのなら当然GPLに従う必要はない。

間違えました…ここmysqlの質問板でした。
上の質問はスルーしてください。

>>936, 937
さんきゅ。

>> 937
つーことは、MySQLのインストール作業をこっちでやらなければOKという解釈でもいいのか。

>>941
どうしても頭文字を基準にパーティショニングする必要がある？
ただ（それなりに）均等に分散すれば良いなら、KEYパーティショニングがすっきりすると思うけど。

http://dev.mysql.com/doc/refman/5.1/ja/partitioning-key.html

mysql 5.5.15

mysqldumpでバックアップする時に外部制約の関係上、テーブル単位でバックアップ
しています。

それでテーブル以外のもの、ストアドプロシージャなどは

mysqldump --routines --no-create-info --no-data --no-create-db --skip-opt hogehoge --default-character-set=cp932 -u xxxx -p > G:\Data\MySQL\fff.sql

としているんですけど、viewの定義とかはここには出てきていません。
viewの定義をバックアップする方法、教えてください。

>>948
ありがとうございます
テーブル定義と一緒にビューの定義も取れました。