ID列の再シード：必要な場合

大学（私は学生です）での最後のレッスンの1つで、講師から、データベース（必要に応じてMySQLサーバー）と、データベースをデータソースとして使用する小さなクライアントアプリを開発するように依頼されました。

要件の1つは、ID列（すべてのテーブルのPK）が連続している必要があることです。つまり、テーブル行が削除された場合、そのPKは後続の挿入で再利用する必要があります。RDBMS、PK、およびID列に関する平均的な知識があります。私が理解していることから、そのID列は、行を挿入するときにDBがPKを自動生成できるようにするための手段にすぎません。また、ID列の値は、（自然キーではない限り）行属性とは一切関係しません。

この要件（厳密に連続したID列）は私には不審でした。IDがシーケンシャルでない（削除によるギャップがある）場合、何が悪いのかを講師に尋ねてみましたが、「ユーザーにとっては便利であり、データベースを保守するDB管理者にとっては便利」という非常に抽象的な回答を得ました。具体的な例はありません。「ユーザーにとって便利」という議論は、ビジネスドメインでは何の意味もないため、ばかげているように思われます。

したがって、これらの理由が本当かどうか知りたいのですが。ID列を再シードする必要がある場合、つまりIDスペースが使い果たされた場合の1つだけを考えることができます。ただし、これは、ID列のタイプが誤って選択された場合int、bigintつまりuniqueidentifierテーブルに10億行が含まれている代わりに、または単純である場合に、より設計上の問題になります。ID列がクラスター化インデックスであるとします。ID列のギャップがインデックスのパフォーマンスに影響を与える可能性はありますか？多分私が知らない削除ごとに自動ID列が再シードされる実際の理由は他にもありますか？

前もって感謝します！

つまり、テーブル行が削除された場合、そのPKは後続の挿入で再利用する必要があります。

あなたの講師はどの宇宙から来ましたか？

それは非常に非効率的です。これを行おうとすると、パフォーマンスの見通しが10分の1になります。

監査の理由でギャップのない数値が必要な場合は、データベースツールから直接ではなく、明示的に作成してください。また、行を削除することはありませんが、「削除済み」としてフラグを付けます。このような行は無視する必要があるため、クエリの煩雑さが増します。

MySQLでは、InnoDBはPRIMARY KEY各テーブルに一意の存在が必要です。しかし、それは要件の範囲です。キーは文字列にすることもできます。

ギャップはユーザーとDBA にとって便利であり、不便ではありません。

ギャップレスが便利な1つのケースを考えることができます-一度に100行のグループにチャンク化します。ただし、を使用する簡単な回避策がありLIMIT 100,1ます。

ギャップはパフォーマンスに影響を与えません。これには非数値インデックスが含まれます。そして非ユニークなインデックス。そして複合インデックス。

もちろん、IDが不足する可能性があります。MySQLを使用してから20年近くの間に2回発生することを見たと思います。小惑星にぶつかる心配もあるでしょう。それは私のもの、つまり私に起きている夜の目覚めのリストには載っていません。

：ギャップは、（少なくとも）から発生し INSERT IGNORE、IODKU、REPLACE、DELETE、ROLLBACK（ガレラおよびグループのレプリケーションを含む）（明示的、またはクラッシュによる）、マルチマスターレプリケーション。それらの回避策を本当に考えたいですか？

講師が疑わしいと言っているものは何でも正気チェックしてください。

ID値の再利用は、一般的にお勧めできません。値は完全に内部で使用されます。その場合、実際の値は重要ではありません。または、外部で使用される場合、値を再利用すると誤認が発生する可能性が高くなります。

請求書または注文番号の明らかなケースを考えてみましょう。これらは簡単にID列から取得されて外部に公開される可能性がありますが、その理由でそれらを再利用することは決してありません。どちらも、混乱させたくない特定のトランザクションを指します。

このような問題を解決することは、企業が合併または買収されたときに大きな手間がかかります。意図的にそのような問題を作成しますか？賢くない。

PK id値の再利用には問題があり、通常は回避する必要があります。

まず、auto_incrementカラムの実装では、ギャップがないことが保証されません。実際、自動インクリメント列で挿入をロールバックすると、ギャップが発生します。

次に、ギャップIDは、削除されていない既存のデータを参照している可能性があります（FK制約がないため）。それらがシステムの外部で通信されるメンバー番号に変換される場合、それは潜在的なビジネスIDリスクをもたらします。

3番目に、bigint unsigned挿入率が非常に高い場合でも、IDが長時間不足することはありません。

ギャップの最大の問題は、監査の欠陥を主張する監査人に出くわすことです。DBAにとって、彼らはギャップが存在することとその理由を知っています。

PKを再利用することは悪い考えであるという他の人のコメントをエコーすることはしませんが、ID列を再シードする必要がある場合があります。

PKインデックス自体の破損。

確かに、これはMS-SQLを使用しており、何年も前に使用されていましたが、それでも適切です。何年も前に私が働いている会社では、クライアントが使用するには古すぎてPCをクローゼットに貼り付けた後、150以上のリモートロケーションのサーバーとしてPCを再利用することをお勧めします。換気なし。120以上の温度のミッションクリティカルなデータベースが実行されている小さな部屋にある、10年前のジャンクコンピュータが山に積まれても、良い結果が得られることは誰もが知っているからです。40％の失敗率のように、私は私のキャリアの選択を再考します。データを本社に複製しますが、多くの場合、これらの障害はデータベースに悪影響を及ぼすことになります。それらの1つは、データベースとレプリケーションプロセスを占有する破損したインデックスを持つデータベースでした。この素晴らしい環境で2回、レプリケーションを修正する唯一のソリューションは、インデックスを再シードしてからレプリケーションを再確立することでした。サーバーを完全に破棄する前に、後でサーバーを交換しました。