>>499
とりあえずOracleと同容量確保しといたら足りるよ

まあ、そりゃそうだろうねw。

Oracleってインストールめんどくせーってイメージしか無いわ。
OSのカーネルパラメータも弄ったりした覚えがある。

再起動してください。

>>508
サンクス
すごい困ってた

MySQLってストアドとかあるの？

また、OracleとかならSQL Developerを使用してストアドをデバッグ実行とかする事が

出切るんだけどMySQLにそういったデバッグ可能なIDEとかってありますか？

>>512
デバッグ出切るＩＤＥとかってありますか？

むりむり

そーいうＩＤＥを作ったら売れるかな？

あんまり売れないんじゃないかなあ

DBをインポートしたら、collationがlatin1_swedish_ciに設定されてしまうんだが、
一括してutf8_general_ciに変更する方法って無いかな？

２ｃｈで質問するしか能の無い奴には無理 >>517

>>518
で、おまえにゃできるの？　できるかできないかだけでいいからレスしてくれ。
やり方は別にいい。自分で調べる。

www

>>519
俺は出切る。お前のおつむじゃ無理だがなｗｗｗ

できないわけないよねー

環境系？の質問って答えづらい。

自環境の状況、書かないやつは、もちろん
事細かに書くやつも、逆になんでそれで直らんの？と思うし。
チェック漏れとか、こっちにはわからんしなぁ

がんばって自分で解決するしかないよ。

InnoDBの主キーって、クラスタインデックスで、リーフブロックにテーブルのレコードをすべて持つって聞きました。
ということは、主キーのサイズはテーブルのサイズより大きくなるんでしょうか。

これだろ。
http://thinkit.co.jp/cert/article/0608/1/2/3.htm
それがテーブルそのものなわけだ。

まったく...驚いちゃうよな
未だに「MySQLはおもちゃ」なんて戯言を恥ずかしげもなく口にしちゃう脂ぎったオヤジどもがこの世に数多存在するってんだから

世に存在する全てのデータはMySQLをもって管理される
世に生まれる全ての創造物はMySQLに収納される
これが何を意味するかわかるかい？

これから生まれる全てのものがMySQLそのものだってことだよ

まあ確かに禅問答だって言われれば否定はできないな
でも考えてみなよ君の名前はどこにある？どこかのサーバーのどこかのディレクトリにインストールされたMySQLの中だろう
MySQLに名前が存在しない人間など存在しない　生後間もない赤ん坊は別として

名前がMySQLにあるってことはだ...うんそうそう、そうなんだ、聡明な君ならもう分かったと思う
名前があればそこに君が「在る」んだよ
君の存在はそこに「在る」んだ
だからそれはつまりこういうことだ

------ペニーオークションは詐欺じゃない

mysql開発のお勧めツール教えて欲しい

なんだこいつ

超初歩的な事を聞いて申し訳ないんですが、最近レコード数が多くなってきて検索が遅くなってきており
インデックスを利用したら早くなるというのを知りました。
しかし、いくつかの例を見てもインデックスはテーブルを作成する段階で作るのが普通のようで、自分のケースの様に
だいぶレコードが増えてしまってから、インデックスを導入するという事は難しいのでしょうか？

＞インデックスを利用したら早くなるというのを知りました。
どんだけ馬鹿なんだよ

僕もそう教わりましたよ

禁書目録のことでしょうか？

インデペンデンス

>>530
>だいぶレコードが増えてしまってから、インデックスを導入するという事は難しいのでしょうか？

MySQLに対して「インデックス作れ」というコマンドを与えるのは簡単。
やり方はcreate index なり alter table なりでぐぐればよろし。

しかし、何をインデックスにするか適切なカラムを選べるかどうかとか、
そういうこと考えてなかったとすれば、もしかしたら適切なカラムが無い
ようなテーブルだったりの可能性も皆無じゃないし、その点が大丈夫
でもレコード数がちょー多かったら、インデックス作成にはけっこう
時間かかったり。

とかで、簡単な作業とは言い切れない。
でもあっさり済んだりして。

>>525
ありがとうございます。
なるほど、テーブルと主キーのインデックスが一体化しているんですね。

InnoDBのテーブルに対して、LOAD DATA LOCAL INFILEで大量のデータをロードする場合、
下記の1.と2.では、一般的に2.のほうが作業時間が短くてすむのでしょうか。

1.既存のテーブルに対してそのままロードする。
2.一旦既存テーブルのセカンダリインデックスを削除して、ロードして、セカンダリインデックスを再作成する。

なんで「セカンダリ」インデックス限定?

とりあえず、loadするデータがユニーク制約や外部制約に触れないものと判っていたら、
既存テーブルそのままよりはload前にそれらの制約外しておいた方がいいよ。

where句にanyを使って副問い合わせしているのですが、
処理に非常に時間がかかってしまっています。
何かいい対策はありますでしょうか
インデックスなどMySQLのメンテの問題でしょうか

sqlを簡略的に書くと以下のようなものなのですが

select CODE,NAME from TBL1 where aaa = 'AA' and CODE = any (select CODE from TBL2 where bbb = 'BB' and ccc = 'CC' group by CODE)

TBL1は約2,500件
TBL2は約390,000件

わかりにくいかもしれませんが
よろしくお願いします。

> 541
早々に有難う御座います
今夜帰ったら試したいと思います
またｶｷｺします

ご意見聞かせて頂きたいのですが、
大カテゴリ、中カテゴリ、商品

以上のテーブルがあった場合、
商品テーブルに、大カテゴリと中カテゴリのリレーションを持たせるべきでしょうか？

大カテゴリに含まれる中カテゴリ内の商品を全て取得したい要件があります。

それとも、商品テーブルには、中カテゴリのリレーションのみを持たせ、
大カテゴリ、中カテゴリ、商品と連なったリレーションを利用すべきでしょうか？

商品テーブルにはカテゴリ持たせずに、
陳列テーブルに大・中・商品を入れる。
ホーム・キッチン用品でも、アウトドア用品に含まれるモノもあるだろうし。

MySQLテーブル上に VARCHAR（100）　と定義している項目に

あいうえお　　・・・　１０バイト

と登録した場合、90バイト分は常に確保されてしまっているのでしょうか？
oracleとかなら大目に定義したとしても自然に使用されていない部分は
端折られたと思うのですが如何でしょうか？

>>545
あまり詳しくないけど、
varcharは可変長だから端折られる。内容量+アルファ程度だったかな。
固定長なcharなら確保されてるかと。
ちなみに、mysql5.0からだったか、varchar(100)は100バイトじゃなく100文字になった。

マニュアル読んでから質問しようぜ

>>546
ありがとうございます。

無駄に容量を食っていたんじゃないかと
あせってました。

>> 538 >>539
ありがとうございます。

> なんで「セカンダリ」インデックス限定?
主キーは残してそれ以外は削除する、という意図でした。
主キーまで削除してしまうと、暗黙の主キーが設定されるらしいので、
それを避けたいと思いました。