MySQL-uuidを主キーとした場合とintを主キーとした場合のパフォーマンス測定比較の詳細説明

偶然、mysql主キー型はUUIDの格納にvarcharを使用しており、queryパフォーマンスがint型の主キーほど良くないことを知りました。インターネット上の多くの情報は理論上のものにすぎません。したがって、以下の結果は参考用であり、信頼できるものではありません。

3 つのテーブルのフィールドは、主キー ID がそれぞれ varchar、bigint、自動インクリメント bigint を使用することを除き、他の 3 つのフィールドはすべて varchar 36 ビットです

データベース: mysql5.5

テーブルタイプ: InnoDB

データ量: 100W アイテム

最初のケース:

主キーは uuid 32 ビットを使用します。

クエリ ステートメント 1 の実行: SELECT COUNT(id) FROM test_varchar;

クエリ ステートメント 2 の実行: SELECT * FROM test_varchar WHERE vname='00004629-b052-11e1-96aa-002655b28d7b';

クエリ ステートメント 3 の実行: SELECT * FROM test_varchar WHERE id='00004599b05211e196aa002655b28d7b';

ステートメント 1 の平均時間は 2.7 秒、

ステートメント 3 の平均時間は 0 秒です。秒; (マルチパーティテスト、条件に主キー ID がある限り、ミリ秒単位のクエリ速度は 000 になります。テストされる ID 値には、最初の 100 と最後の 900,000 が含まれます。クエリ時間は全く同じで、ミリ秒レベルは 000)

2 つの状況:

主キーは bigint

を使用し、データは純粋な数値のシーケンス (22461015967875697) を使用します。 (固定ベース値が大きいことを除いて、自動拡張と同等です。) クエリ ステートメント 1 の実行: SELECT COUNT(id) FROM test_long; クエリ ステートメント 2 の実行: SELECT * FROM test_long WHERE vname='d7f28a24- b053 -11e1-96aa-002655b28d7b';

クエリ ステートメント 3 を実行します: SELECT * FROM test_long WHERE id='22461015967875702';

ステートメント 1 にかかる平均時間は次のとおりです:

ステートメント 2 にかかる平均時間は 1.2 秒です。ステートメント 3 の平均消費時間は 0 秒です (マルチパーティ テスト、条件に主キー ID がある限り、クエリ速度はミリ秒単位で 000 と表示されます)値の範囲は最初の 100 から 900,000 を超えます) クエリ時間はまったく同じで、ミリ秒レベルは 000)

3 番目のケース:

クエリ ステートメント 1: SELECT COUNT(id) FROM test_int ;

クエリ ステートメント 2 の実行: SELECT * FROM test_int WHERE vname= 'c80f8427-b059-11e1-96aa-002655b28d7b'; クエリ ステートメント 3 の実行: SELECT * FROM test_int WHERE id=900000;

主キーは次を使用します。 mysql

に付属する自動拡張機能であり、データは純粋な数値 (1、2、3、4、5...) です。

クエリ ステートメント 1 の平均所要時間: 1.07 秒;

クエリ ステートメント 2 の平均所要時間: 1.31 秒; クエリ ステートメント 3 の平均所要時間: 0 秒条件に主キー ID がある限り、クエリ速度はミリ秒単位で 000 を示します。テストされた ID 値には最初の 100 と最後の 900,000 が含まれており、クエリ時間はまったく同じです。 all 000)

概要

: Mysql InnoDB の主キーは自動拡張を採用し、パフォーマンスが向上していることがわかります。

筆者の独り言: 通常のプロジェクト開発では、SQL文の条件にIDがあるものが多数派であり、IDがないものが少数派である。上記のテストでは、条件ステートメントに主キー ID がある限り、主キーの種類に関係なく、クエリ時間はまったく同じであることがわかります。ただし、プロジェクト内のすべての SQL ステートメントの条件に ID があることを保証することはできません。そのため、どのタイプの主キーを使用する必要があるかはすでに理解していると思います。 データベース: mysql5.5

テーブルタイプ: MyISAM

データ量: 100W 項目

書く単語を減らして時間を節約するために、テーブルこの中で使われているtest SQL ステートメントと同様に、ここでは消費時間のみが記録されます。

最初のケース:

主キーは uuid 32 ビットを使用します。

ステートメント 1 の平均時間は 0 秒、

ステートメント 2 の平均時間は 0.53 秒、 ステートメント 3 の平均時間は 0 秒です。条件に主キー ID がある限り、クエリ速度はミリ秒レベルで 000 を示します。テストされた ID 値には、最初の 100 と最後の 900,000 が含まれます。クエリ時間はまったく同じで、ミリ秒レベルは次のようになります。 all 000)

2 番目のケース:

主キー。bigint

を使用し、uuid_short() を使用してデータを生成します (22461015967875697)。 (固定ベース値が大きいことを除いて、自動拡張と同等です。) ステートメント 1 の平均消費時間は 0 秒です。

ステートメント 2 の平均消費時間は 0.51 秒です。

ステートメント 3 の平均消費時間は次のとおりです。 (マルチパーティ テスト。条件に主キー ID がある限り、クエリ速度はミリ秒単位で 000 と表示されます。テストされた ID 値の範囲は、最初の 100 から 900,000 を超えるまではクエリ時間はまったく同じで、ミリ秒レベルは 000)

3 番目のケース:

主キーは mysql に付属する自動拡張を使用しており、データは純粋です数字 (1、2、3、4、5...) 。

ステートメント 1 の平均時間は 0 秒です。

ステートメント 2 の平均時間は 0.48 秒です。条件に主キー ID があるため、クエリ速度はミリ秒です。テスト ID 値の範囲は最初の 100 から 900,000 を超えます。クエリ時間はまったく同じで、ミリ秒レベルは 000) です。概要: mysql MyISAM の主キーは自動を使用していることがわかります。成長パフォーマンスは他のものよりわずかに優れています。テストデータが 1000W 100000000 であれば、外部キー関連のクエリもあれば、この利点はさらに顕著になると思います。もちろん、設計するシステムのデータ量が 100 万を超えない場合は、使用する主キーの種類は関係ありません。私のテスト コンピュータはラップトップです。プロ用サーバーの場合、これらの mysql MyISAM のテストでは時間差をまったく測定できません。

以上がMySQL-uuidを主キーとした場合とintを主キーとした場合のパフォーマンス測定比較の詳細説明の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。