Les sous-requêtes conditionnelles sont-elles optimisées si la condition est fausse?

Question

J'ai une table foo et une barre de table, où chaque foo pourrait avoir une barre (et une barre pourrait appartenir à plusieurs foos). Maintenant, j'ai besoin de sélectionner tous les foos avec une barre. Mon sql ressemble à ceci

SELECT * 
    FROM foo f 
WHERE [...] 
    AND ($param IS NULL OR (SELECT ((COUNT(*))>0) 
          FROM bar b 
          WHERE f.bar = b.id)) 

avec $ param étant remplacé lors de l'exécution.

La question est: La sous-requête sera-t-elle exécutée même si param est nul, ou les dbms optimiseront-ils la sous-requête?

Nous utilisons mysql, mssql et oracle. Y at-il une différence entre ceux-ci en ce qui concerne ce qui précède?

Answer 1

Cela dépend. Si vous transmettez cette requête au SGBD à chaque fois, le compilateur doit réaliser qu'il n'a pas besoin d'appeler la sous-requête. S'il s'agit d'une procédure statique, cela dépend de la façon dont le compilateur stocke le plan d'exécution. Si elle stocke le plan d'exécution la première fois que la procédure est appelée et que la première fois qu'elle est appelée $ param n'est pas nulle, elle peut en fait appeler la sous-requête chaque fois que la procédure est exécutée.

Sur une note différente, vous devriez envisager Existant à la place du comte (*) pour ce type de contrôle

Select .. 
From foo f 
Where .... 
    And ($param Is Null 
      Or Exists (
         Select 1 
         From bar b 
         Where b.id = f.bar 
         )) 

Answer 2

Dans ce cas, je vous recommande de procéder à l'optimisation vous-même dans le code de l'application, plutôt que de compter sur l'optimiseur de 3 SGBDR différents pour gérer cela comme vous le souhaitez.

Si $ param est nul, sélectionnez simplement dans la table foo. Sinon, rejoignez la table à barres.

pseudo-code:

if ($param is null) 
    SELECT * 
    FROM foo f 
    WHERE [...] 
else 
    SELECT distinct f.* 
    FROM foo f 
    inner join bar b on f.bar = b.id 
    WHERE [...] 
end if