のくす牧場
コンテンツ
牧場内検索
カウンタ
総計:127,062,754人
昨日:no data人
今日:
最近の注目
人気の最安値情報

    元スレ【MySQL】下らねぇ質問はID出して書き込みやがれ 2

    mysql覧 / PC版 /
    スレッド評価: スレッド評価について
    みんなの評価 :
    タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。
    ←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitter

    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
    ありがとうございます
    テーブル定義と一緒にビューの定義も取れました。


    ←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / mysql一覧へ
    スレッド評価: スレッド評価について
    みんなの評価 :
    タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。

    類似してるかもしれないスレッド


    トップメニューへ / →のくす牧場書庫について