こんにちは。

とみたまさひろ <tommy@xxxxxxxxxx>さんの
<20040612210209.724deab0.tommy@xxxxxxxxxx>
"[mysql 09609] Re: ACCESS97 ODBC接続のパフォーマンス"


> サーバスペックの話の前に、MySQL 的なところから調べてみてはどうでしょうか。
> 
> mysqld に --log オプションをつけて(または my.cnf に log と書いて)、
> クエリログを取り、実際にどのようなクエリが発行されているかを確認して、
> EXPLAIN でそのクエリがインデックスを効率的に使用しているか調べてみるとか。

　ですね。

　２万件程度のレコード数ならマシンスペックが「 MySQLは激遅だぁ！」の理由と
はならないかも、ですね。Xとかのリソースを馬鹿食いするAPを動かしていて、
それが手枷足枷になっているなら話は別です。KDE3.2.3を今日入れたのですが、
XとKDEで150MB程度喰ってますね。

　ともあれ、テーブル定義や出しているSQL文を提示してみてはどうでしょう。
パフォーマンス上の問題は、マシンスペックよりも不適切なテーブル定義や
SQL文によるものが多いですから。>津川さん



　津川さんの「C/Sにするとパフォーマンスがあがるかな？と期待していた分シ
ョックです」ですけど、確かにその様な期待を持つ人は多いです。ですが、そう
は問屋が卸さない（簡単には卸して呉れない）のが現実です。

　ですが、スタンドアローンだろうがサーバだろうがやる事は一緒なのですから、
マシンのパフォーマンスが同じなら同じだけの時間が掛かります。また、クライ
アント/サーバのモデルでは、通信というコストが普通掛かりますし、処理がサー
バに集中する事になります。

　サーバとクライアントで処理の分散が出来れば全体のパフォーマンスが上がる
事は考えられます。が、サーバに処理を丸投げする形 (津川さんのシステムもこ
れに近いのでしょうか？丸投げの典型例にはWebベースのアプリケーションサー
バがあります)であれば、コストや処理負荷の集中によってパフォーマンスは逆
に下がってしまう事は十分にあり得る（非常にありがちな）事です。


　　　　松枝知直　　　　<tomom@xxxxxxxxxx>
　　　　　　　　　　　　http://www.argus.ne.jp/~tomom/