Il ne fait aucun doute que la version 1 - clauses where séparées de chaque côté de l'union - sera plus rapide. Voyons pourquoi la version - la clause where sur le résultat de l'union - est pire :
- volume de données :il y aura toujours plus de lignes dans le résultat de l'union, car il y a moins de conditions sur les lignes renvoyées. Cela signifie plus d'E/S disque (en fonction des index), plus de stockage temporaire pour contenir l'ensemble de lignes, ce qui signifie plus de temps de traitement
- scan répété :l'ensemble du résultat de l'union doit être à nouveau scanné pour appliquer la condition, alors qu'il aurait pu être traité lors du scan initial. Cela signifie une double gestion de l'ensemble de lignes, bien que probablement en mémoire, mais c'est quand même un travail supplémentaire.
- les index ne sont pas utilisés pour les clauses where sur un résultat d'union. Si vous avez un index sur les champs de clé étrangère et postType, il ne serait pas utilisé
Si vous voulez des performances maximales, utilisez UNION ALL , qui transmet les lignes directement dans le résultat sans surcharge, au lieu de UNION , qui supprime les doublons (généralement par tri) et peut être coûteux et inutile en fonction de vos commentaires
Définissez ces index et utilisez la version 1 pour des performances maximales :
create index t1_authorID_postType on t1(authorID, postType);
create index t1_websiteID_postType on t1(websiteID, postType);
