1

PK がオーバーフローする可能性がある場合に対応するにはどうすればよいですか?

可能性は低いですが、それでも可能です。おそらく多くのリクエストがあったため、ニュースレターのオプトアウト フォームが機能しないのを見たことがあります。

アプリケーション側で何ができますか? MySQL でできること

4

2 に答える 2

3

PKがオーバーフローする可能性がある場合に対応するにはどうすればよいですか？

簡単な解決策は、PKのタイプが十分に大きく、妥当なユースケースでオーバーフローが発生しないようにスキーマを設計することです。

その仮定が失敗した場合は、問題があります。私はいくつかの可能なオプションを考えることができます。

  • PKタイプを「より大きな」タイプに変更し、アプリケーションを変更してデータを移行します。

  • キースペースを「コンパクト」にするアプリケーションを作成します。つまり、ライブキーごとに、キーを使用するすべてのレコードを更新して、新しいキーに置き換えます...スペースの先頭から開始します。

  • キースペースをラップし、より複雑なジェネレーターを使用して、各候補キーがまだ使用されていないことを確認する次のキーを取得します。

この種のものは、特に予測が難しく、テストが難しいため、通常はシステムに組み込まれていないことに注意してください。

于 2013-03-04T06:06:28.207 に答える
2

私は、32 ビットの INT がオーバーフローした 1 つのケースに取り組みました。これは、行の挿入が成功するたびに、アプリが誤って 1000 個の値をスキップしていたためです。その場合、アプリは最大の符号付き INT 値に達し、そのテーブルでそれ以上の挿入を行うことができませんでした。BIGINT 主キーを使用するようにテーブルを再構築するのを手伝うために、私が呼ばれました。

しかしもちろん、それを行う前に、参照テーブルのすべての外部キーも BIGINT を使用するように変更する必要がありました。他のテーブルの FK によって参照できなかった新しい PK 値をメイン テーブルに挿入したくないためです。

新しい行を挿入するたびに 10 億の値をスキップしない限り、BIGINT の値の範囲を使い果たすには、私たちの寿命よりも長くかかるはずです!

特定のデータベース内のすべての AUTO_INCREMENT PRIMARY KEY を調べ、オーバーフローにどの程度 (パーセンテージで) 近いかを計算する pk-full-ratioというスクリプトを作成しました。

于 2013-03-04T06:28:14.927 に答える