約 100 個のテーブルを持つ InnoDB ベースのスキーマがあり、ほとんどが主キーとして GUID/UUID を使用しています。ディスク IO とフラグメンテーションに関する UUID PK の影響をよく理解していなかった時点でこれを開始しましたが、サーバー クラスターを処理するときに単一のキー ディスペンサーを回避する利点が必要でした。現在、多数の行を扱っているわけではありませんが、（数億単位で）扱う予定であり、そのための準備をしたいと考えています。
InnoDB でのインデックス作成、特に主キーのクラスター化された性質をよりよく理解したので、私の UUID は DISK IO の観点からスケーラビリティの点で不適切な選択であることがわかりますが、サーバーが原因で UUID の使用をやめたくありません。クラスタリング要件。
受け入れられている/推奨される解決策は、オートインクリメント PK (INT|BIGINT) と UNIQUE インデックス付き UUID キーの組み合わせのようです。私の意図は、ai_col各テーブルに新しい最初の列を追加し、それを新しい PK として割り当てることです。次からキューを取得しています。
http://dev.mysql.com/doc/refman/5.1/en/innodb-auto-increment-handling.html
次に、UUID キーの新しい「UNIQUE」インデックスを更新/再作成し、アプリケーション層で引き続き使用します。
これが完了すると、基本的に を無視することができ、他のai_colすべては通常どおりに機能することを期待しています。InnoDB には、クラスタ化して他の一意のインデックスに追加する比較的小さな int ベースの PK があります。
質問 1:この新しいシナリオでは、ケーキを食べて食べることができると仮定して正しいですか?
フォローアップの質問は、より小さな「関連」テーブルに関するものです。つまり、2 つの列のみで、両方とも他のテーブルへの外部キーが暗黙的に結合されています。これらの場合、通常は 2 つのインデックスがあります。1 つは UNIQUE 2 カラム インデックスで、使用頻度の高いカラムが最初にあり、次にもう 1 つのカラムに 2 つ目の単一インデックスがあります。これは本質的に実際の行データの 2.5 倍の大きさであることはわかっていますが、最適化中のより複雑なクエリに実際に役立つようであり、小さなテーブルでは比較的許容できるものです。
これらの関連テーブルのほとんどは、通常はより具体的であるため、プライマリ テーブルのレコード数の一部に過ぎません。 .
質問 2:これらの表にも数値 PK を追加するのは良い考えですか? 答えは「ベンチテスト」に沿ったものになると思いますが、役立つ知恵の塊を探しているだけです。
私が何かを明らかに誤解している場合、または私が考慮していない可能性のある洞察を提供できる場合は、それも本当に感謝しています!
どうもありがとう！
編集:答えで約束されているように、興味のある人のためにフォローアップしたかっただけです...このソリューションは有名に機能しました:)読み取りと書き込みのパフォーマンスは全体的に向上し、これまでのところ約60億回のI/Oまでテストされています/月、汗をかくことなく。