MySQLブログ | システム監視・サーバ監視・障害監視・ネットワーク監視・システム運用・MySQL・Web地図を提供

MySQLブログ エントリ一覧

InnoDB vs MyISAM パフォーマンス比較 DELETEとINSERT

前回のUPDATEに続いて今回はDELETEとINSERTのパフォーマンスを比較します。

測定環境についてはこちらを参照して下さい。

・データ件数は100万件
・こちらの構造のテーブルをInnoDBとMyISAMで作成して処理速度を比較

以下SQL中の「テーブル名 normal」にはMyISAMなら normal2 がセットされます。

3.PrimaryKeyでDELETE

　 DELETE FROM normal WHERE id = %d

　※%idは1～100万の範囲でランダムに変化

PrimaryKeyでDELETE
スレッド数 MyISAM InnoDB
1 86.00 109.00
2 143.67 122.67
4 326.67 120.00
8 689.33 126.67
16 530.67 127.67
32 400.33 126.00
64 626.33 130.00

PrimaryKeyでDELETE


MyISAMの性能にかなりばらつきがありますが4～7倍程度MyISAMが高速です。
InnoDBは同時スレッド数による性能変化がまったく見られません。

4.INSERT

　 INSERT IGNORE INTO normal (id, name, password, email, city, zip, dob, country_id, state_id) VALUES (%d, %s, %s, %s, %s, %s, NOW(), %d, %d)

　※%dや%s等はすべてランダムな値がセットされます。

INSERT
スレッド数 MyISAM InnoDB
1 322.00 122.33
2 287.33 121.33
4 280.330 121.33
8 410.67 116.33
16 1,231.67 113.00
32 1,696.00 113.00
64 1,794.67 112.33

INSERT


3～15倍程度MyISAMが高速です。
特に、同時スレッドに比してQPSが上昇していきます。
通常、更新があるシステムの場合はInnoDBを採用するのが原則ですが、
ログ出力など細かいこと？を気にしない用途の場合にMyISAMはかなり有効だと言えます。

 

関連会社インターオフィスのブログ記事を転載しています。

6月 10

InnoDB vs MyISAM パフォーマンス比較 UPDATE

そもそもトランザクションがあるエンジン(InnoDB)と無いエンジン（MyISAM）を比較して
意味があるのかと言われるとそれまでですが、一応、更新系のパフォーマンスも比較してみます。

MyISAMの圧勝が想像できますが。

測定環境についてはこちらを参照して下さい。

・データ件数は100万件
・こちらの構造のテーブルをInnoDBとMyISAMで作成して処理速度を比較

以下SQL中の「テーブル名 normal」にはMyISAMなら normal2 がセットされます。

1.PrimaryKeyでUPDATE(更新対象は非インデックス項目)

　 UPDATE normal SET name=%s,dob=NOW() WHERE id = %d

　※%idは1～100万の範囲でランダムに変化
　※%sにはランダムな文字列をセットします
　※nameもdobもINDEXには指定されていません

PrimaryKeyでUPDATE(更新対象は非インデックス項目)
スレッド数 MyISAM InnoDB
1 156.67 122.00
2 271.33 118.00
4 414.00 118.33
8 670.67 122.00
16 878.00 121.67
32 728.67 118.67
64 879.67 119.00

PrimaryKeyでUPDATE(更新対象は非インデックス項目)


やはり6～8倍程度MyISAMが速いですね。

2.PrimaryKeyでUPDATE(更新対象がインデックス項目の場合)

　 UPDATE normal SET email=%s,dob=NOW() WHERE id = %d

　※%idは1～100万の範囲でランダムに変化
　※%sにはランダムな文字列をセットします
　※emailはUnique INDEXに指定されています

PrimaryKeyでUPDATE(更新対象がインデックス項目の場合)
スレッド数 MyISAM InnoDB
1 156.67 122.00
2 271.33 118.00
4 414.00 118.33
8 670.67 122.00
16 878.00 121.67
32 728.67 118.67
64 879.67 119.00

PrimaryKeyでUPDATE(更新対象がインデックス項目の場合)


7倍程度MyISAMが高速です。
更新項目が非INDEXの場合に比べて、それほど遅くなっている印象がありません。

次回はdeleteとinsertを計測します。

 

関連会社インターオフィスのブログ記事を転載しています。

6月 09

InnoDB vs MyISAM パフォーマンス比較 Left Join

INNER JOINに続いて、今度はLEFT JOINのパフォーマンス比較です。

測定環境についてはこちらを参照して下さい。

・データ件数は100万件
・こちらの構造のテーブルをInnoDBとMyISAMで作成して処理速度を比較
・entryとentry2は記事を格納するテーブルで100万件登録されています。

・entry_commentとentry_comment2はコメントを格納するテーブルで、こちらも100万件登録されています。
・PRIMARY KEYであるidには1～1000000の値がセットされています。
・1記事に対して、1コメントが存在しています。・以下の構造のテーブルをInnoDBとMyISAMで作成して処理速度を比較

以下SQL中の「テーブル名 entryとentry_comment」にはMyISAMなら entry2とentry_comment2 がセットされます。

LeftJoinのパフォーマンス比較用のＳＱＬ

PLAIN TEXT
SQL:

  1. SELECT e.id,
  2.        e.STATUS,
  3.        e.category_id,
  4.        e.user_type,
  5.        e.name,
  6.        e.favorites,
  7.        e.comments,
  8.        e.trackbacks,
  9.        e.favorite_permission,
  10.        e.comment_permission,
  11.        e.comment_captcha_permission,
  12.        e.trackback_permission,
  13.        e.edited,
  14.        e.image,
  15.        e.caption,
  16.        e.user_name,
  17.        e.created,
  18.        e.modified,
  19.        e.removed,
  20.        e.title,
  21.        e.body
  22.   FROM entry AS e LEFT JOIN entry_comment AS c ON e.id = c.entry_id
  23.  WHERE e.name = %s
  24.    AND ( e.STATUS = 1 OR e.STATUS = 2)
  25.    AND e.removed IS NULL
  26.    AND c.removed IS NULL ORDER BY e.edited DESC

　※%sはランダムに変化します。

InnoDBの実行計画(explainの結果）

PLAIN TEXT
SQL:

  1. *************************** 1. row ***************************
  2.            id: 1
  3.   select_type: SIMPLE
  4.         TABLE: e
  5.          type: ref
  6. possible_keys: entry_unique,entry_idx2
  7.           KEY: entry_unique
  8.       key_len: 194
  9.           ref: const
  10.          rows: 1
  11.         Extra: USING WHERE; USING filesort
  12. *************************** 2. row ***************************
  13.            id: 1
  14.   select_type: SIMPLE
  15.         TABLE: c
  16.          type: ref
  17. possible_keys: entry_comment_idx1
  18.           KEY: entry_comment_idx1
  19.       key_len: 5
  20.           ref: testsuite.e.id
  21.          rows: 1
  22.         Extra: USING WHERE; USING INDEX

MyISAMの実行計画(explainの結果）

PLAIN TEXT
SQL:

  1. *************************** 1. row ***************************
  2.            id: 1
  3.   select_type: SIMPLE
  4.         TABLE: e
  5.          type: ref
  6. possible_keys: entry_unique,entry_idx2
  7.           KEY: entry_unique
  8.       key_len: 194
  9.           ref: const
  10.          rows: 1
  11.         Extra: USING WHERE; USING filesort
  12. *************************** 2. row ***************************
  13.            id: 1
  14.   select_type: SIMPLE
  15.         TABLE: c
  16.          type: ref
  17. possible_keys: entry_comment_idx1
  18.           KEY: entry_comment_idx1
  19.       key_len: 5
  20.           ref: testsuite.e.id
  21.          rows: 1
  22.         Extra: USING WHERE; USING INDEX

実行計画は同じです。

計測結果

LEFT JOINのパフォーマンス比較
スレッド数 MyISAM InnoDB
1 83.67 130.67
2 136.67 256.67
4 235.33 411.67
8 314.00 474.00
16 384.33 467.67
32 444.67 448.33
64 489.00 439.33

LEFT JOIN


8同時スレッドのピーク時性能で50%程度、InnoDBのほうが高速です。
ただし64スレッド以上だと、MySQLのほうが高速になります。
それと、InnerJoinに比べると、処理性能が1/3程度になってしまっています。

 

関連会社インターオフィスのブログ記事を転載しています。

6月 08

InnoDB vs MyISAM パフォーマンス比較 Inner Join

副問い合わせに続いて、今度はINNER JOINのパフォーマンス比較です。

測定環境についてはこちらを参照して下さい。

・データ件数は100万件
・こちらの構造のテーブルをInnoDBとMyISAMで作成して処理速度を比較
・entryとentry2は記事を格納するテーブルで100万件登録されています。

・entry_commentとentry_comment2はコメントを格納するテーブルで、こちらも100万件登録されています。
・PRIMARY KEYであるidには1～1000000の値がセットされています。
・1記事に対して、1コメントが存在しています。・以下の構造のテーブルをInnoDBとMyISAMで作成して処理速度を比較

以下SQL中の「テーブル名 entryとentry_comment」にはMyISAMなら entry2とentry_comment2 がセットされます。

InnerJoinのパフォーマンス比較用のＳＱＬ

PLAIN TEXT
SQL:

  1. SELECT e.id, e.STATUS,
  2.        e.category_id,
  3.        e.user_type,
  4.        e.name, e.favorites,
  5.        e.comments, e.trackbacks,
  6.        e.favorite_permission,
  7.        e.comment_permission,
  8.        e.comment_captcha_permission,
  9.        e.trackback_permission,
  10.        e.edited,
  11.        e.image,
  12.        e.caption,
  13.        e.user_name,
  14.        e.created,
  15.        e.modified,
  16.        e.removed,
  17.        e.title,
  18.        e.body
  19.   FROM entry e, entry_comment c
  20.  WHERE c.user_name = %s
  21.    AND c.removed IS NULL
  22.    AND c.entry_id = e.id
  23.    AND ( e.STATUS = 1 OR e.STATUS = 2)
  24.    AND e.removed IS NULL
  25. ORDER BY c.created DESC

　※%sはランダムに変化します。

InnoDBの実行計画(explainの結果）

PLAIN TEXT
SQL:

  1. *************************** 1. row ***************************
  2.            id: 1
  3.   select_type: SIMPLE
  4.         TABLE: c
  5.          type: ref
  6. possible_keys: entry_comment_idx1,entry_comment_idx2,entry_comment_idx3,entry_comment_idx4
  7.           KEY: entry_comment_idx2
  8.       key_len: 204
  9.           ref: const,const
  10.          rows: 1
  11.         Extra: USING WHERE; USING filesort
  12. *************************** 2. row ***************************
  13.            id: 1
  14.   select_type: SIMPLE
  15.         TABLE: e
  16.          type: eq_ref
  17. possible_keys: PRIMARY
  18.           KEY: PRIMARY
  19.       key_len: 4
  20.           ref: testsuite.c.entry_id
  21.          rows: 1
  22.         Extra: USING WHERE

MyISAMの実行計画(explainの結果）

PLAIN TEXT
SQL:

  1. *************************** 1. row ***************************
  2.            id: 1
  3.   select_type: SIMPLE
  4.         TABLE: c
  5.          type: ref
  6. possible_keys: entry_comment_idx1,entry_comment_idx2,entry_comment_idx3,entry_comment_idx4
  7.           KEY: entry_comment_idx2
  8.       key_len: 204
  9.           ref: const,const
  10.          rows: 1
  11.         Extra: USING WHERE; USING filesort
  12. *************************** 2. row ***************************
  13.            id: 1
  14.   select_type: SIMPLE
  15.         TABLE: e
  16.          type: eq_ref
  17. possible_keys: PRIMARY
  18.           KEY: PRIMARY
  19.       key_len: 4
  20.           ref: testsuite.c.entry_id
  21.          rows: 1
  22.         Extra: USING WHERE

実行計画は同じですね。

計測結果

INNER JOINのパフォーマンス比較
スレッド数 MyISAM InnoDB
1 265.67 976.67
2 889.00 1,679.00
4 1,321.33 1,514.33
8 1975.33 1,117.00
16 918.33 1,044.00
32 925.33 1,025.33
64 939.33 1,080.67

INNER JOIN


4同時スレッドのピーク時性能で15%程度、InnoDBのほうが高速です。
同時スレッド数に対するスケーラビリィティの傾向が他のものと異なっています。

次回はLeftJoinを試してみます。

 

関連会社インターオフィスのブログ記事を転載しています。

6月 07

InnoDB vs MyISAM パフォーマンス比較 副問い合わせ

InnoDB vs MyISAMシリーズでブログ風のテーブル設計にして、
副問い合わせのパフォーマンスを試してみました。

測定環境についてはこちらを参照して下さい。

・データ件数は100万件
・こちらの構造のテーブルをInnoDBとMyISAMで作成して処理速度を比較

・entryとentry2は記事を格納するテーブルで100万件登録されています。
・entry_commentとentry_comment2はコメントを格納するテーブルで、こちらも100万件登録されています。
・PRIMARY KEYであるidには1～1000000の値がセットされています。
・1記事に対して、1コメントが存在しています。・以下の構造のテーブルをInnoDBとMyISAMで作成して処理速度を比較

以下SQL中の「テーブル名 entryとentry_comment」にはMyISAMなら entry2とentry_comment2 がセットされます。

副問い合わせのパフォーマンス比較用のＳＱＬ

PLAIN TEXT
SQL:

  1. SELECT  e.id, e.STATUS,
  2.         e.category_id,
  3.         e.user_type,
  4.         e.name,
  5.         e.favorites,
  6.         e.comments,
  7.         e.trackbacks,
  8.         e.favorite_permission,
  9.         e.comment_permission,
  10.         e.comment_captcha_permission,
  11.         e.trackback_permission,
  12.         e.edited,
  13.         e.image,
  14.         e.caption,
  15.         e.user_name,
  16.         e.created,
  17.         e.modified,
  18.         e.removed,
  19.         e.title,
  20.         e.body,
  21.         s.max_created AS max_created
  22.     FROM entry e, (SELECT c.entry_id,
  23.                         max(c.created) AS max_created
  24.                    FROM entry_comment c
  25.                   WHERE c.user_name = %s
  26.                     AND c.removed IS NULL
  27.                   GROUP BY c.entry_id) s
  28.   WHERE e.id = s.entry_id
  29.     AND e.removed IS NULL
  30.     AND ( e.STATUS = 1 OR  e.STATUS = 2)
  31.   ORDER BY s.max_created

　※%sはランダムに変化します。

InnoDBの実行計画(explainの結果）

PLAIN TEXT
SQL:

  1. *************************** 1. row ***************************
  2.            id: 1
  3.   select_type: PRIMARY
  4.         TABLE: <derived2>
  5.          type: system
  6. possible_keys: NULL
  7.           KEY: NULL
  8.       key_len: NULL
  9.           ref: NULL
  10.          rows: 1
  11.         Extra:
  12. *************************** 2. row ***************************
  13.            id: 1
  14.   select_type: PRIMARY
  15.         TABLE: e
  16.          type: const
  17. possible_keys: PRIMARY
  18.           KEY: PRIMARY
  19.       key_len: 4
  20.           ref: const
  21.          rows: 1
  22.         Extra:
  23. *************************** 3. row ***************************
  24.            id: 2
  25.   select_type: DERIVED
  26.         TABLE: c
  27.          type: ref
  28. possible_keys: entry_comment_idx2,entry_comment_idx3,entry_comment_idx4
  29.           KEY: entry_comment_idx2
  30.       key_len: 204
  31.           ref:
  32.          rows: 1
  33.         Extra: USING WHERE; USING TEMPORARY; USING filesort

MyISAMの実行計画(explainの結果）

PLAIN TEXT
SQL:

  1. *************************** 1. row ***************************
  2.            id: 1
  3.   select_type: PRIMARY
  4.         TABLE: <derived2>
  5.          type: system
  6. possible_keys: NULL
  7.           KEY: NULL
  8.       key_len: NULL
  9.           ref: NULL
  10.          rows: 0
  11.         Extra: const row NOT found
  12. *************************** 2. row ***************************
  13.            id: 1
  14.   select_type: PRIMARY
  15.         TABLE: e
  16.          type: eq_ref
  17. possible_keys: PRIMARY
  18.           KEY: PRIMARY
  19.       key_len: 4
  20.           ref: const
  21.          rows: 1
  22.         Extra: USING WHERE
  23. *************************** 3. row ***************************
  24.            id: 2
  25.   select_type: DERIVED
  26.         TABLE: c
  27.          type: ref
  28. possible_keys: entry_comment_idx2,entry_comment_idx3,entry_comment_idx4
  29.           KEY: entry_comment_idx2
  30.       key_len: 204
  31.           ref:
  32.          rows: 1
  33.         Extra: USING WHERE; USING TEMPORARY; USING filesort

2.rowの表現が食い違っています。
InnoDBは　type: const　ですが、MyISAMは　type: eq_ref　となっています。
ただ、両方ともに　key: PRIMARY　で、　ref: const　なので問題ないようです。

計測結果

副問い合わせのパフォーマンス比較
スレッド数 MyISAM InnoDB
1 498.67 1,192.33
2 1,410.33 1,714.33
4 1,460.00 1,711.33
8 1,442.00 1,668.00
16 1,328.33 1,550.67
32 1,236.33 1,386.00
64 1,150.67 1,162.67

副問い合わせ


2～8同時スレッドのピーク時性能で15～20%程度、InnoDBのほうが高速のようです。

同時スレッド数に対するスケーラビリィティは、これまで見てきた通り、MyISAMが優秀で、
おそらく128同時スレッド数あたりでは、優劣が逆転すると思います。

次回はInnerJoinを試してみます。

 

関連会社インターオフィスのブログ記事を転載しています。

6月 06

« 前ページへ — « 前の記事
次の記事 » — 次ページへ »
システム障害監視サービス
Web上の地図サービス開発
負荷テスト・チューニング
MySQLサービス開発
Google Enterprise パートナーロゴマーク

Google エンタープライズ 販売 / ソリューションパートナーです

MySQLエンタープライズ・ゴールドパートナーロゴマーク

MySQLエンタープライズ・ゴールドパートナーです

RapidSSL サイトシール
subscribe to RSS feed