LAMP システムを調整する: 第 3 回 MySQL サーバーを調整する

サーバー調整のヒントで MySQL サーバーを飛躍させる

LAMP (Linux®、Apache、MySQL、PHP/Perl) アーキテクチャーを使ったアプリケーションは次々と開発され、デプロイされています。しかし多くの場合、アプリケーションはサーバー管理者以外の人が作成したものであるため、サーバー管理者はアプリケーション自体をほとんど制御することができません。この 3 回シリーズの記事では、アプリケーションのパフォーマンスを向上させる、あるいは低下させる、サーバー構成上のさまざまな項目について説明します。シリーズ最終回の今回は、最大の効率を実現するためにデータベース・レイヤーを調整する方法について説明します。

Sean A. Walberg (sean@ertw.com), Senior Network Engineer

Photo of Sean WalbergSean Walberg は 1994年以来、学術や企業の環境で、またインターネット・サービス・プロバイダー環境で、Linux と UNIX に取り組んできています。彼は過去数年間、システム管理に関して幅広い執筆を行ってきました。



2007年 6月 07日

MySQL の調整について

MySQL サーバーを高速にするためには 3 つのことを行うことができます。それらを効果の低いものから高い順に並べると、以下のようになります。

  1. 問題の場所にハードウェアを投入する
  2. MySQL プロセスの設定を調整する
  3. クエリーを最適化する

DB2 へのマイグレーション

MySQL から IBM® DB2® への、わかりやすくてコストのかからないマイグレーション方法を探している方は、「Migrate from MySQL or PostgreSQL to DB2 Express-C」の記事を読み、そこで提供されているマイグレーション・ツールを使うと、容易にマイグレーションを行うことができます。無料の DB2 Express-C をダウンロードし、今すぐに DB2 を使い始めてください。

多くの場合、最初に考えるのは問題の場所にハードウェアを投入することです。データベースはリソースを大量に使用するため、なおさらです。ただしこのソリューションの効果は今までと変わりありません。実際には、通常 CPU (central processing unit) あるいはディスクのスピードを 2 倍にしたり、メモリーを 4 倍から 8 倍にしたりする程度です。

最高の方法に次いで効果のある方法は、MySQL サーバー (mysqld とも呼ばれます) を調整する方法です。プロセスを調整するということは、メモリーを適切な場所に割り当て、そしてどんな種類の負荷を想定するかを mysqld に伝えるということです。ディスクを高速にするよりも、必要なディスク・アクセス数を減らした方が効果的です。同様に、MySQL プロセスが適切に動作している状態を確実にするということは、MySQL プロセスが、クエリーの処理にたくさんの時間を費やすことができ、一時ディスク・テーブルを扱うようなバックグラウンド・タスクの処理や、ファイルを開いたり閉じたりといった処理には、あまり時間を使わずに済むということです。この記事では、mysqld の調整に焦点を当てて説明します。

mysqld の調整として最も効果があるのは、クエリーを最適化することです。これはつまり、適切な索引をテーブルに適用すること、また MySQL の能力を活用できる方法でクエリーを作成する、ということです。この記事ではクエリーの調整については説明しません (クエリーの調整については何冊もの本が書かれています) が、調整が必要かもしれないクエリーをレポートするように mysqld を構成する方法を説明します。

このような作業に優先順位が付けられているからといって、ハードウェアや mysqld の設定を無視してクエリーを適切に調整すればよいというわけではありません。遅いマシンは遅いマシンであり、適切に作成されたクエリーを高速なマシンで使用しても、クエリーの処理ではなくビジーな作業のために mysqld が使われてしまい、高負荷時に障害を起こすのを私は見たことがあります。


スロー・クエリーのログを取る

SQL サーバーでは、データ・テーブルはディスク上にあります。サーバーは索引によって、テーブル全体を検索することなく、テーブル内の特定のデータ行を見つけることができます。テーブル全体の検索が必要な場合、その検索はテーブル・スキャンと呼ばれます。ほとんどの場合、必要なものはテーブルの中のデータの、ごく小さなサブセットのみであるため、完全なテーブル・スキャンは大量のディスク I/O を浪費し、従って時間を浪費します。この問題は、データの連結が必要な場合にはさらに悪化します。連結されるデータ同士の間で、さらに多くの行を比較しなければならないからです。

もちろん、テーブル・スキャンが必ずしも問題であるとは限りません。場合によると、テーブルの中から必要なものを探し出すよりも、テーブル全体を読み取った方が効率的です (こうした判断を下すのは、サーバー・プロセスでのクエリー・プランナーの作業です)。非効率的な索引の使い方をしていたり、あるいはまったく索引を使用できなかったりすると、クエリーの実行速度は遅くなります。そしてこの問題は、サーバーに対する負荷やテーブルのサイズが増加するにつれ、一層顕著になります。指定された時間よりも実行時間を長く必要とするクエリーは、スロー・クエリーと呼ばれます。

スロー・クエリーのログをスロー・クエリー・ログという適切な名前の付いたログとして記録するように mysqld を構成すると、管理者はこのログを調べることで、アプリケーションのどの部分を詳しく調べればよいか判断することができます。リスト 1 はスロー・クエリー・ログを有効にするために my.cnf の中で必要な構成を示しています。

リスト 1. MySQL のスロー・クエリー・ログを有効にする
[mysqld]
; enable the slow query log, default 10 seconds
log-slow-queries
; log queries taking longer than 5 seconds
long_query_time = 5
; log queries that don't use indexes even if they take less than long_query_time
; MySQL 4.1 and newer only
log-queries-not-using-indexes

この 3 つの設定を一緒に使うと、5 秒以上かかるすべてのクエリーと、索引を使わないすべてのクエリーをログに記録することができます。log-queries-not-using-indexes に関する注意点として、MySQL 4.1、あるいはそれよりも新しいバージョンの MySQL が必要です。スロー・クエリー・ログは MySQL のデータ・ディレクトリーの中にあり、(ホスト名)-slow.log という名前が付けられています。別の名前またはパスを使用したい場合には、my.cnf の中で log-slow-queries = /new/path/to/file のようにします。

スロー・クエリー・ログを読み出すための最適な方法は mysqldumpslow コマンドを使う方法です。このログファイルへのパスを指定すると、ソートされたスロー・クエリーのリストと、それらのスロー・クエリーがログに記録されている回数を得ることができます。mysqldumpslow の便利な機能の 1 つは、ユーザーが指定したデータを削除してから結果を照合するため、同じクエリーをさまざまに呼び出しても 1 つとしてカウントされます。これは最も作業が必要なクエリーを見つける上で役立ちます。


クエリーをキャッシュする

多くの LAMP アプリケーションはデータベースに大きく依存していますが、同じクエリーを何度も繰り返し行います。クエリーが実行されるたびに、データベースは同じ作業を行わなければなりません (つまりクエリーを解析し、その実行方法を決定し、ディスクから情報をロードし、その情報をクライアントに返します)。MySQL にはクエリー・キャッシュと呼ばれる機能があり、クエリーの結果が再度必要な時のために、その結果をメモリーに保存します。多くの場合、これによってパフォーマンスを劇的に向上させることができます。ただし注意する点として、クエリー・キャッシュはデフォルトで無効になっています。

query_cache_size = 32M を /etc/my.conf に追加すると、32MB のクエリー・キャッシュを有効にすることができます。

クエリー・キャッシュを監視する

クエリー・キャッシュを有効にしたら、そのキャッシュが効果的に使われているかどうかを理解することが重要です。MySQL には、キャッシュの中の様子を調べるための、いくつかの変数があります。リスト 2 はキャッシュの状態を示しています。

リスト 2. クエリー・キャッシュの統計を表示する
mysql> SHOW STATUS LIKE 'qcache%';
+-------------------------+------------+
| Variable_name           | Value      |
+-------------------------+------------+
| Qcache_free_blocks      | 5216       |
| Qcache_free_memory      | 14640664   |
| Qcache_hits             | 2581646882 |
| Qcache_inserts          | 360210964  |
| Qcache_lowmem_prunes    | 281680433  |
| Qcache_not_cached       | 79740667   |
| Qcache_queries_in_cache | 16927      |
| Qcache_total_blocks     | 47042      |
+-------------------------+------------+
8 rows in set (0.00 sec)

これらの項目の詳細を表 1 に示します。

表 1. MySQL のクエリー・キャッシュの変数
変数名説明
Qcache_free_blocksキャッシュの中にある連続したメモリー・ブロックの数を表します。この値が大きいと、キャッシュの断片化が起きていることを示します。FLUSH QUERY CACHE はキャッシュのデフラグを行い 1 つのフリー・ブロックのみにします。
Qcache_free_memoryキャッシュ内の空きメモリー容量を表します。
Qcache_hitsキャッシュにあるクエリーが使われるたびにインクリメントされます。
Qcache_insertsクエリーが挿入されるたびにインクリメントされます。挿入された回数をヒット数で割るとミス・レートが得られ、1 からミス・レートの値を引くとヒット・レートが得られます。先ほどの例では、約 87% のクエリーがキャッシュから提供されています。
Qcache_lowmem_prunesキャッシュがメモリー不足になり、さらにクエリーをキャッシュするためにクリーンアップしなければならなかった回数を表します。この値は時間の経過に伴う変化を調べるのが適切です。この値が増加している場合は、断片化が深刻であるか、あるいはメモリーが不足している兆候です (上記の free_blocks と free_memory でその状況を知ることができます)。
Qcache_not_cachedキャッシュの候補にならなかったクエリーの数 (通常はクエリーが SELECT 文ではなかったために候補にならなかったクエリーの数) を表します。
Qcache_queries_in_cache現在キャッシュされているクエリー (とレスポンス) の数を表します。
Qcache_total_blocksキャッシュの中にあるブロックの数を表します。

多くの場合、これらの変数を何秒かの間隔で表示すると変化がわかるため、キャッシュが効果的に使われているかどうかをその変化から判断することができます。FLUSH STATUS を実行すると一部のカウンターがリセットされます。これはサーバーがしばらく前から実行している場合のリセット用として便利です。

クエリー・キャッシュの大きさは、すべてをキャッシュしようとして過度に大きくしがちです。mysqld はキャッシュに対するメンテナンスを行う (メモリーが不足してきた場合にプルーニングを行うなど) 必要があるため、キャッシュを管理しようとしてサーバーの動作が遅くなる可能性があります。一般的なルールとして、FLUSH QUERY CACHE に長い時間がかかるようであれば、そのキャッシュは大きすぎます。


制限を設定する

システム負荷によってリソースの枯渇が起こらないように、いくつかの制限を mysqld の中で設定する必要があります。リスト 3 は、my.cnf での、リソースに関連する重要な設定のいくつかを示しています。

リスト 3. MySQL のリソース設定
set-variable=max_connections=500
set-variable=wait_timeout=10
max_connect_errors = 100

1 行目では最大接続数が指定されています。Apache の MaxClients の場合と同様、最大接続数の考え方は、処理することが可能な接続数の範囲でのみ接続を許可することです。これまでサーバーで観察された最大接続数の情報を得るためには、SHOW STATUS LIKE 'max_used_connections' を実行します。

2 行目は、10 秒以上アイドル状態であったすべての接続を終了するように mysqld に指示されます。通常、LAMP アプリケーションでのデータベースへの接続は、Web サーバーがリクエストを処理するために必要な期間にのみ存在します。場合によると、負荷のある状態で接続が継続し、接続テーブルのスペースを占有してしまうことがあります。対話型のユーザーが多い場合、あるいはデータベースに対して永続的な接続を使用する場合には、この値を低く設定することは賢明ではありません。

最後の行は安全策です。もしホストとサーバーとの接続に問題があり、ホストがリクエストの処理をアボートする回数が多すぎる場合には、FLUSH HOSTS が実行されるまでホストはロックされます。デフォルトでは、10 回も失敗すればブロックされる条件としては十分です。この値を 100 に変更すると、サーバーにはどのような問題からも回復できるだけの十分な時間が与えられます。この値を大きくしても、あまり効果はありません。もしサーバーが 100 回試行しても 1 度も接続できないのであれば、まったく接続できない可能性が高いからです。


バッファーとキャッシュ

MySQL には、100 項目をはるかに超える調整可能な設定があります。しかし幸いなことに、そのごく一部をマスターすれば、必要なことのほとんどに対応することができます。こうした設定の適切な値を見つけるためには、SHOW STATUS コマンドを使ってステータス変数を調べ、その結果を基に、mysqld が期待どおり動作しているかどうかを判断します。システムに存在する以上のメモリーをバッファーとキャッシュに割り当てることはできないため、調整は多くの場合、妥協を伴います。

MySQL の調整可能項目は、mysqld プロセス全体、あるいは個々のクライアント・セッションのいずれかに適用されます。

サーバー全体に渡る設定

各テーブルはディスク上のファイルとして表現され、テーブルを読み取るためには、まずそのテーブルを開く必要があります。ファイルからの読み取りプロセスを高速にするため、mysqld はこれらの開いたファイルを、/etc/mysqld.conf の中の table_cache によって指定される限界までキャッシュします。リスト 4 は、テーブルを開く動作に関連するアクティビティーの表示方法を示しています。

リスト 4. テーブルを開くアクティビティーを表示する
mysql> SHOW STATUS LIKE 'open%tables';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Open_tables   | 5000  |
| Opened_tables | 195   |
+---------------+-------+
2 rows in set (0.00 sec)

リスト 4 は、5,000 のテーブルが現在開いていること、そしてファイル記述子がキャッシュの中になかったため 195 のテーブルを開く必要があったことを示しています (この統計は先ほどクリアーされたので、オープン動作の履歴が 195 のみで 5,000 のテーブルがオープンしていても不自然ではありません)。SHOW STATUS コマンドを再度実行したときに Opened_tables が急激に増加しているようであれば、キャッシュはあまりヒットしていません。もし table_cache の設定よりも Open_tables の方が遥かに低いのであれば、キャッシュは大きすぎます (ただしキャッシュ・サイズに余裕を持たせることは悪いことではありません)。テーブル・キャッシュの調整は、例えば table_cache = 5000 のようにします。

テーブル・キャッシュと同様、スレッド用のキャッシュもあります。mysqld は接続の要求を受信すると必要に応じてスレッドを作成します。接続がすぐに破棄されるビジーなサーバーでは、後で使用するためにスレッドをキャッシュすることで接続の確立に要する時間を短くすることができます。

リスト 5. は、十分な数のスレッドがキャッシュされているかどうかを調べる方法を示しています。

リスト 5. スレッド使用状況の統計を示す
mysql> SHOW STATUS LIKE 'threads%';
+-------------------+--------+
| Variable_name     | Value  |
+-------------------+--------+
| Threads_cached    | 27     |
| Threads_connected | 15     |
| Threads_created   | 838610 |
| Threads_running   | 3      |
+-------------------+--------+
4 rows in set (0.00 sec)

ここで重要な値は Threads_created です。この値は、mysqld が新しいスレッドを作成する必要が生じるたびにインクリメントされます。もし SHOW STATUS コマンドを継続して実行している間にこの数字が急激に増加するようであれば、スレッド・キャッシュを増加することを検討する必要があります。そのためには、my.cnf の中で、例えば thread_cache = 40 のようにします。

キー・バッファーは MyISAM テーブルの索引ブロックを保存します。索引ブロックへの要求は、ディスクにはアクセスに行かず、メモリーへのアクセスにとどめておくのが理想的です。リスト 6 は、メモリーから読み取られたブロックの数に対してディスクから読み取られたブロックの数がいくつあるかを調べる方法を示しています。

リスト 6. キーの効率を調べる
mysql> show status like '%key_read%';
+-------------------+-----------+
| Variable_name     | Value     |
+-------------------+-----------+
| Key_read_requests | 163554268 |
| Key_reads         | 98247     |
+-------------------+-----------+
2 rows in set (0.00 sec)

Key_reads はディスクへのアクセスが行われた要求の数を表し、Key_read_requests は要求の合計数を表します。Key_readsKey_read_requests で割ると、ミス・レートが得られます。この場合では 1,000 回の要求に対して 0.6 回のミスです。もし 1,000 回の要求に対して 1 回を超えるミスが起きている場合には、キー・バッファーを増加することを検討する必要があります。例えば key_buffer = 384M とするとバッファーは 384MB に設定されます。

一時テーブルは高度なクエリーに使われます (例えば GROUP BY 句の場合のように、さらに処理を行う前に一時的にデータを保存しなければならない場合など)。理想的には、そうしたテーブルをメモリー内に作成しますが、一時テーブルは大きくなりすぎすぎるとディスクに書き込まれます。リスト 7 は一時テーブルの作成に関連する統計を示しています。

リスト 7. 一時テーブルの使用状況を調べる
mysql> SHOW STATUS LIKE 'created_tmp%';
+-------------------------+-------+
| Variable_name           | Value |
+-------------------------+-------+
| Created_tmp_disk_tables | 30660 |
| Created_tmp_files       | 2     |
| Created_tmp_tables      | 32912 |
+-------------------------+-------+
3 rows in set (0.00 sec)

一時テーブルが使われるごとに Created_tmp_tables が増加します。またディスク・ベースのテーブルが使われると Created_tmp_disk_tables がインクリメントされます。この比率はどのようなクエリーが行われるかに依存するため、この比率に関する確かなルールはありません。時間をかけて Created_tmp_disk_tables を観察すると、作成されたディスク・テーブルの割合を知ることができ、そこから設定の効果を判断することができます。tmp_table_sizemax_heap_table_size はどちらも一時テーブルの最大サイズを制御します。そのため、この両方を my.cnf の中で設定する必要があります。

セッションごとの設定

ここで説明する設定はセッションごとに行う設定ですが、これらの数字を設定する際には注意をする必要があります。接続数が増えると、これらのオプションによって大量のメモリーが要求されることになるからです。特定のセッションでこれらの数字を変更するためにはコードを使用し、すべてのセッションに対して変更する場合は my.cnf で行います。

ソートを行う必要がある場合、MySQL は、ディスクから行を読み取る際にそれらの行を保存するためのソート・バッファーを割り当てます。ソート対象のデータが大きすぎる場合には、そのデータをディスク上の一時ファイルに置いてから再度ソートする必要があります。もし sort_merge_passes ステータス変数の値が大きい場合は、このためのディスク・アクティビティーが多いことを示しています。リスト 8 はソートに関連するいくつかのステータス・カウンターを示しています。

リスト 8. ソート統計を表示する
mysql> SHOW STATUS LIKE "sort%";
+-------------------+---------+
| Variable_name     | Value   |
+-------------------+---------+
| Sort_merge_passes | 1       |
| Sort_range        | 79192   |
| Sort_rows         | 2066532 |
| Sort_scan         | 44006   |
+-------------------+---------+
4 rows in set (0.00 sec)

sort_merge_passes が大きい値の場合は、sort_buffer_sizeに注目する必要があるということです。例えば、sort_buffer_size = 4M はソート・バッファーを 4MB に設定します。

また MySQL はテーブルを読み込む際にもメモリーを割り当てます。理想的には、必要な行のみを読み取るための十分な情報が索引によって提供されますが、場合によると、クエリーが (不適切な設計、またはデータの性質により) テーブルの大きな部分の読み取りを要求することがあります。この動作を理解するためには、SELECT 文が何回実行され、また (索引による直接アクセスを使わず) テーブルの中の次の行を読み取る動作が何回必要だったかを知る必要があります。このためのコマンドをリスト 9 に示します。

リスト 9. テーブル・スキャンの割合を調べる
mysql> SHOW STATUS LIKE "com_select";
+---------------+--------+
| Variable_name | Value  |
+---------------+--------+
| Com_select    | 318243 |
+---------------+--------+
1 row in set (0.00 sec)

mysql> SHOW STATUS LIKE "handler_read_rnd_next";
+-----------------------+-----------+
| Variable_name         | Value     |
+-----------------------+-----------+
| Handler_read_rnd_next | 165959471 |
+-----------------------+-----------+
1 row in set (0.00 sec)

Handler_read_rnd_next / Com_select によってテーブル・スキャンの割合が得られます。この場合は 521:1 です。もしこの数字が 4000 を超えるようであれば、read_buffer_size を調べ、例えば read_buffer_size = 4M のようにする必要があります。もしこの数字が 8M を超えて大きくなるようであれば、これらのクエリーを調整するよう、開発者と相談する必要があります。


3 つの必須ツール

SHOW STATUS コマンドは特定の設定を詳しく調べる場合には便利ですが、mysqld が提供する膨大な量のデータを解釈するためには、そのためのツールがいくつか必要です。私は 3 つのツールが欠かせないことに気付きました (リンクは「参考文献」セクションにあります)。

大部分のシステム管理者には、top コマンドがおなじみです。このコマンドは、さまざまなタスクによって CPU とメモリーが使用される様子を、常に最新状態に更新しながら表示します。mytoptop をモデルにしたものであり、接続されているすべてのクライアントを、それらのクライアントが現在実行しているすべてのクエリーと共に表示します。また mytop は、キー・バッファーとクエリー・キャッシュの効率に関するリアルタイム・データと履歴データ、そして実行されているクエリーに関する統計も提供します。mytop は何が起きているのかを (10 秒以内に) 調べるための便利なツールであり、サーバーのヘルスや、問題を引き起こしている接続を表示することができます

mysqlard は MySQL サーバーに接続するデーモンであり、5 分ごとにデータを収集し、そのデータを Round Robin Database バックエンドに保存します。Web ページは、テーブル・キャッシュの使用状況やキーの効率、接続されたクライアント、一時テーブルの使用状況などのデータを表示します。mytop はサーバーのヘルスのスナップショットを表示しますが、mysqlard は長期間のヘルス情報を表示します。さらに mysqlard は収集した情報の一部を使ってサーバーの調整方法についての助言をしてくれます。

SHOW STATUS 情報を収集するための、もう 1 つのツールが mysqlreport です。mysqlreport によるレポートは mysqlard よりもはるかに冗長ですが、それは mysqlreport がサーバーのすべての側面を分析するためです。mysqlreport はステータス変数に関して適切な計算を行い、修正が必要な部分を判断するための補助となるため、素晴らしいツールと言うことができます。


まとめ

この記事では MySQL の調整の基本について説明しました。LAMP コンポーネントの調整に関する 3 回シリーズは今回で終わりです。調整の大部分は、さまざまなものがどのように動作するかを理解することであり、またそれらが適切に動作しているかどうかを判断し、調整し、そして再評価を行うことです。それぞれのコンポーネント、Linux、Apache、PHP、そして MySQL には、さまざまな要求事項があります。それらを個々に理解することで、アプリケーションの速度を低下させるボトルネックをなくすことができます。

参考文献

学ぶために

製品や技術を入手するために

  • 実践ハイパフォーマンス MySQL』は 3 年前の本ですが、現在でも読む価値のある本です。この本の著者は MySQL に関するさまざまな記事を掲載した Web サイトも持っています。
  • mytop は、その瞬間に MySQL サーバーで何が起きているかを正確に教えてくれる上、いくつかの重要な統計も提供してくれます。データベースに関して問題があると、私は最初にこのプログラムを利用します。
  • mysqlard は MySQL サーバーのいくつかの重要なパフォーマンス指標をグラフ化し、そして調整のための助言を提供します。
  • mysqlreport は必須のツールとして、皆さんに代わって SHOW STATUS 変数を分析します。
  • MySQL に関する記事は phpMyAdmin へのリンクがなくては完全ではありません。この製品はステータス変数に関するいくらかの解釈も提供しますが、この製品を使うことで管理を容易に行えることが強みです。
  • developerWorks から直接ダウンロードできる IBM trial softwareを使って皆さんの次期 Linux 開発プロジェクトを構築してください。

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Linux, Open source, Web development
ArticleID=291825
ArticleTitle=LAMP システムを調整する: 第 3 回 MySQL サーバーを調整する
publish-date=06072007