私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ【MySQL】下らねぇ質問はID出して書き込みやがれ 2

みんなの評価 :
レスフィルター : (試験中)
>>903
デフォルトではそう。
オプションで
「あるDBのみレプリケーション」
「あるDBのみ除外」
「あるテーブルのみレプリケーション」
「あるテーブルのみ除外」
が設定できる。
http://dev.mysql.com/doc/refman/5.1/ja/replication-rules.html
そういえば5.5のマニュアル全然日本語化されないねぇ。
デフォルトではそう。
オプションで
「あるDBのみレプリケーション」
「あるDBのみ除外」
「あるテーブルのみレプリケーション」
「あるテーブルのみ除外」
が設定できる。
http://dev.mysql.com/doc/refman/5.1/ja/replication-rules.html
そういえば5.5のマニュアル全然日本語化されないねぇ。
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
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に戻してくれる。
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に戻してくれる。
>>916
あ、INSERT部分じゃなくて文字列をパースして分かち書きにするところまで。。
あ、INSERT部分じゃなくて文字列をパースして分かち書きにするところまで。。
>>920
レスありがとうございます。
他にも checkとpriceとか、checkとnoとか
色々な組み合わせで検索したりするんですが
それらも全部それぞれの組み合わせで
複合インデックスを作成しておいた方がいいという事でしょうか?
要するに、(`check`,`date`)、(`check`,`price`)、(`check`,`no`) とかで。
それとも全部纏めての複合インデックスの方がいいんでしょうか?
要するに、(`check`,`date`,`price`,`no`) とかで。
質問ばかりすみません。
レスありがとうございます。
他にも 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
がんばれ。
検索と更新の割合次第…としか言えないかなぁ。
インデックスは基本的に
・無駄なインデックスでも検索には基本的に影響が出ない
・有効なインデックスでも更新には常に影響が出る
ものだから、
更新が日に1回しかないのならがっつり作っちゃえば良いし、
更新が断続的に続くなら検索頻度が高い組み合わせだけで
複合インデックスを作った方が良い。
全部まとめて複合インデックスにするのは多分NG。
複合インデックスは順番どおりに使わないといけないってルールがあるから。
http://dev.mysql.com/doc/refman/5.1/ja/mysql-indexes.html
がんばれ。
>>922
あっ、書いてる間にレスしてくれてたんですね(汗)
すみません。
そうですかー、全部纏めて作るのはNGなんですか。
そうなるとやっぱり組み合わせの分だけ作った方がいいような気がしますね。
データの追加とか更新はそこまで頻繁にはないので
検索重視のシステムを構築したいと思います。
ですのでやっぱりインデックスをがっつり作っておきたいと思います。
外部ページなんかも紹介してくださってありがとうございました。
非常に参考になりました。助かりました。どうもです。
あっ、書いてる間にレスしてくれてたんですね(汗)
すみません。
そうですかー、全部纏めて作るのはNGなんですか。
そうなるとやっぱり組み合わせの分だけ作った方がいいような気がしますね。
データの追加とか更新はそこまで頻繁にはないので
検索重視のシステムを構築したいと思います。
ですのでやっぱりインデックスをがっつり作っておきたいと思います。
外部ページなんかも紹介してくださってありがとうございました。
非常に参考になりました。助かりました。どうもです。
あっカーディナリティっていうのは
checkには二通りの種類しかない=カーディナリティが2という事なんですかね。
確かにインデックス作ってもこれは効果が薄そうではありますね… う~ん。
checkには二通りの種類しかない=カーディナリティが2という事なんですかね。
確かにインデックス作ってもこれは効果が薄そうではありますね… う~ん。
>>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がレコードの全件数に近くなれば近くなるほどテーブルからフェッチする件数が
全件スキャンに近くなるから差がほとんどなくなる。
て感じ。
それは良かった!
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の仕様として仕方がないんですね。
安心しました。
とりあえずこの方向性でシステム調整して行こうと思います。
>>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で一意に特定できるので、上でもいいかと思うのですが
検索とか考えると下のほうが早いのかもと考え始めたらよく解らなくなりました。
一つの曲は複数ジャンルをもてる場合
音楽テーブルは
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で一意に特定できるので、上でもいいかと思うのですが
検索とか考えると下のほうが早いのかもと考え始めたらよく解らなくなりました。
ライセンスがよくわからんのだけど、
受託でWEBアプリケーションを納品するときって、ソース公開しないといけないの?
それとも、MySQLの派生物じゃないから公開義務は発生しないの?
受託でWEBアプリケーションを納品するときって、ソース公開しないといけないの?
それとも、MySQLの派生物じゃないから公開義務は発生しないの?
>>935
俺もそんなに詳しくはないけど、
MySQL(や、その他GPLが適用されたプログラム)に含まれる
ソースコードそのものを取り込んで(改変して)いなければGPLは適用されない。
WEBアプリケーションを外部からアクセス可能にするだけでは
「再頒布」に当たらない(GPLなソフトウェアからの出力、と看做されたと思う)ので
GPLv2の再頒布にかかる規定(ソースコードの公開etc.)に従う必要はない。
ただ、客先への納品は再頒布だから、
・GPLが適用される ⇒ 客先へのソースコード公開が必要
・GPLが適用されない ⇒ 客先との契約次第
になる。いずれも客先への公開の問題で、世間一般に公開する必要はないはず。
俺もそんなに詳しくはないけど、
MySQL(や、その他GPLが適用されたプログラム)に含まれる
ソースコードそのものを取り込んで(改変して)いなければGPLは適用されない。
WEBアプリケーションを外部からアクセス可能にするだけでは
「再頒布」に当たらない(GPLなソフトウェアからの出力、と看做されたと思う)ので
GPLv2の再頒布にかかる規定(ソースコードの公開etc.)に従う必要はない。
ただ、客先への納品は再頒布だから、
・GPLが適用される ⇒ 客先へのソースコード公開が必要
・GPLが適用されない ⇒ 客先との契約次第
になる。いずれも客先への公開の問題で、世間一般に公開する必要はないはず。
>>935
「MySQLの派生物じゃない」部分だけ納品するのなら当然GPLに従う必要はない。
「MySQLの派生物じゃない」部分だけ納品するのなら当然GPLに従う必要はない。
間違えました…ここmysqlの質問板でした。
上の質問はスルーしてください。
上の質問はスルーしてください。
>>941
どうしても頭文字を基準にパーティショニングする必要がある?
ただ(それなりに)均等に分散すれば良いなら、KEYパーティショニングがすっきりすると思うけど。
http://dev.mysql.com/doc/refman/5.1/ja/partitioning-key.html
どうしても頭文字を基準にパーティショニングする必要がある?
ただ(それなりに)均等に分散すれば良いなら、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の定義をバックアップする方法、教えてください。
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の定義をバックアップする方法、教えてください。



類似してるかもしれないスレッド
- 【】 MySQLを買収したSunを買収したOracleを 【】 (112) - [25%] - 2023/1/22 14:15
- 【この先一体】MySQL 総合 Part15【どうなるの】 (1001) - [21%] - 2009/11/22 13:31 ○
トップメニューへ / →のくす牧場書庫について