データベースにあった効率なフィールドの書き方？

質問

MySQL4とMySQL5を使っています。
データベース不慣れで、言葉や考え方が間違っているかもしれませんが、

例えば以下のようなフィールドを持つテーブルがあり、
どちらがデータベースにとって効率良い（スピードやDBサイズ）
のでしょうか？

例１）1レコード128バイト
bigint position
zyusyo char(120)

例２）１レコード256バイト
bigint position
zyusyo char(248)

MySQLに限らず、他のDBもフィールドの定義仕方で効率が変わることは、あるのでしょうか？

このようなことはDBチューニング？というものでしょうか？
語彙不足で申し訳ありません。

回答No.2

chukenkenkou · ベストアンサー

例が悪すぎます。
char(120)で管理できるものを、char(248)と定義するなら、無駄なスペースを作ることになります。
char(248)が必要なものを、char(120)で管理するなら、全情報を得る場合は複数行の検索が必要になります。

１．ページと行長
　多くのRDBMSは、ページといった単位でI/Oを行います。行長が短ければ、このページ内に複数の行を格納できます。行長が長ければ、ページ内に格納できる行数が少なかったり、使われないスペースが増えます。
複数行を順次検索するような操作が多いなら、ページ内の格納行数が多ければI/O回数を減らせますが、ランダム検索するような操作が主体なら、I/O回数は減らせません。
また、ページ内に複数行が格納されている場合、RDBMSによる排他制御が行単位ならいいですが、ページ単位の場合は異なる行を操作しているのに、排他制御で待ちになることがあります。

２．固定長列と可変長列
　可変長列を使えば、無駄なスペースを持たずにすみます。また、非常に長いデータを持つこともでき、RDBMSによってはページ長を超える場合でも、複数ページに分割格納してくれます。しかし、分割格納されるということは、1行の操作で複数回のI/Oが発生することになります。また、インデクスを付けたり、ソートやグループ化などが行える列長に上限がある場合が殆どなので、無闇に長いデータ型を使うべきではありません。
　RDBMSによっては、表の構成列が固定長のみの場合は、内部的なスペース管理が簡単になることなどで、大幅な性能向上ができるものもあります。

３．列数
　SQLでは列単位で操作できる一方で、多くのRDBMSでは、列数が多くなると、CPU使用時間が長くなり極端に性能劣化します。そのため、正規化だけでなく、無闇に細かな列をたくさん作るのは、十分に注意が必要です。

>このようなことはDBチューニング？というものでしょうか？

これらは、DBの論理設計や物理設計の範疇です。

回答No.1

Tasuke22

テーブルは小さいほうが効率的であることは間違いありません。
効率の小さな問題はDBのマネージャが頑張っているので、開発者
はあまり意識する必要は無いと思います。

寧ろ、分かり易さ、テーブル設計における拡張性などを最初は
意識するべきでしょう。
拡張性は、初期段階では効率が悪いように思えますが、DBのフィ
ールドやテーブルががどんどん増えたりするようなシステムでは、
将来的な効率の悪化が抑えられます。