Optimization is a complicated task since it ultimately requires understanding of the whole system. While it may be possible to do some local optimizations with small knowledge of your system/application, the more optimal you want your system to become the more you will have to know about it.
So this chapter will try to explain and give some examples of different ways to optimize MySQL. But remember that there are always some (increasingly harder) ways to make the system even faster left to do.
The most important part for getting a system fast is of course the basic design. You also need to know that kinds of things your system will be doing. That is your bottlenecks are.
The most common bottlenecks are.
We start with the system level things sine some of these decisions have to be made very early. In other cases a fast look at this part may suffice since it not that important for the big gains. But it is always nice to have a feeling about how much one gould gain by chancing things at this level.
使うべき OS はとても重要です！ 複数の CPU を持つマシンでは、 Solaris (なぜなら、Solaris のスレッドはとても素晴らしく動作するから)、 あるいは、Linux ( kernel 2.2 は良い SMP をサポートしているから) を 使用すべきです。 32bit マシンの Linux では、2G bytes のファイルサイズの 制限があります。 これは新しいファイルシステム (XFS) のリリース時に なくなって欲しいものです。
Since we have not run production MySQL on that many platforms we advice you to test your intended platform before choosing it if possible.
Other tips:
--skip-locking MySQL オプション
を使用します。
Note that this will not impact MySQL functionality as
long that only run one server. Just remember to take down the server (or
lock relevant parts) before you run myisamchk. On some system
this switch is mandatory since the external locking does not work in any
case.
MIT スレッドでコンパイルする時は --skip-locking がデフォルトです。
これは全てのプラットフォームで MIT スレッドが flock() を完全にサポートし
ていないためです。
--skip-locking が使用できないただ一つの状態は、
もしあなたが複数の MySQL SERVER (クライアントではないです) を
同じデータに対して走らせている場合です。
Or run
myisamchk on the table without first flushing and locking the
mysqld server tables first.
たとえ --skip-locking を使用していても、
LOCK TABLES / UNLOCK TABLES の使用は可能です。
次のテストの多くは Linux 上で MySQL ベンチマークで行われました。 しかし、これらは他の OS についてもいくつかの指標を与えます。
-static でのリンク時に最速の実行形式を得ます。
TCP/IP の代わりに Unix ソケットをデータベースへの
接続に使用することも、より良い性能を与えます。
Linux では、pgcc と -O6 でコンパイルした時に最速のコードを得られます。
このオプションで `sql_yacc.cc' をコンパイルすると、gcc/pgcc は
全ての関数をインラインにするために多くのメモリを必要とするので、200M のメモリが必要です。
libstdc++ ライブラリの増加を避けるためには、
MySQL の configure 時に CXX=gcc も設定すべきです。
より良いコンパイラー、そしてコンパイラーのオプションは、10-30% の 速度の向上をもたらします。 これはあなた自身が MySQL をコンパイルする 時に重要なことです！
Intel では、例えば pgcc か Cygnus CodeFusion compiler で最速となります。 我々は 新しい Fujitsu コンパイラーでもテストしましたが、 MySQL を最適化オプションでコンパイルするには、 まだ完全なバグ・フリーではありませんでした。
Here is a list of some mesurements that we have done:
pgcc を使用して -O6 で全てをコンパイルすると、
mysqld サーバーは gcc よりも 11% 速くなります。
-static) 無し)の場合、結果は 13% 遅くなります。
Note that you still can use a dynamic linked MySQL library. It
is only the server that is critical for performance.
gcc 2.7.3 は Sun Pro C++ 4.2 より 13% 速くなります。
TCX により配布されている MySQL-Linux 配布は pgcc でコンパイルされ、
静的にリンクされています。
テーブルとデータベースのファイルを MySQL のデータベースディレクトリーから 違う場所に移動し、 それに対してシンボリックリンクを張ることができます。 これは例えばディスク容量が少なくなって、データベースを移動したい場合にそうしたくなるでしょう。
MySQL が、テーブルがシンボリックリンクであることに気づいた場合、
symlink を解析し、代わりにその実体のテーブルを使用します。
これは realpath() コールをサポートする全てのシステムで働きます（少
なくとも Linux と Solaris は realpath() をサポートします！）。
realpath() をサポー トしないシステム上では、symlink とテーブルを
同時に使用すべきでありません！ テーブルはテーブルの更新後に矛盾する事になるでしょう。
MySQL はデフォルトではデータベース同士のリンクをサポートしません。
が、データベース間のシンボリックリンクを作成しない限り、これは正常に働くでしょう。
MySQL データディレクトリに db1 データベースがあるとして、
仮に db2 を db1 のシンボリックリンクにしたとします:
shell> cd /path/to/datadir shell> ln -s db1 db2
すると、db1 中の tbl_a テーブルは db2 の tbl_a テーブルとして見えます。
もしあるスレッドが db1.tbl_a を更新し、他のスレッドが db2.tbl_a を
更新した場合、 問題が発生します。
こういった使用をどうしてもしたい場合、`mysys/mf_format.c' を以下のように変更します:
if (!lstat(to,&stat_buff)) /* Check if it's a symbolic link */
if (S_ISLNK(stat_buff.st_mode) && realpath(to,buff))
Change the code to this:
if (realpath(to,buff))
mysqld サーバーが使用している現在のバッファサイズを次で得ることができます:
shell> mysqld --help
この結果、全ての mysqld オプションと次のようなコンフィグ可能変数のリスト
を得られます。出力結果にはデフォルト値が含まれ、以下のように表示されます:
Possible variables for option --set-variable (-O) are: back_log current value: 5 connect_timeout current value: 5 delayed_insert_timeout current value: 300 delayed_insert_limit current value: 100 delayed_queue_size current value: 1000 flush_time current value: 0 join_buffer_size current value: 131072 key_buffer_size current value: 1048540 lower_case_table_names current value: 0 long_query_time current value: 10 max_allowed_packet current value: 1048576 max_connections current value: 100 max_connect_errors current value: 10 max_delayed_threads current value: 20 max_heap_table_size current value: 16777216 max_join_size current value: 4294967295 max_sort_length current value: 1024 max_tmp_tables current value: 32 max_write_lock_count current value: 4294967295 net_buffer_length current value: 16384 query_buffer_size current value: 0 record_buffer current value: 131072 sort_buffer current value: 2097116 table_cache current value: 64 thread_concurrency current value: 10 tmp_table_size current value: 1048576 thread_stack current value: 131072 wait_timeout current value: 28800
もし mysqld サーバーを走らせているなら、以下のコマンドでも変数の値を見ることができます:
shell> mysqladmin variables
これらのオプションは以下のように決めてください。
buffer size, buffer length, stack size は byte 単位で与えます。
これらの値の後ろに `K' や `M' を追加すると、キロバイト、メガバイトになります。
例えば、16M は16メガバイトを示します。大文字小文字の区別はなく、
16M と 16m は同じ意味になります。
稼働中のサーバーの統計情報は SHOW STATUS で参照できます. 「7.21 SHOW 構文 (テーブルやフィールドなどについての情報を得る)」節参照.
back_loglisten(2) のマニュアルページに、さらに詳細があります。
この値を最大限にしたい場合、お使いのOSのドキュメントを見てください。
back_log をこのOSの制限値より多く取ってもは全く効果ありません。
connect_timeoutmysqld サーバーが接続パケットを待つ秒数。 (Bad handshake を返すまでの秒数)
delayed_insert_timeoutINSERT DELAYED スレッドが INSERT 文を待つべきか。
delayed_insert_limitdelayed_insert_limit 個のレコードを挿入した後、 INSERT DELAYED ハンドラーは
待たされている SELECT 文がないかチェックします。 もしあるなら、
挿入を続ける前にそれらの実行を許します。
delayed_queue_sizeINSERT DELAYED.
If the queue becomes full, any client that does INSERT DELAYED will wait until
there is room in the queue again.
flush_timeflush_time 秒ごとに
全てのテーブルが閉じられます。 (リソースの解放とDiskへのsyncのために)
join_buffer_sizekey_buffer_sizekey_buffer_size はインデックス・ブロックのためのバッファ・サイズです。
Increase this get better index handling (for all reads and multiple
writes) to as much as you can afford. If you make this too big the
system will starte to page and go REAL slow. Remember that since MySQL
does not cache data read that you will have to leave some room for the
OS filesystem cache.
To get even more speed when writing many rows at the same time use
LOCK TABLES. 「7.24 LOCK TABLES/UNLOCK TABLES 構文」節参照.
long_query_timeSlow_queries カウンター
が増やされます。
max_allowed_packetnet_buffer_length バイトに初期化されますが、
max_allowed_packetまで大きくすることができます。このデフォルト値は、
大きなパケット、間違ったパケットをを受けるには小さい値です。
大きな BLOB を使用している場合は、これを増加する必要があります。使用した
い最大の BLOB と同じくらい大きくするべきです。
max_connectionsmysqld が持つファイ
ルディスクリプタの数を増やす必要があるでしょう。
後述のファイルデスクリプターの制限の説明を参照のこと。
これは OS に依存しますので、OS のドキュメントを見てください。
max_connect_errorsFLUSH HOSTS コマンドで
ホストの拒否を解除できます。
max_delayed_threadsINSERT DELAYED を扱うスレッドを起動できません。
もし全ての INSERT DELAYED スレッドが使用されていて、さらに新しいテーブルに
データを挿入しようとすると、そのレコードは DELAYED が与えられていない
場合と同様に挿入されます。
max_join_sizemax_join_size より多いレコードを触るとエラーが返ります。長い時間をかけて
百万行を返すような WHERE なしの結合を作成するようなユーザを持って
いる場合にこれを設定してください。
max_sort_lengthBLOB または TEXT 項目上でソートする時に使用するバイト数。
(最初の max_sort_length バイトだけがそれぞれの値で使用でき、残りは無視されます)
max_tmp_tablesnet_buffer_lengthmax_allowed_packet バイトまでです)
record_buffersort_bufferORDER BY または GROUP BY のためにはこれを増やしてく
ださい。
「18.4 MySQL が一時ファイルを格納する場所」節参照.
table_cachemysqldが要求するオープンファイルディスクリプタの数も
増加することに注意しないといけません。
MySQL はユニークテーブル毎に2つのファイルディスクリプタを必要と
します。
後述のファイルデスクリプターの制限の説明を参照のこと。
テーブルキャッシュがどのように働くかはこちらを参照 「10.2.4 MySQL はどのようにテーブルのオープン & クローズを行なうか？」節.
tmp_table_sizeThe table ### is full エラーを生成します。
多くの先進的な GROUP BY クエリを行う場合は、この値を増加してください。
thread_stackcrash-me によって検出される多く
の制限がこれに依存します。デフォルトでは、通常のオペレーションに対して
十分とってあります。
「10.8 Using your own benchmarks」節参照.
wait_timeout
MySQL はとてもスケーラブルなアルゴリズムを使用します。そのため 通常はとても少ないメモリで動作し、またより良い性能を得るために MySQL に多くのメモリを与えることができます。
多くのメモリと多くのテーブルを持っていて、適度のクライアント数で最大性能を得た い場合、次のようなものを使用します:
shell> safe_mysqld -O key_buffer=16M -O table_cache=128 \
-O sort_buffer=4M -O record_buffer=1M &
多くの接続で少ないメモリしかない場合、次のようなものを使用します:
shell> safe_mysqld -O key_buffer=512k -O sort_buffer=100k \
-O record_buffer=100k &
or even:
shell> safe_mysqld -O key_buffer=512k -O sort_buffer=16k \
-O table_cache=32 -O record_buffer=8k -O net_buffer=1K &
もしとても多くの接続があり、mysqld が各接続に対して少ないメモリーで
動作するように設定されていれば、スワップの読み書きによるパフォーマンスの低下がおきます。
もちろん十分なメモリーがあれば、全ての接続にたいして mysqld のパフォーマンス良くなります。
mysqld へのオプションを変更する場合、そのサーバのインスタンスにだけに
有効であることに注意して下さい。
パラメータ変更の効果を見るには、このようにします:
shell> mysqld -O key_buffer=32m --help
--help オプションは最後につけてください。
その他のオプションを --help の後につけると、そのオプションは反映されません。
table_cache, max_connections , max_tmp_tables は
サーバーが開いた状態にしておく事が出来るファイルの最大数に影響します。
If you
increase one or both of these values, you may run up against a limit
imposed by your operating system on the per-process number of open file
descriptors. However, you can increase the limit on many systems.
Consult your OS documentation to find out how to do this, because the
method for changing the limit varies widely from system to system.
table_cache は max_connections に関連します。
例えば 200 のコネクションを同時に開けるなら、少なくとも 200 * n の
テーブル・キャッシュが必要です。 ここで n は join におけるテーブルの
最大数です。
オープンテーブルのキャッシュは最大で table_cache まで大きくなります(デ
フォルトは 64, mysqld のオプション -O table_cache=# で変更可能)。
キャッシュが一杯になって、他のスレッドがテーブルのオープンを試みた時、
または mysqladmin refresh mysqladmin flush-tables
を使用した場合を除いて、テーブルはクローズされません。
キャッシュがいっぱいになった場合、サーバーは以下の処置を取って キャッシュを使用できるように配置します：
テーブルは各同時アクセスに (再び) オープンされます。これは、同じテーブルで2つのスレッ
ドが実行されている場合、または同じクエリで(AS で)テーブルを2回アクセス
する場合、テーブルは2回オープンする必要があることを意味します。最初のテーブルのオー
プンは2つのファイル記述子を使用し、続くテーブルの各使用は1つだけのファイル記述
子を使用します。
もしたくさんのファイルが一つのディレクトリにある場合、オープン、クローズ、
作成操作は遅くなるでしょう、 もし SELECT 文を多くのテーブルに対し
実行した場合、テーブルキャッシュが一杯ならば、このオーバーヘッドは多くなるでしょう。
なぜなら、それぞれのテーブルにつきオープンし、クローズしなくてはならないからです。
このオーバーヘッドを緩和するには、テーブルキャッシュを大きくします。
mysqladmin status を実行すると、次のようなものが得られます:
Uptime: 426 Running threads: 1 Questions: 11082 Reloads: 1 Open tables: 12
確かにたった6個しかテーブルがないのに、このような結果が出るので少々戸惑われるかもしれません。
MySQL はマルチスレッドなので、同じテーブルで一度に多くのクエリを持て ます。同じファイル上で異なる状態を持つ2つのスレッドで、問題を最小化する ため、同時に動作する各スレッドのためテーブルを再びオープンします。これはいくつ かのメモリとデータファイルについての一つの拡張ファイル記述子を使用します。 インデックスファイル記述子は全てのスレッド間で共有されます。
以下に mysqld サーバーがどのようにメモリーを使用するか、いくつか示します。
サーバーに与える変数名は、サーバーのメモリーの使用方に関連した名前となっています。
key_buffer) は全てのスレッドで共有され、
残りは必要時に割り当てられます。
「10.2.3 サーバーパラメーターのチューニング」節参照.
thread_stack), 接続バッファ(variable
net_buffer_length), 結果バッファ(variable
net_buffer_length)。接続バッファと結果バッファは必要となった時、
動的に最大 max_allowed_packet まで増えます。
クエリが走っている時、そのクエリの文字のコピーが割り当てられます。
BLOB を含む
テーブルはディスク上に置かれます。
MySQL 3.23.2 以前での問題は、HEAP テーブルが
tmp_table_size のサイズを越えると、エラー The table tbl_name is full
が出ることです。将来我々は、必要時にメモリ (HEAP) テーブルをディスクベー
ス (NISAM) テーブルに自動的に変更することにより、これを修正します。この
問題を回避するため、mysqld への tmp_table_size オプションま
たはクライアント側で SQL オプション SQL_BIG_TABLES で増加できます。
「7.25 SET OPTION 構文」節参照.
MySQL 3.20 では、一時テーブルの最大サイズは
recordbuffer*16 でした。そのため、このバージョンを使用していると、
recordbuffer を追加する必要があります。 mysqld を --big-tables で
開始することで、常に一時テーブルをディスク上に格納できます。しかしこれは
多くの複雑なクエリの速度に影響します。
malloc() と free() で行なわれます)。
3 * n のサイズのバッファが割り当てられます。
( n は BLOB 型のフィールドの長さを含めない、一レコードの最大長です )
BLOB は 5 から 8 バイト + BLOB データの長さを使用します。
BLOB を持つ各テーブルでは、より大きな BLOB の読み込みでバッファ
は動的に拡大されます。テーブルのスキャンをする場合、割り当てられたバッファは最
も大きい BLOB と同じ大きさになります。
mysqladmin refresh は使用されていない全てのテーブルをクローズし、
使用されている全てのテーブルを、実行中スレッドが終った時にクローズするよ
うにマークします。これは多くの使用メモリを解放するのに有効です。全てのロ
グファイルもクローズと再オープンされます。
mysqld 実行時、ps や他のプログラムは、それが多くのメモリ
を使用していると報告するでしょう。これは異なったメモリアドレス上のスレッ
ドスタックによって発生します。例えば、Solaris ps はスタック間の未使用メ
モリを使用メモリとして計算します。'swap -s' で有効なスワップをチェックす
ることでこれを確かめられます。我々は市販のメモリリーク検出プログラムで
mysqld をテストしました。そのため、メモリリークは全くありません。
MySQL の全てのロックはデッドロックフリーです。これは、常にクエ リ開始時に一度ロックを必要とする全てを要求し、常に同じ順でテーブルをロッ クすることで管理されます。
MySQL が使用する WRITE ロックは次のように働きます:
MySQL の READ ロックは次のように動きます:
ロックが解放されたとき、最初に write ロックキュー内のスレッドに、その後 read ロックキュー内のスレッドにロックを与えます。
これは、同じテーブルで多くの更新をする場合、SELECT 構文は
update がなくなるまで待たされることを意味します。
同じテーブルで多くの INSERT と多くの SELECT を行う場合、これを解決するに
は、他のテーブルに行を挿入して、たまに、その一時テーブルから全てのレコー
ドをもう一方のテーブルに update します。
これは次のコードで行えます:
mysql> LOCK TABLES real_table WRITE, insert_table WRITE; mysql> insert into real_table select * from insert_table; mysql> delete from insert_table; mysql> UNLOCK TABLES;
決まりきった検索に優先権を与えるため、INSERT 構文で LOW_PRIORITY か HIGH_PRIORITY オプションが使用できます。
「7.14 INSERT構文」節参照.
一つのキューだけを使用するように `mysys/thr_lock.c' 内のロックコードを変更 することもできます。この場合、いくつかのアプリケーションのために、 write ロックは read ロックと同じ優先順位にします。
MySQL のテーブル・ロッキングのコードはデッドロック・フリーです。
MySQL はとても速いロックスピードを得るために、 (レコードのロックやフィールドのロックの代わりに) テーブルのロックを使用します。 大きなテーブルには、 テーブルのロックはレコードのロックよりはるかに良いですが、 いくつかの落とし穴があります。
In MySQL 3.23.7 and above, one can insert rows into
MyISAM tables at the same time as other threads are reading on
the table. Note that currently this only works if there is no deleted
rows in the table.
テーブルのロックはたくさんのスレッドが同時にあるテーブルから読み出すのを可能にしますが、 もしあるスレッドがあるテーブルに対し書込み要求を出す場合、 それはまず最初に排他的なアクセスを得なければなりません. その更新の間、更新が完了するまで、この特定のテーブルにアクセスしようとする 他の全てのスレッドが待たされることになります。
通常データベースの更新は SELECT よりも重要とされるため、
テーブルを更新する全てのスレッドが、テーブルから情報を検索するスレッドよりも
高い優先順位を持ちます。 これは ある特定のテーブルに対して、多くの重いクエリが発行され
た場合に、 更新が不完全に終わらないことを確実にするためです。
Starting from MySQL 3.23.7 one can use the
max_write_lock_count variable to force MySQL to issue
a SELECT after a specific number of inserts on a table.
この1つの主な問題が以下です：
SELECT を発行。
UPDATE を発行；
このクライアントは先の SELECT が完了するまで待ちます
SELECT 構文を発行；
UPDATE は SELECT よりも高い優先度を持つので、
この SELECT は先の UPDATE が完了するまで待ちます。
これは一番最初の SELECT が 終了するまで待たされます！
この問題のいくつかの可能な解決は以下の通りです：
SELECT 構文を速く実行できるように試みます； これを行うにあたり、
いくつかのサマリーテーブルを作成しなければならないかもしれません.
mysqld を --low-priority-updates オプションで起動。
これは全てのあるテーブルを更新する構文に対して、 SELECT 構文よりも
低い優先度を与えます。 この場合、前述のシナリオ中の最後の SELECT 構文は
INSERT 構文が完了する前に実行されます。
LOW_PRIORITY 属性指定を用いて、 INSERT,UPDATE,DELETE 構文
に低い優先度を与えることも出来ます。
mysqld with a low value for max_write_lock_count to give
READ locks after a certain number of WRITE locks.
SET SQL_LOW_PRIORITY_UPDATES=1 を使用して、
ある特定のスレッドからの全ての更新を、低い優先度に指定する事ができます。
「7.25 SET OPTION 構文」節参照.
HIGH_PRIORITY 属性を用いて、特定の SELECT がとても重要であると
指定することが可能です。. 「7.12 SELECT構文」節参照.
INSERT combined with SELECT,
switch to use the new MyISAM tables as these supports concurrent
SELECTs and INSERTs.
INSERT と SELECT 構文を主に混在させるのなら、
INSERT の DELAYED 属性指定はこの問題を解決させるでしょう。
「7.14 INSERT構文」節参照.
SELECT と DELETE で問題があるなら、
DELETE の LIMIT オプションが助けになるでしょう。
「7.11 DELETE構文」節参照.
One of the most basic optimization is to get your data (and indexes) to take as little space on the disk (and in memory) as possible. This can give huge improvements since disk reads are faster and normally less main memory will also be used. Indexing also takes less resources if done on smaller columns.
You can get better performance on a table and minimize storage space using the techniques listed below:
MEDIUMINT は INT より良いでしょう。
NOT NULL に定義してください。これは全てをより速くし、
各フィールド毎に1ビットを節約します。
Note that if you really need
NULL in your application you should definitely use it. Just avoid
haveing it on all columns by default.
VARCHAR, TEXT, BLOB) を持たない場合は、
固定サイズレコード形式が使用されます。
これはかなり速いです。しかしあいにくいくらかの領域を浪費します。
「10.6 table 型の選択」節参照.
Indexes are used to find find a row with a specific calue on one column fast. Without a index MySQL has to start with the first record and then read through the whole table until it find the relevent rows. The bigger the table the more this costs. If the table has a index for the colums in question MySQL can get fast a possition to seek to in the middle of the data file without having to look at all data. If a table have 1000 rows this is at least 100 times faster than reading sequentially. Note that is you need to access almost all 1000 rows it is faster to read sequentially since we when avoid disk seeks.
全ての MySQL インデックス, PRIMARY, UNIQUE そして INDEX()
は B tree に格納されます。文字列は自動的に始めと終りの空白が圧縮されます。
「7.27 CREATE INDEX 構文」節参照.
Indexes are used to:
WHERE節にマッチした行の素早い検索
MAX() や MIN() 値の割り出し
ORDER BY key_part_1,key_part_2 )。
もし DESC 指定があれば、全てのキーは逆順に読まれます。
以下のような SELECT 文を発行したとします：
mysql> SELECT * FROM tbl_name WHERE col1=val1 AND col2=val2;
もし col1 と col2 に複数フィールドインデックスが定義されている場合、
すぐに思ったとおりの結果が得られます。
If separate single-column
indexes exist on col1 and col2, the optimizer tries to
find the most restrictive index by deciding which index will find fewer
rows and using that index to fetch the rows.
もしテーブルが複数フィールドインデックスを持つなら、インデックスの接頭部一番左の部分
がレコードを見つけるための最適化に使用されます。例えば、3つのフィールド
(col1,col2,col3) に対して一つのインデックスを持っていたとします。
すると、これは (col1), (col1,col2) ,
(col1,col2,col3) でインデックスがサーチされます。
もし一番左に指定しているフィールドがインデックスを作成していないなら、 MySQL は部分的なインデックスを使用しません。
以下のような SELECT 文を発行したとします：
mysql> SELECT * FROM tbl_name WHERE col1=val1; mysql> SELECT * FROM tbl_name WHERE col2=val2; mysql> SELECT * FROM tbl_name WHERE col2=val2 AND col3=val3;
もしインデックスが (col1,col2,col3) にあるならば、
上に示した最初のクエリだけがインデックスを使用します。二番目三番目のクエリは
インデックスを持つフィールドを発動しますが、
(col2) と (col2,col3) は、(col1,col2,col3) の
接頭部一番左に指定されていません。
MySQL は、もし LIKE がワイルドカードから始まっていなくて、
ある種固定された文字で始まっているなら、
LIKE の評価にインデックスを使用します。
例えば、以下の SELECT 文はインデックスを使用します:
mysql> select * from tbl_name where key_col LIKE "Patrick%"; mysql> select * from tbl_name where key_col LIKE "Pat%_ck%";
一つ目の文は、"Patrick" <= key_col < "Patricl" となるレコードだけ、考慮されます。
二つ目の文は、"Pat" <= key_col < "Pau" となるレコードだけ、考慮されます。
以下の SELECT 文はインデックスを使用しません:
mysql> select * from tbl_name where key_col LIKE "%Patrick%"; mysql> select * from tbl_name where key_col LIKE other_col;
最初の文は、LIKE がワイルドカード文字で始まっています。
二つ目の文は、LIKE が定数ではありません。
Searching using column_name IS NULL will use indexes if column_name
is a index.
MySQL は通常、一番少ないレコード数を見つけるインデックスを使用します。
インデックスは、以下に示す演算子を用いて比較できるフィールドに対して、使用されます：
=, >, >=, <, <=, BETWEEN そして
'something%' の様に頭にワイルドカードがない LIKE。
WHERE 節ないの全ての AND にかからないインデックスは、
全くクエリの最適化に使用されません。
以下の WHERE 節はインデックスを使用します：
... WHERE index_part1=1 AND index_part2=2
... WHERE index=1 OR A=10 AND index=2 /* index = 1 OR index = 2 */
... WHERE index_part1='hello' AND index_part_3=5
/* optimized like "index_part1='hello'" */
以下の WHERE 節はインデックスを使用しません：
... WHERE index_part2=1 AND index_part3=2 /* index_part_1 is not used */ ... WHERE index=1 OR A=10 /* No index */ ... WHERE index_part1=1 OR index_part2=10 /* No index spans all rows */
First one thing that affect all querys. The more compex permission systen setup you have, the more overhead you get.
If you do not have any GRANT statements done MySQL will optimize
the permission checking somewhat. So if you have a very high vokume it
may be worth the time to avoid grants. Otherwise more permission check
gives a larger overhead.
もし MySQL 関数のあるものが確実に問題を引き起こしているのならば、 常に MySQL クライアント側は以下のようになります：
mysql> select benchmark(1000000,1+1); +------------------------+ | benchmark(1000000,1+1) | +------------------------+ | 0 | +------------------------+ 1 row in set (0.32 sec)
上の例では MySQL は 1,000,000 + 式を 0.32 秒で実行できています
(たんなる PentiumII 400MHz マシンで)。
全ての MySQL 関数は最適化されていますが、
いくつかは例外があるかもしれません。
benchmark(loop_count,expression)はあなたのクエリの
問題を見つけるためのとてもよいツールです。
ほとんどの場合、ディスク・シークを数えることでだいたいのパフォーマンスを予測できます。
小さなテーブルでは、通常、1回のディスク・シークでレコードを見つけれるでしょう
(インデックスがたぶんキャッシュされるので)。 大きなテーブルでは、
おおよその予測として、(B++ ツリーインデックスを使用している場合)、
log(row_count) /
log(index_block_length / 3 * 2 / (index_length + data_pointer_length)) +
1 シーク、1レコードを見つけるのに必要となるでしょう。
MySQL では、インデックス・ブロックは通常 1024 バイトで、
データ・ポインターは通常 4 バイトです。 これは、
インデックス長が 3 (medium integer) 、データが 500,000 レコードあるテーブルでは、
log(500,000)/log(1024/3*2/(3+4)) + 1 = 4 シークとなります。
As the above index would require about 500,000 * 7 * 3/2 = 5.2M, (assuming that the index buffers are filled to 2/3 (which is typical) you will probably have much of the index in memory and you will probably only need 1-2 calls to read data from the OS to find the row.
For writes you will however need 4 seek requests (as above) to find where to place the new index and normally 2 seeks to update the index and write the row.
Note that the above doesn't mean that your application will slowly degenerate by N log N! As long as everything is cached by the OS or SQL server things will only go marginally slower while the table gets bigger. After the data gets too big to be cached, things will start to go much slower until your applications is only bound by disk-seeks (which increase by N log N). To avoid this increase the index cache as the data grows. 「10.2.3 サーバーパラメーターのチューニング」節参照.
SELECT クエリの速度
通常、遅い SELECT ... WHERE を速くするには、
まず最初にインデックスがあるかどうかをチェックします。 「10.4 MySQL はどのようにインデックスを使用するか？」節参照.
違うテーブルを参照する場合には、普通はインデックスをともなうべきです。
EXPLAIN コマンドを使用すれば、SELECT でどのインデックスが
使用されているか確認できます。
「7.22 EXPLAIN 構文 (SELECTについての情報を得る)」節参照.
Some general tips:
myisamchk
--analyze on a table after it has been loaded with relevant data. This
updates a value for each index that indicates the average number of rows
that have the same value. (For unique indexes, this is always 1, of
course.)
myisamchk
--sort-index --sort-records=1 (if you want to sort on index 1). If you
have a unique index from which you want to read all records in order
according to that index, this is a good way to make that faster. Note
however that this sorting isn't written optimally and will take a long
time for a large table!
WHERE 節を最適化するか？
The where optimizes are put in the SELECT part here since they
are mostly used there. But the same optimizations are used for there in
DELETE and UPDATE statements.
Also note that this section is incomplete. MySQL does many optimizations and we have not had time to document them all.
MySQLによる最適化のいくつかを以下に示します:
((a AND b) AND c OR (((a AND b) AND (c AND d)))) -> (a AND b AND c) OR (a AND b AND c AND d)
(a<b AND b=c) AND a=5 -> b>5 AND b=c AND a=5
(B>=5 AND B=5) OR (B=6 AND 5=5) OR (B=7 AND 5=6) -> B=5 OR B=6
WHERE がない CONST(*) は、テーブルから
直接取り出されます。これはまた同じ条件下での任意の NOT NULL 表現
のためにも行われます。
SELECT 構文を素早く見つけ、0 行を結果として返します。
GROUP BY または group 関数 (COUNT(), MIN()...) を使用しない場合は、
HAVING は WHERE とマージされます。
WHERE 評価を得るために、また、可能な限り
早くレコードをスキップするために、各サブ結合についてより簡単な
WHERE が構築されます。
WHERE 節で UNIQUE インデックスや PRIMARY KEY が使用されたテーブルで、
かつ、全てのインデックスが定数式で使用されていて、
かつ、インデックスのパートが NOT NULL で定義されているテーブル。
mysql> SELECT * FROM t WHERE primary_key=1;
mysql> SELECT * FROM t1,t2
WHERE t1.primary_key=1 AND t2.primary_key=t1.id;
ORDER BY または GROUP 内の全てのフィールドが同じテーブルの場合は、
このテーブルは結合時に最初に優先されます。
ORDER BY 節と GROUP BY 節がある場合、または ORDER BY か GROUP BY が結合キュー
内の最初のテーブルではない他のテーブルからの項目を含む場合、一時テーブルが生成されます。
SQL_SMALL_RESULT を使用するなら, MySQL はメモリー内の一次テーブルを
使用します
DISTINCT は、全てのフィールドに対する GROUP BY に変換されるため、
ORDER BY と合わした DISTINCT は多くの場合で一時テーブルが
必要になります。
HAVING 節に適合するものをスキップします。
以下はとても速いクエリの例です:
mysql> SELECT COUNT(*) FROM tbl_name;
mysql> SELECT MIN(key_part1),MAX(key_part1) FROM tbl_name;
mysql> SELECT MAX(key_part2) FROM tbl_name
WHERE key_part_1=constant;
mysql> SELECT ... FROM tbl_name
ORDER BY key_part1,key_part2,... LIMIT 10;
mysql> SELECT ... FROM tbl_name
ORDER BY key_part1 DESC,key_part2 DESC,... LIMIT 10;
以下のクエリはインデックスツリーのみを使用します(インデックス化されているフィールドは 数値型と仮定します)：
mysql> SELECT key_part1,key_part2 FROM tbl_name WHERE key_part1=val;
mysql> SELECT COUNT(*) FROM tbl_name
WHERE key_part1=val1 AND key_part2=val2;
mysql> SELECT key_part2 FROM tbl_name GROUP BY key_part1;
以下のクエリは、ソートされた行の検索にインデックスを使用します：
mysql> SELECT ... FROM tbl_name ORDER BY key_part1,key_part2,... mysql> SELECT ... FROM tbl_name ORDER BY key_part1 DESC,key_part2 DESC,...
LEFT JOIN
A LEFT JOIN B is in MySQL implemented as follows
B is set to be dependent on table A.
A is set to be dependent on all tables (except B)
that are used in the LEFT JOIN condition.
LEFT JOIN conditions are moved to the WHERE clause.
WHERE optimzations are done.
A that matches the WHERE clause, but there
wasn't any row in B that matched the LEFT JOIN condition,
then an extra B row is generated with all columns set to NULL.
LEFT JOIN to find rows that doesn't exist in some
table and you have the following test: column_name IS NULL in the
WHERE part, where column_name is a column that is declared as
NOT NULL, then MySQL will stop searching after more rows
(for a particular key combination) after it has found one row that
matches the LEFT JOIN condition.
LIMIT
In some cases MySQL will handle the query differently when you are
using LIMIT # and not using HAVING:
LIMIT, MySQL
will use indexes in some cases when it normally would prefer to do a
full table scan.
LIMIT # with ORDER BY, MySQL will end the
sorting as soon as it has found the first # lines instead of sorting
the whole table.
LIMIT # with DISTINCT, MySQL will stop
as soon as it finds # unique rows.
GROUP BY can be resolved by reading the key in order
(or do a sort on the key) and then calculate summaries until the
key value changes. In this case LIMIT # will not calculate any
unnecessary GROUP's.
MySQL has sent the first # rows to the client, it
will abort the query.
LIMIT 0 will always quickly return an empty set. This is useful
to check the query and to get the column types of the result columns.
LIMIT # to calculate how much
space is needed to resolve the query.
INSERT クエリの速度レコードを挿入する時間は次からなります:
ここで (数字) は比例時間です。これは、テーブルのオープンにかかる初期オーバーヘッ ド(これは同時に動作する各クエリ毎に1回行なわれます)は考慮されていません。
テーブルのサイズはインデックスの挿入を N log N で遅くします (B-tree)。
Some ways to speed up inserts:
INSERT 文を使用します。 これは個々に INSERT 文
を発行する場合に比べて、とても速くなります。
INSERT DELAYED 文の使用で、より速くなるでしょう。 「7.14 INSERT構文」節参照.
MyISAM one can insert rows at the same time
SELECT:s are running if there is no deleted rows in the tables.
LOAD DATA INFILE を
使用します。 これはたくさんの INSERT 文の発行に比べて通常 20倍 程度
速くなります
「7.16 LOAD DATA INFILE構文」節参照.
LOAD DATA INFILE even
faster when the table has many indexes. Use the following procedure:
CREATE TABLE. For example using
mysql or Perl-DBI.
FLUSH TABLES の実行。 あるいは mysqladmin flush-tables
コマンドの実行。
myisamchk --keys-used=0 -rq /path/to/db/tbl_name の使用。 This will
remove all usage of all indexes from the table.
LOAD DATA INFILE を使用してデータを入れます. This will not
update any indexes and will therefore be very fast.
myisampack をお持ちで、テーブルを圧縮したいなら、
myisampack を実行します. 「10.6.3 Compressed table characteristics」節参照.
myisamchk -r -q /path/to/db/tbl_name でインデックスを再構築.
これは disk に書き込む前にインデックスをメモリに作成します。
And that is much faster since it avoid lots of disk
seeks. The resulting index tree is also perfectly balanced.
FLUSH TABLES の実行。 あるいは mysqladmin flush-tables
コマンドの実行。
LOAD DATA INFILE in some future
version of MySQL.
mysql> LOCK TABLES a WRITE; mysql> INSERT INTO a VALUES (1,23),(2,34),(4,33); mysql> INSERT INTO a VALUES (8,26),(6,29); mysql> UNLOCK TABLES;主な速度差は、全ての
INSERT 構文でインデックスバッファが一度だけディスクにフ
ラッシュされることです。通常は INSERT 構文があるのと同じくらい多くのインデッ
クスバッファフラッシュがあります。単一構文の全てのレコードは、ロックなしで挿入できます。
ロックも複数接続テストの合計時間を低くしますが、いくつかのスレッドの最大
待ち時間は上がります(ロックを待っているから)。
例えば:
thread 1 does 1000 inserts thread 2, 3, and 4 does 1 insert thread 5 does 1000 insertsロックを使用しない場合、2, 3 そして 4 は 1 と 5 の前に終ります。ロックを 使用する場合、2,3,4 は 1 や 5 の前に終わることはおそらくありませんが、合 計時間は約 40 % 速くなります。
INSERT, UPDATE , DELETE は、 MySQL ではとても速いので、
1 行で約 5 つ以上、値を 挿入・更新 をする操作に対して、
ロックを追加すれば、全般的により良い性能が得られます。
とても多い insert を行なう場合、
他のスレッドにそのロックしたテーブルへのアクセスを与えるために 、
だいたい 1000 レコードごとに一度、UNLOCK TABLES した後に
LOCK TABLES を行います。 これでもまだ良い性能が得られます。
もちろん LOAD DATA INFILE はとても速いです。
To get some more speed for both LOAD DATA INFILE and
INSERT, enlarge the key buffer. 「10.2.3 サーバーパラメーターのチューニング」節参照.
UPDATE クエリの速度
UPDATE クエリは SELECT クエリのように最適化されますが、
書き込みのオーバーヘッドが加わります。
書き込み速度は、更新されるデータの大きさ、更新されるインデックス数に
依ります。
Also another way to get fast updates is to delay updates and then do many updates in a row later. Doing many updates in a row is much quicker than doing one at a time if you lock the table.
Not that with dynamic record format updating a record with to a longer
total length may split the record. So if you do this often it is very
important to OPTIMIZE TABLE sometimes. 「7.9 OPTIMIZE TABLE構文」節参照.
DELETE クエリの速度1レコードを削除する時間は、ちょうどインデックスの数に比例します。 より速くレコードを削除したいなら、インデックス・キャッシュを 増やします。 「10.2.3 サーバーパラメーターのチューニング」節参照.
Its also much faster to remove all rows than to remove a big part of the rows from a table.
MySQL では、現在 (version 3.23.5)、4つのテーブルフォーマットを、 スピードの観点から選ぶことが出来ます。
myisamchk は、それぞれのレコードの開始点と終了点を安易に見つけることが出来ます。
So it can usually reclaim all records except the
partially written one. Not that in MySQL all indexes can always be
reconstructed.
OPTIMIZE table か myisamchk を使用して、テーブルの
フラグメンテーションを修正することが可能です。
If you have static data that you acess/change a lot in the same
table as some VARCHAR or BLOB columns, it might be a good
idea to move the dynamic columns to other tables just to avoid
fragmentation.
myisampack で作成されます。
SELECT tab1.a, tab3.a FROM tab1, tab2, tab3
WHERE tab1.a = tab2.a and tab2.a = tab3.a and tab2.c != 0;
これをスピードアップするために、我々は、
tab2 と tab3 を join した一時テーブルを作成することができます。
なぜならこれらは同じフィールド(tab1.a) に参照されるからです。
以下に一時テーブルの作成と SELECT を示します。
CREATE TEMPORARY TABLE test TYPE=HEAP
SELECT
tab2.a as a2, tab3.a as a3
FROM
tab2, tab3
WHERE
tab2.a = tab3.a and c = 0;
SELECT tab1.a, test.a3 from tab1, test where tab1.a = test.a1;
SELECT tab1.b, test.a3 from tab1, test where tab1.a = test.a1 and something;
VARCHAR,
BLOB, TEXT フィールドがない場合に、使用されます。
CHAR, NUMERIC, DECIMAL フィールドは、そのフィールド長
に足りない部分にはスペースが埋められます。
myisamchk) unless a huge number of
records are deleted and you want to return free disk space to the operating
system.
VARCHAR, BLOB, TEXT フィールドが
含まれている場合に使用されます。
'') for string columns, or zero for numeric columns (this isn't
the same as columns containing NULL values). If a string column
has a length of zero after removal of trailing spaces, or a numeric
column has a value of zero, it is marked in the bit map and not saved to
disk. Non-empty strings are saved as a length byte plus the string
contents.
myisamchk
-r from time to time to get better performance. Use myisamchk -ei
tbl_name for some statistics.
3 + (フィールド数 + 7) / 8 + (char フィールドの数) + 数値フィールドをパックしたサイズ + 文字の長さ + (NULL フィールドの数 + 7) / 8There is a penalty of 6 bytes for each link. A dynamic record is linked whenever an update causes an enlargement of the record. Each new link will be at least 20 bytes, so the next enlargement will probably go in the same link. If not, there will be another link. You may check how many links there are with
myisamchk -ed. All links may be removed with myisamchk -r.
myisampack utility. All customers
with extended MySQL email support are entitled to a copy of
myisampack for their internal usage.
myisampack can read tables that
were compressed with myisampack
0 are stored using 1 bit.
BIGINT column (8 bytes) may
be stored as a TINYINT column (1 byte) if all values are in the range
0 to 255.
ENUM.
BLOB or TEXT
columns.
myisamchk.
MySQL can support different index types, but the normal type is
ISAM. This is a B-tree index and you can roughly calculate the size for the
index file as (key_length+4)*0.67, summed over all keys. (This is for
the worst case when all keys are inserted in sorted order.)
String indexes are space compressed. If the first index part is a string, it
will also be prefix compressed. Space compression makes the index file
smaller if the string column has a lot of trailing space or is a VARCHAR
column that is not always used to the full length. Prefix compression helps
if there are many strings with an identical prefix.
HEAP テーブルはメモリー内にのみ存在することが出来ます。
そのため、もし mysqld が止められたりクラッシュしたりした場合、
このデータはなくなります。
しかしこれは とても 速いので、とにかく便利です。
The MySQL internal HEAP tables uses 100% dynamic hashing without overflow areas and don't have problems with delete.
You can only access things by equality using a index (usually by the
= operator) whith a heap table.
HEAP のもつマイナス面は:
ORDER BY).
Unsorted tips for faster systems:
EXPLAIN コマンドでこれが行えれます。
「7.22 EXPLAIN 構文 (SELECTについての情報を得る)」節参照.
SELECT queries on tables that are updated a
lot. This is to avoid problems with table locking.
SELECT * from table where hash='calculated hash on col1 and col2'
and col_1='constant' and col_2='constant' and ..
VARCHAR や BLOB
フィールドを避けるように試みるべきです。
You will get dynamic row length as soon as you
are using a single VARCHAR or BLOB columns. 「9.4 MySQL table types」節参照.
UPDATE table set count=count+1 where index_column=constant
is very fast!
This is really important when you use databases like MySQL that
only has table locking (multiple readers / single writers). This will
also give better performance with most databases as the row locking
manager in this case will have less to do.
INSERT /*! DELAYED */ when you do not need to now when your
data is written. This speeds things up since many records can be written
with a single disk write.
INSERT /*! LOW_PRIORITY */ when you want your selects are
more important.
SELECT /*! HIGH_PRIORITY */ to get selects that jumps the
que. That is the select is done even if there is somebody waiting to do
a write.
INSERT 文の使用。 これは多くのレコードを一つの SQL コマンドで
挿入することが出来ます。
(多くの SQL サーバーがこれをサポートしています)
LOAD DATA INFILE to load bigger amounts of data. This if
faster than normal inserts and will be even faster when myisamchk
is integrated in mysqld.
AUTO_INCREMENT columns to make unique values.
OPTIMIZE TABLE を時々使用します。
「7.9 OPTIMIZE TABLE構文」節参照.
HEAP テーブルをスピードアップのために使用します. 「9.4 MySQL table types」節参照.
name instead of
customer_name in the customer table). To make your names portable
to other SQL servers you should keep them shorter than 18 characters.
MyISAM directly you could
get a speed increase of 2-5 times compared to using the SQL interface.
The be able to do this the data must however be on the same server as
the application and usually it should only be accessed by on processes
(because external file locking is real slow). One could eliminate the
above problems by introducing low level MyISAM commands in the
MySQL server (this could be one easy way to get more
performance if needed). By carefully designing the database interface
it should be quite easy to support this types of optimisations.
You should definitely benchmark your application and database to find out where is the bottlenecks. By fixing it (or by replacing the bottleneck with a 'dummy module') you can then easily identify the next bottleneck (and so on). Even if the overall performance for your application is 'good enough' you should at least make a 'plan', for each bottleneck, how to solve it if you someday 'really need it fix it'.
For some example portable becnchmark programs look at the MySQL benchmark suite. 「11 MySQL ベンチマークスイート」節参照. You can take any program this suite and modify it for your needs. By doing this, you can try different solutions to your problem and test which is really the fastest solution for you.
It is very common that some problems only occur then the system is very heavily loaded. And we have had many customer who contacts us then they have a (tested) system in production and have have got load problems. In every on these cases so far it has been problems with basic design (table scans are NOT good at high load) or OS/Library issues. Most of this would be a LOT easier to fix if the system where not already in production.
To avoid probles like this you should put some effort into benchmarking your whole appliction under the worst possible load!
MySQL keeps row data and index data in separate files. Many (almost all) other databases mix row and index data in the same file. We belive that the MySQL choice is better for a very wide range of modern systems.
Another way to store the row data is to keep the information for each column in a separate area (examples are SDBM and Focus). This will get a performance hit for every query that access more than one column. Since this degenerates so quickly when more that when one columns are accessed we believe that this model is not good for general purpose databases.
The more common case is there the index and data are stored together (like in Oracle/Sybase at all). In this case you will find the row information at the leaf page of the index. The good thing with this layout is that it in many cases (depends on how well the index is cached) saves a disk read. The bad things with this layout is:
Since MySQL uses extremely fast table locking (multiple readers / single writers) the biggest remaining problem is a mix of a steady stream of inserts and slow selects on the same table.
We belive that for a huge number of system the extreamy fast performance in other cases make this choice a win. This case is usually also possible to solve by having multiple copies of the table. But it takes more effort and hardware.
We are also working on some extension to solve this problem for some common application niches.
Since all SQL servers implement different parts of SQL it takes work to write portable SQL applications. For very simple selects/inserts it is very easy but the more you need the harder it gets. And if you want a application that is fast with many databases it becomes even harder!
To make a complex application portable you need to choose a number of SQL server that it should work with.
When you can use the MySQL crash-me program/web-page http://www.mysql.com/crash-me-choose.htmy to find functions, types and limits you can use with a selection of database servers. Crash-me now test a long way from everything possible but it still is vｴcomprehensive with about 450 things tested.
For example, you shouldn't have longer column names than 18 characters if you want to be able to use Informix or DB2.
Both the MySQL benchmarks and Crash-me programs are very database independent. By taking a look of how we have handled this, you can get a feeling of what you have to do to write your application database independent. The benchmark themselves can be found in the `sql-bench' directory in the MySQL source distribution. They are written in Perl with DBI database interface (which solves the access part of the problem.
See http://www.mysql.com/benchmark.html the results from this benchmark.
As you can see in these results all databases has some weak points. That is they have different design compromises that lead to different behavior.
If you strive for database independence you need to get a good feeling of each SQL servers bottlenecks. MySQL is VERY fast in retrieving and updating things, but will have a problem in mixing slow readers/writers on the same table. Oracle on the other hand has a big problem when you try to access rows that you have recently updated (until they are flushed to disk). Transaction databases in general are not very good in generating summary tables from log tables as in this case row locking is almost useless.
To get your application 'really database independent' you need to define a easy extendable interface through which you manipulate your data. As C++ is available on most systems, it makes sense to use a C++ classes interface to the databases.
If you use some specific feature for some database (like the
REPLACE command in MySQL), you should code a method for
the other SQL servers to implement the same feature (but slower). With
MySQL you can use the /*! */ syntax to add
MySQL specific keywords to a query. The code inside
/**/ will be treated as a comment (ignored) by most other SQL
servers.
If REAL high performance is more important than exactness, like in some web applications. A possibility is to create a application layer that caches all results to give you even higher performance. By just letting old results 'expire' after a while you can keep the cache reasonable fresh. This is quite nice in case of extremely high load, in which case you can dynamicly increase the cache to be bigger and set the expire timeout higher until things gets back to normal.
In this case the table creating information should contain information of the initial size of the cache and how often the table should normally be refreshed.
MySQL の初期の開発期には、MySQL は我々のもっとも大口の顧客に合うように 機能が作成されました。 彼らは、いくつかのスウェーデン最大手の小売り業者 のために、倉庫に入れている（商品）データを取り扱います。
我々は、すべての店から、全ボーナス・カード取扱高の、その週間まとめを得ます。 そして、その店のオーナにとって有益な情報、その店の広告キャンペーンが お客にどの程度影響を及ぼすか、を提供することが、我々に求められています。
そのデータは、とても大きくて (約700万/月 回の取り扱い)、 我々はその顧客に提供する必要のあるデータを 4～10年分、持っています。 我々は、カスタマーから、彼らがこのデータからできる新しいレポートに ”即時に”アクセスしたいという、要求を受けました。
我々はこれを、全ての月ごとの情報を圧縮した 'transaction' テーブルに 保存することで解決しました。 We have a set of simple macros/script that generate summary tables grouped by different criterias (product group, customer id, store ...) from the transaction tables. そのレポートは Web ページで、これは小さな perl スクリプトで動的に 作成されます。 この perl script は Web Page を分析し、SQL 文を 実行し、結果を挿入します。 Now we would have used PHP or mod_perl instead but they where not available at that time.
画像データのために、我々は簡単なツールを C でかきました。
これは SQL のクエリの結果を元に(結果にいくつか処理をして) GIF を提供します。
これも動的に perl スクリプト(HTML ファイルを分析する)から実行されます。
In most cases a new report can simple by done by copying a existing script and modifying the SQL query in it. In some cases we will need to add more fields to an existing summary table or generate a new one, but this is also quite simply as we keep all transactions tables on disk. (Currently we have at least 50G of transactions tables and 200G of other customer data).
We also let our customers access the summary tables directly with ODBC so that the advanced users can themselves experiment with the data.
我々はこれらを Sun Ultra sparcstation (2x200 Mz) で扱っていますが、 なんの問題もありません。 We recently upgrade one of our servers to a 2 CPU 400 Mz Ultra sparc and we are now planing to start handling transactions on the product level, which would mean a 10 fold increase of data. We think we can keep up with this by just adding more disk to our systems.
We are also experimenting with Intel-Linux to be able to get more cpu power cheaper. 現在、我々はバイナリ互換のデータベースフォーマットを持っており (new in 3.23) 、我々はこれをアプリケーションのいくつかの部分に使用しはじめる事でしょう。
Our initial feelings are that Linux will perform much better on low to medium load but Solaris will perform better when you start to get a a high load because of extrema disk IO, but we don't yet have anything conclusive about this. After some discussion with a Linux Kernel developer this might be a side effect of Linux giving so much resources to the batch job that the interactive performance gets very low. This make the machine feel very slow and unresponsive while big batches are going. Hopefully this will be better handled in future Linux Kernels.
Go to the first, previous, next, last section, table of contents.