sql - SQL：最大値が255の場合、整数の代わりにtinyintを使用するのは効率的ですか？

Question

最大になる可能性のあるデータグリッド行の数を保存したいとします。各行が1時間であるため、24。

データベースに行インデックスを保存するには、tinyintフィールドで十分です。しかし、私の心に戻って、データベースが整数用に最適化されていることを少し覚えていますか？！

では、tinyintを使用する価値はありますか？

Answer 1

テーブルが狭くなると、データベースは1つのIOページにより多くのレコードを収めることができるため、必要なハードディスクの読み取りが少なくなります。

経験則では、必要なストレージサイズが最小になるデータ型を常に使用します。

Answer 2

Tinyintは整数であり、TINYINTはINTデータ型（4バイト）よりも少ないバイト（1バイト）を使用するため、INTよりも高速です。

参照：

• int、bigint、smallint、およびtinyint（Transact-SQL）

Answer 3

一般に、ディスク (またはメモリ) 上の単一の 8k I/O ページに収まる行が多いほど、データの検索および/または取得に必要な I/O が少なくなるため、スペースが少ないほど良いです...これは特に重要です。インデックスで使用される列用。ただし、マシンがたとえば 32 ビット マシンであり、32 ビット OS を実行している場合、独立してアドレス指定できる最小のメモリ チャンクは 32 ビットであるため、これがテーブル スキーマ内でより小さい唯一の列である場合32 ビットよりも大きい場合は、データの各完全な行が 32 ビット境界で開始および終了する必要があるため、問題ではありません。したがって、各行は 32 ビット幅の倍数である必要があります。

つまり、テーブルが

MyTable(ColA tinyint, ColB Int, ColC DateTime) 次に、各行は 16 バイト (128 ビット) を取り、24 ビットが無駄になります。

一方、tinyInts である可能性のある 4 つの列がある場合は、必ずそれを使用してください。SQL サーバーはそのうちの 4 つをディスク上の 1 つの 32 ビット ストレージの場所に配置します (それらを宣言する順序に関係なく)。

64 ビット OS/CPUbB で実行される 64 ビット SQL Server にも同じ原則が適用されます。

Answer 4

tinyint

スペースが少ない方が良いです。