100,000 から 10,000,000 レコードの MySQL テーブルがいくつかあります。実際には 11 文字を超えるエントリがないにもかかわらず、一部のフィールドは VARCHAR(100) です。
明らかに、本来よりも多くのスペースを使用しています... 100 万レコードのテーブルの 1 つの VARCHAR(100) フィールドが 100 MB のスペースを使用している場合、数 GB ものスペースを無駄にしている可能性があります。
これらのテーブルを簡素化し、VARCHAR フィールドを適切なサイズに縮小した場合、ストレージ スペース以外にも役立つでしょうか? クエリのルックアップ時間を改善できる可能性はありますか?
MySQL ドキュメントのData type storage requirementsの時点で、varchar 型は次のように値を格納します。
列の値に 0 ～ 255 バイトが必要な場合は L + 1 バイト、値に 255 バイトを超える値が必要な場合は L + 2 バイト。ここで、L は特定の文字列値の実際の長さをバイト単位で表します。
タイプを VARCHAR(100) から VARCHAR(11) に変更する計画がある場合、MySQL はすでにその「最適」に値を格納しているため、クエリのパフォーマンスには影響しません。
タイプが CHAR(100) の場合、100 文字未満の文字列は空白で埋められます。この場合、スペースの消費が悪く、クエリのパフォーマンスも悪いと思います。
ドキュメントを参照するCHAR型の長さは次のとおりです。
M × w バイト、0 <= M <= 255。ここで、w は文字セット内の最大長の文字に必要なバイト数です。M は、宣言された列の長さを文字で表します。
ただし、すべてのレコードが固定長 11 の場合は、CHAR(11) を使用する必要があります。これにより、ストレージとクエリのパフォーマンスが向上します。
文字列ストレージに関するもう 1 つの重要な点は、ドキュメントに記載されているように、char セットを参照します。
特定の CHAR、VARCHAR、または TEXT 列の値を格納するために使用されるバイト数を計算するには、その列に使用される文字セットと、値にマルチバイト文字が含まれているかどうかを考慮する必要があります。特に、utf8 Unicode 文字セットを使用する場合は、すべての文字が同じバイト数を使用するわけではなく、1 文字あたり最大 3 バイトが必要になる可能性があることに注意する必要があります。
それが役に立てば幸い！
mysql 実装の詳細はわかりませんが、リレーショナル データベースの典型的な実装は知っており、その実装では役に立ちます。
通常、レコードは RID テーブルと呼ばれるファイルに連続して格納されます。RID テーブル内のレコード番号 (0 から始まるカウントを使用) にレコード サイズを掛けた値が、ファイル内でレコードが格納されている場所へのオフセットになります。
レコード サイズが小さい場合、RID テーブルのより多くのレコードがディスクからフェッチされたディスク セクターに収まり、より多くのレコードがメモリに収まります。
実装が異なっていても、レコード バッファを小さくすると、より多くのレコードをメモリにキャッシュできるため、ディスク アクセスの回数を減らすことができます。