1

私はすべて..

私は常に int(10) をすべてに使用してきましたが、数日前に新しいプロジェクトを開始し、これを 100% 最適化することを望んでいました ;)

それで、私は何人かと思っています。

user_id => int(6) vs. mediumint (8) または同様のものを作成/追加できます

group_id => tinyint(1) vs tinyint (4) または同様の作成/追加が可能になります

等々..

(X)がフィールドの幅であることは知っていますが、例を使用して作成できる実際のユーザー/投稿/メッセージ++の数はよくわかりません; int(10) の代わりに、id の mediumint(8)。

これについての返信ありがとうございます!!

-トム

4

2 に答える 2

5

通常、データベース ID は常に正 (0->∞) であるため、最大値は次のようになります。

Integer Type    Max Value
TINYINT         255
SMALLINT        65535
MEDIUMINT       16777215
INT             4294967295
BIGINT          18446744073709551615
于 2012-04-09T20:13:13.763 に答える
4

(X)はフィールドの幅であることを知っています

オプションの括弧内の数字は表示幅です。整数の範囲内に一意の値がいくつあるか、または整数が必要とするストレージ容量とは関係ありません。 アプリケーション コードは、表示幅に関するヒントを自由に無視できます。「表示幅」は、SQL の非標準拡張機能です。

INTEGER(6) と INTEGER(2) は両方とも格納に 4 バイトを必要とし、両方とも-2147483648 から 2147483647 の範囲の値を受け入れます。

すべての中整数は、保存に 3 バイトを必要とし、-8388608 から 8388607 までの範囲の値を受け入れます。

中間の int が値の完全なドメインを識別するのに十分な大きさ (〜 1,600 万の一意の値) であると仮定すると、4 バイトの整数よりも行ごとに 1 バイトを節約できる可能性があります。(一部のプラットフォームでは、次の単語境界までのパディングが必要になる可能性があります。32 ビット システムの場合、これは 4 バイトになるため、実際のスペースの節約にはなりません。MySQL がそれを行うかどうかはわかりません。) 1,000 万行の場合、 10 メガバイトを節約できます (さらに、インデックス内のスペースをいくらか節約できます)。最近ではそれほど多くありません。一般に、幅の狭いテーブルは幅の広いテーブルよりも高速ですが、ここでは違いに気付かないと思います。

于 2012-04-11T13:05:52.407 に答える