2012年6月22日金曜日

INDEXの功罪(デメリットの方)

よく`INDEXは検索に利くけど更新性能を落とす'のは言われるけれど、
実際どれくらいなのか自分で試してみた。

投げ遣りなテーブルを作る。
 CREATE TABLE t1 ( num bigint unsigned auto_increment primary key,val char(32) );

0,''と100万回かかれたファイルを読み込ませる。
 LOAD DATA INFILE '/tmp/zero' INTO TABLE t1;

100万行更新する。
 UPDATE t1 SET val = MD5(num);

100万行消す。
 DELETE FROM t1;

各3回ずつ測定したら、INDEXを増やす。
 ALTER TABLE t1 ADD INDEX val1(val);

で、これを同じカラムに3本まで増やしながら延々測定。


INDEX LOAD[sec] UPDATE[sec] DELETE[sec]
PKだけ 4.2 17.0 3.3
PK+1つ 5.7 31.3 9.9
PK+2つ 7.7 46.4 18.5
PK+3つ 8.8 61.6 27.0


重複キーだから一概に言い切れないけど、綺麗に線形(ax+bの形で)出てるなぁ。。
かといってUPDATE,DELETEに使うカラムにはINDEX作っておきたいしなぁ。。
INDEXのないカラムでUPDATE,DELETEのWHERE条件を指定すると、InnoDBは全部の行をロックする

功罪あるよね。テーブル設計ムズカシイ。


ところで、Bloggerってファイル名はタイトルから自動生成してるみたいなんだけど、
このタイトルから自動的に生成されたファイル名は`index.html'だった。。

0 件のコメント :

コメントを投稿