文字列またはintは外部キーに適していますか？

状況によって異なります

多くの既存のディスカッションがありますナチュラルキーとサロゲートキーの間のトレードオフについて -何が効果的で、組織内の「標準」は何かを決定する必要があります。

OPの場合、代理キー（int userId）の両方があります）と自然キー（char またはvarchar username ）。どちらの列もテーブルの主キーとして使用でき、どちらの方法でも、もう一方のキーの一意性を強制できます。

いずれかの方法を選択する際の考慮事項は次のとおりです。

代理キーを使用する場合（例：UserId INT AUTO_INCREMENT）

サロゲートを使用する場合（例：UserId INT AUTO_INCREMENT ）を主キーとして、テーブルMyUsersを参照するすべてのテーブル次に、UserIdを使用する必要があります外部キーとして。

ただし、usernameの一意性を強制することはできます追加の一意のインデックスを使用した列例：

CREATE TABLE `MyUsers` (
  `userId` int NOT NULL AUTO_INCREMENT,
  `username` varchar(100) NOT NULL,
  ... other columns
  PRIMARY KEY(`userId`),
  UNIQUE KEY UQ_UserName (`username`)

@Dagonによると、狭い主キー（intなど）を使用します）varcharのようなより広い（そして可変長の）値を使用するよりもパフォーマンスとストレージの利点があります。この利点は、MyUsersを参照する他のテーブルにも影響します、useridへの外部キーとして狭くなります（フェッチするバイト数が少なくなります）。

サロゲート整数キーのもう1つの利点は、MyUsersを参照するテーブルに影響を与えることなくユーザー名を簡単に変更できることです。。usernameの場合自然キーとして使用され、他のテーブルはMyUsersに結合されています username経由、ユーザー名を変更するのは非常に不便です（外部キーの関係が侵害されるため）。 usernameを使用してテーブルでユーザー名を更新する必要がある場合外部キーとして、 ON UPDATECASCADE のような手法データの整合性を維持するために必要です。

自然キー（ユーザー名など）を使用する場合

サロゲートキーを使用することの1つの欠点は、MyUsersを参照する他のテーブルです。代理キーを介してJOINである必要があります MyUsersに戻ります Usernameの場合はテーブル列が必要です。自然キーの潜在的な利点の1つは、クエリにUsernameのみが必要な場合です。 MyUsersを参照するテーブルの列、MyUsersに再度参加する必要はありませんユーザー名を取得します。これにより、I/Oのオーバーヘッドがいくらか節約されます。