Comment éviter le syndicat dans SQL Server pour cette requête?

Dans cette première requête, vous obtenez UserID, dans Secon Requête, vous ne recevrez pas d'utilisateur. Par conséquent, cet ensemble de résultat est unique. Donc, vous pouvez utiliser un syndicat tout.

Select U.UserId, A.ActivityPlace From UserTable U
Inner Join MasterTable  M ON M.Id=U.UserId
Inner Join ActivityTable A ON A.ActivityID=M.UserId
Where M.Id<>0

Union all

Select '', A.ActivityPlace From MasterTable  
M Inner Join ActivityTable A ON A.ActivityID=M.UserId
Where M.Id=0

Je pense que vous pouvez faire ci-dessous

Select 
U.UserId, A.ActivityPlace 
From 
UserTable U
Inner Join 
MasterTable M ON (M.Id = U.UserId or M.Id = 0)
Inner Join 
ActivityTable A ON A.ActivityID = M.UserId

Je pense que je recommanderais:

Select m.Id as UserId, A.ActivityPlace 
From MasterTable M left join
     UserTable U  
     on M.Id = U.UserId left join
     ActivityTable A 
     on A.ActivityID = M.UserId;

• Le Union code> n'élimine pas réellement les doublons. LI>
• null code> est un remplacement raisonnable pour '' code>. li>
• Tous sauf 0 code> ID utilisateur correspondent à li> ul>

  alors il devrait faire ce que vous voulez. En fait, pour la troisième condition, vous pouvez ajouter: p> xxx pré>

  en fait, je suppose que le traitement spécial pour m.Id = 0 code> est simplement parce que Il n'y a pas d'utilisateur. Dans ce cas, vous voulez juste Joindre de gauche CODE> S: P>

  where m.id = 0 or u.userid is not null
  

J'ai une déclaration syndicale dans la requête qui doit éliminer comme son Performance frappé à cause des millions d'enregistrements trouvés ci-dessous Tables.

Comment puis-je atteindre l'utilisation de la join gauche afin que la performance ne soit pas compromis?

Malheureusement, vous n'avez fourni aucun Informations utiles , à côté du fait que vous avez des millions d'enregistrements dans certaines tables.

Voici quelque chose qui nous aurait aidé à reproduire votre problème et à déterminer une solution possible:

• Postage de la structure complète des tables, y compris les index
• montrant quelques échantillons de données
• Afficher un exemple indiquant les résultats attendus

  La réponse évidente est la suivante: vérifiez le plan d'exécution et si vous ne le comprenez pas, postez-le avec les informations mentionnées ci-dessus.

  J'ai peur que les réponses que vous obteniez sont spéculatives. Malgré les meilleurs efforts des participants, rien ne garantit que l'une de ces réponses traitera de votre problème de performance de manière adéquate . Il n'y a tout simplement pas assez d'informations.

  Les réponses que vous avez sont bien racontées:

  • "Vous pouvez essayer de déplacer la condition dans l'expression de cas"
  • "Je pense que je recommanderais"
  • "Je pense que vous pouvez faire ci-dessous"

    Ne blâmez pas les membres, vous n'avez pas donné suffisamment de détails utiles pour tout ce qu'ils peuvent faire est devinez .

    Un astuce De toute façon: Vérifiez vos index , en particulier sur les champs Joindre ED ensemble. Étant donné que vous utilisez SQL Server, vous pouvez consulter ce guide, par exemple: Assurez-vous que toutes les colonnes de jointure sont indexées . Ce conseil est également valable pour d'autres dbses relationnels, bien que chacun ait sa propre optimisation de la requête et ses particularités.

    Je suis en fait surpris que personne ne vous a posé sur vos indices . Très souvent, il est en effet possible de réécrire une instruction SQL existante d'une manière qui le rend plus performant. Mais vous devez aller à la racine du problème et considérer également les couches inférieures, c'est-à-dire les données.

    En termes simplifiés, si vous n'avez pas d'index et que vous n'interrisez aucun conseil de cache ou d'optimisation, le moteur de base de données doit faire une analyse de la table pour obtenir les résultats. Si vous avez beaucoup d'enregistrements, cela prend évidemment du temps. Si vous vous joignez à des tables, la charge augmente encore. La solution: une bonne structure de table, un modèle de données sonore et des index appropriés.

    Un index n'est pas une balle magique cependant, si vous avez une mauvaise structure de table, il ne sera pas aussi efficace que cela devrait être.

    Si cela ne vous aide toujours pas, je vous suggère que vous ajoutez plus de détails ou postez la question plus tard avec tous les détails pertinents. Comme une ligne directrice: Comment puis-je poser une bonne question?