MySQL 8.0 リファレンスマニュアル MySQL NDB Cluster 8.0 を含む
このページは機械翻訳したものです。
MyISAM
テーブルが可変長カラムを含んでいる場合 (VARCHAR
、VARBINARY
、BLOB
、または TEXT
)、またはテーブルが ROW_FORMAT=DYNAMIC
テーブルオプションで作成された場合は、動的ストレージフォーマットが使用されます。
動的フォーマットは、それぞれの行に行の長さを示すヘッダーがあるため、静的フォーマットよりも少し複雑です。 更新の結果として行が長くなった場合、行がフラグメント化される可能性があります (非連続的な断片で格納されます)。
OPTIMIZE TABLE
または myisamchk -r を使用して、テーブルをデフラグできます。 可変長カラムも含んだテーブルで、固定長カラムに頻繁にアクセスしたり変更したりする場合、可変長カラムを他のテーブルに移動して、フラグメンテーションを回避する方法が良い場合があります。
動的フォーマットのテーブルには、次の特徴があります。
長さが 4 未満のカラムを除くすべての文字列カラムは動的です。
それぞれの行の先頭には、どのカラムが空の文字列 (文字列カラムの場合) またはゼロ (数値カラムの場合) を含むかを示すビットマップが付いています。 これには、NULL
値を含むカラムは含まれません。 後続スペースを削除したあとに文字列カラムの長さがゼロであったり、数値カラムの値がゼロであったりした場合、ビットマップの中でマークが付きますが、ディスクには保存されません。 空ではない文字列は、長さバイトに文字列コンテンツを加えて保存されます。
NULL
カラムの値が NULL
であるかどうかを記録するには、行に追加の領域が必要です。 各 NULL
カラムは 1 ビット余分に占め、もっとも近いバイトまで丸められます。
通常、固定長テーブルに比べると、必要なディスク容量がかなり少なくなります。
それぞれの行は、必要とする容量だけを使用します。 ただし、行がさらに大きくなると、必要な数の断片に分割され、行のフラグメンテーションが起こることになります。 たとえば、行の長さを延長する情報を使って行を更新すると、その行はフラグメント化されます。 このような場合、パフォーマンスを上げるために、ときどき OPTIMIZE TABLE
または myisamchk -r を実行しなければいけないかもしれません。 myisamchk -ei を使用して、テーブルの統計を取得します。
行がいくつもの断片にフラグメント化されている場合や、リンク (フラグメント) が失われている場合があるため、クラッシュ後の再構築は、静的フォーマットテーブルよりも難しくなります。
動的サイズの行の予想される行長は、次の式で計算されます。
3 + (number of columns
+ 7) / 8 + (number of char columns
) + (packed size of numeric columns
) + (length of strings
) + (number of NULL columns
+ 7) / 8
それぞれのリンクには 6 バイトのペナルティーがあります。 更新によって行が拡大される場合は、必ず動的行がリンクされます。 新しいリンクはそれぞれ少なくとも 20 バイトであるため、おそらく次の拡張は同じリンクになります。 そうでない場合、別のリンクが作成されます。 myisamchk -ed を利用してリンク数を確認できます。 OPTIMIZE TABLE
または myisamchk -r を使用すると、すべてのリンクを削除できます。