データベース内の削除されたレコードの数値主キーは、将来の新しいレコードに再利用されますか?
-
05-07-2019 - |
質問
たとえば、自動採番されたフィールドがある場合、このフィールドを指定せずに新しいレコードを追加し、DBエンジンにそれを選択させます。
それで、削除されたレコードの番号を選択しますか?はいの場合、いつですか?
// SQL Server、MySQL。 //
フォローアップの質問:主キーに使用する数値がDBエンジンで不足するとどうなりますか?
解決
いいえ。手動で指定する場合を除き、数値主キーは再利用されません(これは実際に避けてください!)
他のヒント
わかりました、これはMySQLで発生する可能性があります :
InnoDBは、サーバーが実行されている限り、メモリ内の自動インクリメントカウンターを使用します。サーバーを停止して再起動すると、InnoDBは、前述のように、テーブルへの最初のINSERTのために各テーブルのカウンターを再初期化します。
サーバーの再起動後。 Innodbは以前に生成されたauto_increment値を再利用します。 :
推奨される修正: innodbテーブルは、auto_increment列の次の番号のトラックを失わないはずです。 再起動します。
自動採番システムに依存します。任意の種類のシーケンスを使用している場合、削除されたレコードの数は再認識されません。シーケンスがそれらを認識していないためです。
通常、いいえ、番号は再利用されません。
ただし、Oracleなどの製品では、循環して番号を再利用するシーケンスジェネレーターを指定できます。
これらが削除されたレコードの数であるかどうかは、アプリケーションの問題です。
この質問は、より正確にする必要があります:
..." with Oracle Sequences"
..." MySQL自動番号列を使用する"
...など...
テーブルを正しく作成する限り、番号を再利用しません。 ただし、次を使用してID列を再シードできます(とにかくMSSQLで)。
-次に使用する番号ではなく、テーブル内の最後の有効なエントリの番号を入力します
DBCC CHECKIDENT([TableName]、RESEED、[NumberYouWantToStartAt])
これはもちろん正気ではありません...決して実行すべきではありません:)
MySQLは、 where
句のないテーブルを truncate
または delete
しない限り、IDを再利用しません(この場合、MySQLは内部的に、単に truncate
)を実行します。
特にありません。キーがシーケンスまたは自動インクリメントID列から読み取られている場合、シーケンスはプラグインし、次の値を生成します。ただし、これを無効にして(SQL Serverで identity_insert on
を設定)、一意性制約に違反しない限り、任意の番号を列に入力できます。
ええ、それは本当にidの生成方法に依存します。
たとえば、GUIDを主キーとして使用している場合、ランダムな新しいGuidを取得するほとんどの実装は、別のGUIDを再度選択する可能性は低くなりますが、十分な時間を与え、GUIDがテーブルにない場合は挿入しますステートメントは正常に動作しますが、既にGUIDが存在する場合は、主キー制約違反が発生します。
MySQLの「機能」を検討します; idの再利用はバグです。
ファイルのアップロードの処理などを検討してください。データベースIDをファイル名として使用することをお勧めします。シンプルで、ユーザーが指定したファイル名などを悪用するリスクはありません。
ファイルシステムが関与する場合、すべてをトランザクション対応にすることはできません...データベーストランザクションをコミットしてからファイルを書き込むか、ファイルを書き込んでデータベーストランザクションをコミットする必要がありますが、一方または両方が失敗した場合、または、クラッシュした場合、またはネットワークファイルシステムに適合した場合、データベースに有効なレコードがあり、ファイルがないか、データベースレコードのないファイルがあります。これはアトミックではないためです。
このような問題が発生し、サーバーが戻ってきたときに最初に行うことは、ロールバックされたトランザクションのID、つまりファイルを上書きすることです。これらのファイルは役に立つかもしれません。
いいえ、銀行がaccount_idを再利用することに決めた場合を想像してください-arghhhh !!