元スレ【MySQL】下らねぇ質問はID出して書き込みやがれ 2
mysql覧 / PC版 /みんなの評価 :
904 = :
>>903
デフォルトではそう。
オプションで
「あるDBのみレプリケーション」
「あるDBのみ除外」
「あるテーブルのみレプリケーション」
「あるテーブルのみ除外」
が設定できる。
http://dev.mysql.com/doc/refman/5.1/ja/replication-rules.html
そういえば5.5のマニュアル全然日本語化されないねぇ。
912 = :
>>904
>そういえば5.5のマニュアル全然日本語化されないねぇ。
オレはとっくにあきらめてる。orz
5.6では、正式リリースと同時とか
期待してるんだぜ。
915 = :
>>914
ストアドファンクションでできるよ。
空白の制御とか細かいところ作ってないけど、
20文字くらいを処理させるのに大体1ミリ秒弱だった。
921 = :
>>920
レスありがとうございます。
他にも checkとpriceとか、checkとnoとか
色々な組み合わせで検索したりするんですが
それらも全部それぞれの組み合わせで
複合インデックスを作成しておいた方がいいという事でしょうか?
要するに、(`check`,`date`)、(`check`,`price`)、(`check`,`no`) とかで。
それとも全部纏めての複合インデックスの方がいいんでしょうか?
要するに、(`check`,`date`,`price`,`no`) とかで。
質問ばかりすみません。
922 = :
>>921
検索と更新の割合次第…としか言えないかなぁ。
インデックスは基本的に
・無駄なインデックスでも検索には基本的に影響が出ない
・有効なインデックスでも更新には常に影響が出る
ものだから、
更新が日に1回しかないのならがっつり作っちゃえば良いし、
更新が断続的に続くなら検索頻度が高い組み合わせだけで
複合インデックスを作った方が良い。
全部まとめて複合インデックスにするのは多分NG。
複合インデックスは順番どおりに使わないといけないってルールがあるから。
http://dev.mysql.com/doc/refman/5.1/ja/mysql-indexes.html
がんばれ。
924 = :
>>923
`check`のカーディナリティが2だから、
複合インデックスにしてもORDER BY分しか速くならないからね。。
残しておくかどうかの基準は>>922といっしょ。
本気で見極めるなら、検索と更新のターンアラウンドタイムを取って確かめるしかない。
925 = :
>>922
あっ、書いてる間にレスしてくれてたんですね(汗)
すみません。
そうですかー、全部纏めて作るのはNGなんですか。
そうなるとやっぱり組み合わせの分だけ作った方がいいような気がしますね。
データの追加とか更新はそこまで頻繁にはないので
検索重視のシステムを構築したいと思います。
ですのでやっぱりインデックスをがっつり作っておきたいと思います。
外部ページなんかも紹介してくださってありがとうございました。
非常に参考になりました。助かりました。どうもです。
927 = :
あっカーディナリティっていうのは
checkには二通りの種類しかない=カーディナリティが2という事なんですかね。
確かにインデックス作ってもこれは効果が薄そうではありますね… う~ん。
931 = :
やっと書き込めた!お礼遅くなりごめんなさいです!
>>930
非常に丁寧に細かい説明ありがとうございます。
やっぱり遠くにあるものを取り出す時は
処理コストが掛かるのはMySQLの仕様として仕方がないんですね。
安心しました。
とりあえずこの方向性でシステム調整して行こうと思います。
933 = :
似たようなもん作っていて(音楽データではないけど)、下の作りでやってる
934 = :
>>932
上は音楽IDとジャンルIDで一意、じゃなくてジャンルIDだけで一意だがそれでいいのか?
下は音楽IDとジャンルIDでも一意じゃないがそれでいいのか?
935 :
ライセンスがよくわからんのだけど、
受託でWEBアプリケーションを納品するときって、ソース公開しないといけないの?
それとも、MySQLの派生物じゃないから公開義務は発生しないの?
936 = :
>>935
俺もそんなに詳しくはないけど、
MySQL(や、その他GPLが適用されたプログラム)に含まれる
ソースコードそのものを取り込んで(改変して)いなければGPLは適用されない。
WEBアプリケーションを外部からアクセス可能にするだけでは
「再頒布」に当たらない(GPLなソフトウェアからの出力、と看做されたと思う)ので
GPLv2の再頒布にかかる規定(ソースコードの公開etc.)に従う必要はない。
ただ、客先への納品は再頒布だから、
・GPLが適用される ⇒ 客先へのソースコード公開が必要
・GPLが適用されない ⇒ 客先との契約次第
になる。いずれも客先への公開の問題で、世間一般に公開する必要はないはず。
937 = :
>>935
「MySQLの派生物じゃない」部分だけ納品するのなら当然GPLに従う必要はない。
942 = :
>>941
どうしても頭文字を基準にパーティショニングする必要がある?
ただ(それなりに)均等に分散すれば良いなら、KEYパーティショニングがすっきりすると思うけど。
http://dev.mysql.com/doc/refman/5.1/ja/partitioning-key.html
949 = :
>>948
ありがとうございます
テーブル定義と一緒にビューの定義も取れました。
みんなの評価 :
類似してるかもしれないスレッド
- 【】 MySQLを買収したSunを買収したOracleを 【】 (112) - [25%] - 2023/1/22 14:15
- 【この先一体】MySQL 総合 Part15【どうなるの】 (1001) - [21%] - 2009/11/22 13:31 ○
トップメニューへ / →のくす牧場書庫について