問題を考えています。
C 言語では、構造体のサイズは 2 バイトの倍数であることが推奨されています。
式:
struct text{
int index;//assume int is 4 byte.
char [8] word;
}//alought text is only 12 bytes, compiler would assign 16 bytes for this struct
したがって、MySQL のレコード サイズ (Gordon Linoff さんに感謝) でも同じ問題が発生するのでしょうか?
さらに、テーブルサイズを制御して MySQL を最適化するにはどうすればよいですか?
まず、テーブル サイズではなく、レコードサイズを参照しています。
第二に、データベースは手続き型言語のようには機能しません。レコードはページに保存され、ページが収まらなくなるまで埋められます。その後、追加のページが使用されます。通常、ページには多くのレコードがあります。
ここで、ページがどのように見えるかを把握できます。それらは複雑ですが、基本的にユーザーから隠されています。
「時期尚早の最適化」を試みているようです。これがすべての悪の根源というわけではありませんが、物事を成し遂げる上で大きな妨げとなります。つまり、必要に応じてレコードを定義します。勝手にすればいい。パフォーマンスに問題がある場合は、問題が発生した時点で修正してください。
レコードのサイズは、問題の中で最も少なくなります。データベースはページ単位で I/O を行うため、1 つのレコードに対して 12 バイトと 16 バイトの違いは意味がありません。まだページ全体を読む必要があります (はるかに大きい)。