元スレMySQL 総合 Part12
mysql覧 / PC版 / みんなの評価 : ○
前へ
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 = :
749 = :
>>748
「うまく動きません」の内容を詳しく。
みんなの評価 : ○
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 ○
トップメニューへ / →のくす牧場書庫について