このクエリと最適化されたテーブル構造のMYSQLの速度

私は新しいテーブルシステムを構築する必要があります。それはidと1varchars(255)のIDを格納します。それだけで保存する必要があります。行全体の明白な挿入/削除/更新以外に、実行される唯一の他のクエリはSELECT * FROM table WHERE id='id'です。 700万レコードこのクエリと最適化されたテーブル構造のMYSQLの速度

私は2つの私が思いついた構造である持っている：

（1） - 単一のテーブル、ID、その後、10 varcharsを、何のidが主キー、シンプルselect *で、空想何も参加していません。

（2） - 2つのテーブルは、最初にid、10個の整数要素、2番目はinteger(auto increment)、varcharsです。これは結合を使用します。したがって、私はクエリごとに10の結合を推測するでしょう。

明らかに2は正式な構造として、後でテーブルの構造の変更にはより良いですが、SPEEDという観点からは、より良いでしょうか？

出典

2010-12-27 David19801

あなたは常に正確10VARCHARフィールドを格納され、（それは常に名前、または常にアドレスなどだように）各VARCHARは独自の意味を持っている場合は、単に10フィールドを持つテーブルを作成します。

2番目のソリューションはEAV（entity-attribute-value）と呼ばれ、主に疎行列に使用されます（多くの可能な属性があり、特定のエンティティに対して設定されている属性がほとんどありません）。スケーラビリティとメンテナンス性はありますが、あなたのようなクエリの効率は低くなります。

出典

2010-12-27 13:02:53 Quassnoi

um、ありがとうございますが、どちらが速くなりますか？ – David19801

@David：最初のもの（すべての値が単一の行にあります）。 EAVの記述の「効率の悪い」とは「遅い」を意味します:) – Quassnoi

速度の面では間違いなく最初の方が優れています。ジョインは大きなテーブルではとても遅いです

出典

2010-12-27 13:05:22

「ジョイントは大きなテーブルでは本当に遅くなります」というメッセージが表示されますか？私はtable1のid列とtable2のinteger列のインデックスを作成します。 – David19801

大きなテーブルが遅い理由を明らかにするために何が起こるか想像してみてください。 –

このクエリと最適化されたテーブル構造のMYSQLの速度

答えて

関連する問題