しょうじ
kuriy****@takum*****
2006年 1月 17日 (火) 08:59:19 JST
はまださん ありがとうございます。 ご指摘のとおり、昨日、その辺を色々と調べてみました。 結構苦労しました^^; 勉強不足を痛感しつつ、わかったことは、はまださんが言われていた中にもありまし た、クエリの発行回数が多いというものでした。 admin/orders.php を事務処理を円滑にするため、いろいろと改良しているのです が、ソースを見るとクエリの発行回数はかなりのものでした。 他にも原因があるかもしれませんので、はまださんにご指摘いただいた部分を（過去 のメーリングリストを振り返ってｗ）調べてみます。 大変参考になりました。 ありがとうございました。 ----- 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 > >
