0

この情報でテーブルを作成したい：

ID bigint(20) PK AI
FID bigint(20) unique
points int(10) index 
birthday date index 
current_city varchar(175) index 
current_country varchar(100) index 
home_city varchar(175) index 
home_country varchar(100) index 
Engine = MyISAM

私が学んだ学校で：2つの追加のテーブルを作成します。1つは都市で、もう1つは国で、データを挿入するときにそのテーブルへのFKを作成します。私が疑う理由は次のとおりです。

このテーブルには、1 時間あたり約10Mの挿入があります。行を挿入し、挿入ごとに都市の FK と国の FK を検索する必要がある場合、速度が大幅に低下する可能性があります。そして、これは、WHERE ID = id でのみ発生する行を選択しているときに得られる利益の価値があります。これらの選択は 1 時間あたり約25Mになります。

4

3 に答える 3

2

すべての悪の根源である場合、時期尚早の最適化。実際のパフォーマンス データがある場合は、まずきれいに設計し、次に最適化します。

きれいな設計とは、適切に正規化されたテーブル、つまり別の都市と国のテーブルを使用することです。

行を挿入し、挿入するたびに都市の FK と国の FK を検索する必要がある場合、速度が大幅に低下する可能性があります。

実際には、生の国/都市名の代わりに小さな ID だけを varchar 列に挿入する方が効率的です。

  • これにより、ディスクへの書き込みが少なくなります
  • MyISAMテーブルがあります。そのため、FK サポートがなく、外部キーのルックアップ/チェックを行いません。
  • varchar 列を整数に置き換えると、テーブルが固定長行形式になります。これは、動的長形式よりも高速になる可能性があります。

実際のデータ/ワークロードでベンチマークを行い、非正規化が本当に価値があるかどうかを確認してください。

于 2013-05-20T19:14:57.473 に答える
1

データベースの正規化が存在するのには理由があります。
都市用のテーブルと国用のテーブルを使用し、FK を介してマスター テーブルと結合します。
また、名前が100文字である国を知っていますか?
名前が175文字ある都市を知っていますか?
ID は bigint にすることができますが、BIGINT(20) が必要ですか? INT(11) で十分ではないでしょうか? とにかく、AUTOINCREMENTそれUNIQUEは意味がありません。
また、すべての列にインデックスがありますが、複合インデックスはありません。これは非常に多くの理由で間違っています。しませんpre-indexが、クエリに応じてインデックスを作成します。explainインデックスを作成する対象を確認するために使用します。
また、恐れずに複合インデックスを使用し、すべての列にインデックスを作成することは避けてください。
上記のすべての手順を実行すると、クエリが高速になります (少なくとも期待しましょう)。

于 2013-05-20T19:17:19.733 に答える