ターゲットテーブルにPKがないため、注文のメリットは見られないことをお勧めします。だから、それはあなたが見ている変換オーバーヘッドです。 PKがある場合でも、挿入時に585k行をソートする必要があります。 SQLは、それがセミソートされていることをどのように認識しますか？
これで、5,850 x 100行の挿入の場合、新しい行は「中央」ではなく「最後」に配置されるため、ページ分割とオーバーヘッドが削減されるため、いくつかの利点があります。
さらに進んで、この記事の日付は2002年で、SQL 2000に関するものであり、実際の生活に追い抜かれていると言えます。
SQL Server 2005には、厳密に単調なGUIDでいくつかの問題を解決できるようにするSEQUENTIALGUIDがあります。 PKとしてのGUIDもここで実行されています：最近の例：INTとUnique-サードパーティのリンクを持つデータベースのIDフィールドの識別子。
ORMがGUIDを自然キーや標準のintベースの代理キーではなくPKとして指定する場合、それはORMの重大な制限です。そして、クライアントの尻尾がデータベースの犬を振っているケース。