値が255を超えないことがわかっているときにtinyintフィールドを設定することには利点がありますか？

Question

可能な限り最小のデータ型を選択する必要がありますか、たとえば値1を格納している場合、colデータ型が何であるかは関係なく、値は同じメモリサイズを占有しますか？

質問もあります。なぜなら、私は常にそれを変換し、アプリケーションで遊んでいる必要があるからです。

---

更新

値が「a」の場合、varchar（1）とvarchar（50）は同じメモリサイズだと思いますが、intとtinyintでも同じだと思いましたが、そうではないと理解しています回答ではないですか？

Answer 1

可能な限り最小のデータ型を常に選択します。 SQLは最大値を予測することはできませんが、データ型を指定するとストレージとパフォーマンスを最適化できます。

---

更新に回答するには：

varchar は、使用するスペースと同じだけのスペースを使用するため、文字「a」が選択した varchar フィールドの大きさに関係なく、1バイト（ラテンエンコード）を使用します。 SQLの他のタイプのフィールドには当てはまりません。

ただし、すべてをvarcharフィールドにすると、スペースの効率が犠牲になる可能性があります。すべてが固定サイズのフィールドである場合、SQLは単純な定数時間の乗算を実行して、値（配列など）を見つけることができます。そこにvarcharフィールドがある場合、データが保存されている場所を見つける唯一の方法は、リンクされたリストのように、以前のすべてのフィールドを通過することです。

SQLを開始している場合、テキストが非常に少なく、ブログ投稿などのテキストが非常に多いフィールドがある場合を除き、varcharフィールドには近づかないことをお勧めします。可変長フィールドを最適な状態で使用するタイミングを知るには経験が必要であり、私もほとんどの時間を知りません。

Answer 2

これは、システムの設計に特有のパフォーマンスの考慮事項です。一般に、SQL Serverデータのページに収まるデータが多いほど、パフォーマンスが向上します。

SQL Serverの1ページは8kです。 intの代わりに小さなintを使用すると、より多くのデータを1つのページに入れることができますが、それだけの価値があるかどうかを考慮する必要があります。 1分間に数千のヒットを提供する場合は、はい。これが趣味のプロジェクトまたは数十人のユーザーにしか見られないものであれば、それは問題ではありません。

Answer 3

利点はありますが、多くの行があり、操作のロスを実行しない限り、重要ではないかもしれません。パフォーマンスが向上し、ストレージが小さくなります。

Answer 4

伝統的にページサイズで保存されるすべてのビットは、少し速度が向上することを意味します。狭い行はページあたりの行数が増えることを意味し、メモリ消費量とIO要求が少なくなり、速度が向上します。ただし、SQL Server 2008では、ページ圧縮があいまいになり始めます。圧縮アルゴリズムは、1バイト未満でも255未満の値を持つ4バイト整数を圧縮する場合があります。

行圧縮アルゴリズムは、4バイトのintを127（intは符号付き）未満の値の場合は1バイト、32768未満の値の場合は2バイトなど。

ただし、優れた圧縮機能はEnterprise Editionサーバーでのみ利用可能であるため、可能な限り最小のデータ型を使用する習慣を維持することは理にかなっています。