データベースは主キーを自動的にインクリメントしますか?

1 すべてのテーブルに自動インクリメント主キーが必要ですか?

必ずしもそうとは限りません
主キーの自動インクリメントにより、行の挿入が高速化され、表スペースの使用率が向上し、断片化が目立たなくなります。

ただし、非常に頻繁で比較的集中している uid に基づくクエリなど、一部のコンテンツでは、主キーの自動インクリメントを使用せず、複合主キーとして uid+id を使用すると、クエリ効率が向上します。ただし、挿入と断片化が増加します。ただし、データベースのストレージ タイプが SSD の場合、この問題は発生しません。

したがって、ほとんどの場合、テーブルに自動インクリメント主キーがあるのは正しいことです。

2 自動インクリメントされる主キーのビジネスは独特ですか?

必ずしもそうとは限りません

単一テーブル構造では、はい。

複数のテーブルの場合、異なるサフィックスを設定する、同じ間隔を設定するなど、特定の戦略は必ずしも必要ではありません。

3 自己増加する主キーはビジネスに影響を与える可能性がありますか?

これはお勧めできません。

例: テーブルには、テーブル内で一意の自動インクリメント主キーを持つことができます。 idに基づいて問い合わせや更新を行う場合、操作を簡略化できます。ただし、一般的に、ビジネスとの関係があり、一意性が必要な場合は、フォーマットやアルゴリズムの使用、ハッシュ生成など、ビジネスが独自に維持する必要があります。

4 複数のテーブルの場合に、ビジネスによって維持される主キーの一意性を維持するにはどうすればよいですか?

自動インクリメントキー間隔セグメントを維持し、サーバーは毎回 1 つのセグメントを取得し、楽観的ロックが更新されます。これには、このフィールドを維持するための追加のテーブルまたは戦略が必要です。

アルゴリズム A に基づいて、yyyyMMddHHmmss + テーブル番号の修正値 + 乱数などの固定時間プレフィックスを使用し、桁数を増やすことで競合の可能性を減らします。テーブル フィールドには一意の制約があります (ただし、この制約が信頼できない場合もあります)。挿入中に重複フィールド値の例外がスローされた場合、挿入は再生成されます。

アルゴリズム B に基づいており、yyyyMMddHHmmss+固定桁数、衝突自動インクリメント値 N+乱数などの固定時間プレフィックス。競合の可能性を減らすためにビット数を増やす必要はありません。挿入によって重複フィールド値の例外がスローされると、N++ は競合がなくなるまで再挿入を行います。これ以降、N は接頭辞として使用され、N はサーバー上にキャッシュされ、再起動後も引き続き使用されます。繰り返し例外が発生する場合は、再度 N++ で同じ操作を実行してください。 N の mod 値については意図的に言及する必要はありません。

インフィックス管理、つまり中央サーバーにインフィックスを報告することに基づいて、サーバーの ID 関係がどこかにキャッシュされ、インフィックスが動的に割り当てられることがわかります。

他にも多くの方法がありますが、これまで使用されたことがないため、詳細は説明しません。
アルゴリズム B は単純で、通信量が少なく、衝突の数も限られています。アルゴリズム A では、衝突の回数は無限にありますが、その割合は非常に低いです。ただし、同時実行性が高い場合、初期化中にアルゴリズム B の方がアルゴリズム A よりも激しく動作します。

インターバルセグメントとインフィックス管理はどちらもセントラルノードの概念を導入しています。セントラルノードは依存性は高いですが比較的信頼性が高く、業界でより一般的な実装方法です。

以上がデータベースは主キーを自動的にインクリメントしますか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。