Je dirais que vous ne voyez pas l'avantage de la commande car la table cible n'a pas de PK. Donc, c'est la surcharge de conversion que vous voyez. S'il a un PK, les lignes de 585k doivent toujours être triées lors de l'insertion. Comment SQL sait-il qu'il est semi-trié ?
Maintenant, s'il s'agissait d'insertions de lignes de 5 850 x 100, vous constaterez peut-être un avantage, car les nouvelles lignes iront "à la fin" et non "au milieu", ce qui réduira les fractionnements de page et les frais généraux.
J'irais plus loin et dirais que l'article date de 2002, qu'il concerne SQL 2000 et qu'il a été dépassé par la vraie vie.
Dans SQL Server 2005, nous avons des GUID SEQUENTIELS pour permettre aux GUID strictement monotones de résoudre certains problèmes. Le GUID en tant que PK a été fait ici aussi :exemple récent :INT vs Unique-Identifier pour le champ ID dans la base de données avec des liens tiers.
Si un ORM dicte GUID en tant que PK plutôt qu'une clé naturelle ou une clé de substitution standard basée sur int, il s'agit d'une limitation sévère de l'ORM. Et un cas où le client remue la queue du chien de la base de données.
