私の仕事では、PKとしてUUIDを使用しています。経験から言えることは、PKとして使用しないでください（ちなみにSQL Server）。
これは、レコード数が1000未満の場合は問題ありませんが、数百万の場合は最悪の事態です。なんで？ UUIDはシーケンシャルではないため、新しいレコードが挿入されるたびに、MSSQLはレコードを挿入する正しいページを確認してから、レコードを挿入する必要があります。これによる本当に醜い結果は、ページがすべて異なるサイズになり、断片化されることです。そのため、定期的に断片化解除を行う必要があります。
自動インクリメントを使用すると、MSSQLは常に最後のページに移動し、（理論的には）同じサイズのページになるため、これらのレコードを選択するパフォーマンスが大幅に向上します（また、INSERTがテーブル/ページをブロックしないため）とても長いです。
ただし、UUIDをPKとして使用することの大きな利点は、DBのクラスターがある場合、マージ時に競合が発生しないことです。
次のモデルをお勧めします：1。 PKINTIdentity2。 UUIDとして自動的に生成される追加の列。
このようにして、マージプロセスが可能になります（UUIDはREALキーになりますが、PKはパフォーマンスを向上させる一時的なものになります）。
注：最善の解決策はNEWSEQUENTIALIDを使用することです（コメントで言ったように）が、リファクタリングする時間があまりない（さらに悪いことに、すべての挿入を制御しない）レガシーアプリの場合、それは不可能です。 2017年の時点で、ここでの最善の解決策はNEWSEQUENTIALIDか、NHibernateでGuid.Combを実行することだと思います。
これがお役に立てば幸いです