[Tep-j-general] Re: データベースの容量が大きくなったら・・・

アーカイブの一覧に戻る

しょうじ kuriy****@takum*****
2006年 1月 17日 (火) 08:59:19 JST


はまださん ありがとうございます。
ご指摘のとおり、昨日、その辺を色々と調べてみました。
結構苦労しました^^;
勉強不足を痛感しつつ、わかったことは、はまださんが言われていた中にもありまし
た、クエリの発行回数が多いというものでした。

admin/orders.php を事務処理を円滑にするため、いろいろと改良しているのです
が、ソースを見るとクエリの発行回数はかなりのものでした。

他にも原因があるかもしれませんので、はまださんにご指摘いただいた部分を(過去
のメーリングリストを振り返ってw)調べてみます。

大変参考になりました。
ありがとうございました。



----- Original Message ----- 
From: "hamada" <bungu****@leo*****>
To: <tep-j****@lists*****>
Sent: Tuesday, January 17, 2006 8:41 AM
Subject: [Tep-j-general] Re: データベースの容量が大きくなったら・・・


>
> こんにちわ。

>
> > どうして遅いんだろう・・・
>
> とりあえず、my.cnfの[mysqld]下に
>
> set-variable = long_query_time=1
> set-variable = log-slow-queries=slow.log
>
> とか追記してプロセスを再起動し、スロークエリを抽出する事から始めるのが常
> 道かと思います。
>
> まずshow variablesで設定値を確認し、show statusで動作状況を確認し、スロー
> クエリを特定してexplainで問題のクエリの動作状況を調べ、なにが足りないの
> かを調べて足りないものを足す、というのが基本パターン。
>
> そもそも、現状のサーバスペック、特に実メモリの量と、mysqldプロセスに設定
> されてるkey_buffer_size、およびtable_cacheの値は幾らなんでしょう?
>
> MySQL4.xなら(他の方からもお話し出てますが)クエリキャッシュを有効にする
> 手もあります。この辺は過去ログを見てもらえば良いと思うので、繰り返しませ
> ん。チューニングのドロ沼に踏み込むのは、もう沢山(^_^;)
>
> > 以前、トップページに複数のランキングを表示していた時に、トップページの表
示が
> > 遅かったことがありました。
>
> 上記記述だけでは『遅い』原因が本当にDBなのか、それともそれ以外に原因があ
> るのかを判別出来ませんが、DBが『遅い』原因だとすれば
>
> A. クエリそのものが重い(=スロークエリ)
> B. クエリの発行回数が多い
>
> のどちらかが原因なことが多いんじゃないでしょか?
>
> Aが原因だとすれば
>
> A1 プロセス変数(my.cnf)のチューニング
> A2 インデックス等データベースのチューニング
> A3 データベースサーバの強化
>
> 等が主な対策かと思われますが、まずは現状、つまり「どこの何がどうボトルネッ
> クになっているのか」を把握するのが先決かと。
>
> はまだ
>
> _______________________________________________
> Tep-j-general mailing list
> Tep-j****@lists*****
> http://lists.sourceforge.jp/mailman/listinfo/tep-j-general
>
>




Tep-j-general メーリングリストの案内
アーカイブの一覧に戻る