主キーにintの代わりにtinyintを使用することのパフォーマンス上の利点はありますか？
このテーブルで行数が制限されていることがわかっているが、このキーが別の巨大なテーブルで外部キーとして使用されることがわかっている場合、主キーにintではなくtinyintを使用するとパフォーマンス上のメリットがありますか？ （クエリでは多くの結合を使用します）私はMySQLを使用しています。たとえば、これは私のモデルの一部です：
はい、TINYINTとINTを使用するとパフォーマンスが向上します。
ディスク上のスペースを最小限に抑えるようにテーブルを設計します。これにより、ディスクに読み書きされるデータの量が減り、大幅な改善が可能になります。小さなテーブルは通常、クエリの実行中にその内容がアクティブに処理されている間、必要なメインメモリが少なくなります。また、テーブルデータのスペースを削減すると、インデックスが小さくなり、より高速に処理できます。
documentation のページ全体を読み、さらに詳しい情報を得るためにその段落を抜粋します。
特定のケースでは、会社テーブルでINTではなくTINYINTを使用すると、プロジェクトテーブルの外部キーは8ではなく5バイトになります。これは、すべてのセカンダリキーにテーブル自体のプライマリキーが含まれているためです-これ主キーレコードを検索して詳細情報を取得できるようにするためです。 （これにより、クラスター化インデックス、インデックスのカバー、およびダブルルックアップについての議論につながります。）
したがって、この外部キーを会社のテーブルに結合またはフィルタリングする場合は、各インデックスエントリに5/8分のスペースを使用します。つまり、1あたり約8/5のスペースを確保できます。ページルックアップ。つまり、特定のクエリを処理するためにメモリにロードする必要のあるページが少なくなります。
一般に、小さいほど常に優れています。それ自体はディスク領域の使用量ではなく、結合とWHERE句フィルターのためにデータをメモリにロードする必要がある場合に使用します。
とはいえ、TINYINTは非常に小さいです。 256社を超える企業が必要になることはありませんか？私の経験則では、レコードの数を推測し、10倍以上のデータ型を選択します。どうして？なぜなら、人々は将来のユースケースの推定と予測の両方が得意ではないからです。 SMALLINTまたはMEDIUMINTを使用すると、将来の切り替えの手間を省くことができます。
したがって、小さいが、すぐに（またはできれば、いつでも）変更する必要がないように十分な大きさにしてください。