元スレMySQL 総合 Part12

mysql覧

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで

703 = :

>>697-698
ありがとう　試してみます

704 :

http://click.j-a-net.jp/1006827/223686/

710 = :

ありがとうございます。
早速変更して様子をみたいと思います。
思ったより、スパムの接続数が多いみたいです。

712 :

すいません。バカな漏れをすくってください。
以前、MySQLをインストールして、失敗し、やむなく消去して。
XAMPPをいれたんですけど。
MｙSQLにつなぐと。
access violation なんちゃら～libmysql.dll～なんちゃら
と、何回もエラーがでて、そのうち操作不能になります。
コマンドでsc delete MySQLとかやってみたり、
管理ツールとかもしてみたんですが、
なおりません。
ともだちに聞いたら、クリーンインストールしかないんじゃない
とのことなんですが。
ちょっと消しちゃまずいものもあったりするんで。
バックアップに不安感もあって、ふみきれません。
どうか、たすけてください。

あと、5日前くらいからはじめたばかりなので。
初心者すぎて、書いてることも、自分でもよくわかりきってないんで。
そのへん、ほんとうに、すみません。

713 = :

窓からパソコン投げれば良いと思う

714 = 712 :

>>713
そうとうそういう衝動おさえてますｗｗ

715 = :

親切な自分がいい方法を教えてあげよう。
お年玉で新しいPCを買え（w

716 = 712 :

>>715
ききたくなかったｗｗｗｗ
そのもっとも正論を、ききたくなかったｗｗ

718 :

http://click.j-a-net.jp/1006827/223692/

720 :

>>717さん。
本当に感謝します。
今、ガチで地面に頭つけて土下座しました。
これは、完全に本当です。ありがとうございます。
そして>>718さん。
すかさずのジョーク、笑わせていただきました。
ありがとうございます。

722 = :

そもそもの設計が間違ってるんじゃね？　としかいいようがない。
EXPLAINしてみた？

ちなみにインデックス張ってると更新は重くなるよ。

725 = :

SQLの勉強しろよ。
IN を使えばいいでしょ。

726 = :

複数のカラムでOrder Byするとインデックスが無視されてしまいますが
どうやったって複数の項目でソートせざるを得ないときはどうしますか？

単純な数値のキー二つなら足したりかけたりして一つのカラムに
まとめたりすることも出来ますが、日時と数字だったりすると
相当面倒くさいです。ソートだけに。

728 = :

>>725
すみません。勉強不足でした。
INで出来ました。ありがとうございました。

730 = :

>>729
参照主体ならレプリケーションでも十分対応できるんじゃね？
更新主体だとそうもいかんけど。

5.1使うとその辺楽できていいよね。

731 = :

>>722>>723 >>729>>730
アドバイスどうもありがとうございました。
EXPLAINで最適化をしたのですが、どうしてもスピードが劣化してしまします。
このペースで1000万件良くと大変なことになりそうなので、策を考えていました。

>>729さんに教えて頂いたパーティション初耳だったのですが、マニュアルを見たらすごく便利ですね。
私は同じテーブルを複製してPGで参照テーブルを決定することを考えていたのですが、
DB側で透過的に負荷分散してくれるこのやり方は最高です。

いま問題になっているのは、会員の購入履歴みたいなもので、会員IDと購入品目などが並んでいます。
会員IDにINDEXを指定していて、会員IDをキーに購入履歴を参照しています。(実際には条件がもう少し複雑です)

このような用途で、会員別にパーティションにしたいのですが、
その場合は、「15.2.3. HASH 分割」がベストということで宜しいでしょうか？
http://dev.mysql.com/doc/refman/5.1/ja/partitioning-hash.html

732 = :

>>730
アドバイスありがとうございました。
>参照主体ならレプリケーションでも十分対応できるんじゃね？
残念ながら両方なんです。
参照もしながら更新もするテーブルでして、参照も更新も半々で、
それでいてデータ数も2年後には1000万件いく勢いなので・・・

733 = :

>>731
思うんだけど、購入履歴は「過去○件まで」として
それ以上は削除したら良いんじゃないか？
で、購入履歴からこれまでの注文金額を割り出しているのなら
それを止めて、購入合計金額テーブル+購入履歴にするとか。

俺はそうしてるよ。じゃないと、履歴のログがたまりすぎる。

734 = :

>>733
返事ありがとうございます。
そうですね、確かにそうしたいのですが、そのテーブルが過去の取引記録を修正する必要がある特殊なもので、
更にその取引履歴がないと他の処理の際に非常に困るケースがありまして、
そのテーブルを今の形以上に最適化？するのが難しいんです。

なので、将来的にそれが1億件とか溜まったらどうするの？って問題もあるのですが、
それに対応するのは、同じ構造のテーブルを複製して負荷分散するしかないのかなぁ、と思ったのが最初の考えだったんです。

735 = :

>>734
例え1億件溜まったとしても、それに全件対象で
検索なんてまずしないでしょうし、回避方法いくらでもあるでしょう。
しかもその９割以上はもう更新されない固定データのはずです。

737 = :

最適化云々の前に、どう考えても設計にミスがあると思うんだが・・。
mixiほどの会員数でもないだろうし。せいぜい1万人前後だろ。

738 = :

単位は人じゃないと思う

739 = :

>>731
まいったな。
5.1新機能の『水平パーティショニング』じゃなくて、MySQLサーバ複数に
同じテーブル用意して、プログラムで参照先を変える、
手動(?)水平パーティショニングのつもりで書いた。
その場合、ユーザテーブルにデータクラスタidのカラムを増やすことになる。
736の言うように、5.1はまだRC1だからなぁ。

>>737
会員数じゃない。

745 = :

>>744
>>675

749 = :

>>748
「うまく動きません」の内容を詳しく。

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / mysql一覧へ

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

• MySQL 総合 Part13 (996) - [94%] - 2008/6/10 21:02 ☆
• MySQL 総合 Part19 (982) - [94%] - 2011/6/9 2:33
• MySQL 総合 Part14 (1001) - [94%] - 2008/11/23 10:17 ☆
• MySQL 総合 Part15 (1001) - [94%] - 2009/4/20 12:15 ☆
• MySQL 総合 Part17 (1001) - [94%] - 2010/6/10 20:47 ○
• MySQL 総合 Part18 (986) - [94%] - 2011/1/17 15:46
• MySQL 総合 Part22 (1001) - [94%] - 2012/7/10 16:45
• MySQL 総合 Part23 (992) - [89%] - 2013/8/11 17:00
• MySQL 総合 Part26 (860) - [89%] - 2023/2/2 9:30
• MySQL 総合 Part21 (1001) - [89%] - 2011/12/25 22:16
• MySQL 総合 Part20 (995) - [89%] - 2011/10/17 4:48
• MySQL 総合 Part24 (1010) - [89%] - 2015/2/14 4:46
• MySQL 総合 Part25 (947) - [89%] - 2017/6/18 6:30
• MySQL vs PostgreSQL Part2 (941) - [36%] - 2022/5/26 1:30 ○