回答:
通常、varcharsではなく整数を使用します。スペースを消費せず、ソートパターンがインデックス付けなどに高速であることをよく理解しているためです。整数はCPUの自然なデータ型であり、したがってパフォーマンスは一般的に最適です。通常、整数は4バイトで、（非Unicode）varcharの4文字だけに相当します。
INT型でスペースが不足することが心配な場合は、BIGINTを試してください。8バイトの数値が得られます。これの制限は非常に大きく、そのレコードの制限に達する前におそらくディスク容量が不足するでしょう:-) BIGINTのパフォーマンスも非常に良くなります。特に多くのサーバーが64ビットになっているためです。 。
特にデータ型をBIGINTに変更せずに言ったように、INTを使い果たしたときに何が起こるかについての質問の最初の部分に対する答えは簡単ではありません。基本的に、できることはあまりありません。できることは、データベース内のデータの性質によって非常に制限されています。このデータの外部キーはどのレコードですか？そのテーブルのすべてのデータと関連レコードがまだ必要ですか？多くの初期データ（およびその関連データ）をアーカイブできると仮定した場合、提案できる唯一のことは、データをテーブルから移動することです（最初の1〜100万レコードを言う）。 IDシードを1にリセットします。さまざまな理由がありますが、それはお勧めしませんが、たとえば、idフィールドの最大値をチェックするなど、コードの多くのビットがあります。追加されたばかりのものを確認するために、それは機能しません（実行すべきではありません）。また、人々は、レコードNがN + 1の前に作成されたと仮定します。簡単な答えはないと思います。
最後に、MySQLについては知りませんが、制限に達するとSQL Serverはオーバーフローエラーを返します。
見落とされがちな点の1つは、多くの人が自動番号またはIDを1から開始するため、可能な範囲の半分がすぐに失われることです（署名済みの場合）
この場合、-1から始まるように単純に番号を再定義します。
おそらく、ID列を埋めることを期待している場合は、最初にこれを設計し、より広いデータ型を使用する必要がありました。
この最近の質問をご覧くださいSO：SQL Server 2008：IDがintの最大値を超えた場合はどうなりますか？
オーバーフローBIGINT？ハハ。最初に不滅を達成する方法を見つけてください。INT UNSIGNED（40億）は到達するのに十分困難です。1秒あたり100のINSERTは、1年でINTのオーバーフローに近づきます。BIGINTには数十億年かかります。
修正するには：ALTER TABLE foo MODIFY COLUMN id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT; しかし、テーブル（40億行近くあります）をコピーし、すべてのセカンダリインデックスを再構築するため、これには数時間かかります。計画アヘアd。
一般に、フィールドに対して大きすぎる数値（たとえば、TINYINT UNSIGNEDの999）を保存しようとすると、フィールドの最大値（この場合は255）に暗黙のうちに上限が設定されます。「警告」があるかもしれませんが、ほとんどの人は警告を確認することを気にしません。UNIQUEフィールドの場合、または外部キーがある場合、より深刻なエラーが発生する可能性があります。
CHARまたはVARCHARは、使用可能なスペースに切り捨てられます。