OP zei:
Het probleem is dat de where
clausule filtert de resultatenset, dus uw test voor een req.status
van 2 of 5 gooit alles weg waar req.status
is null omdat geen enkele rij overeenkomt met de tabel applications
.
De algemene, theoretische (aangezien niets anders dan een triviale implementatie ooit zoiets zou doen) volgorde van bewerkingen voor een select
verklaring is:
- Produceer het volledige cartesiaanse product van elke tafel vermeld in de
from
clausule. - Filter dat door de opgegeven
join
toe te passen criteria en verwijderde rijen die de gespecificeerde tests niet doorstaan. - Pas de filtercriteria toe die zijn gespecificeerd in de
where
clausule, het verwijderen van rijen die de gespecificeerde tests niet doorstaan. - Order de resultaten die zijn ingesteld op de uitdrukkingen die zijn opgegeven in de
group by
clausule en verdeel de resultaten in groepen. - Sluit elke dergelijke groep samen in een enkele rij en bereken de waarde van alle gespecificeerde aggregatiefuncties.
- Verwijder alle kolommen uit de resultatenset die niet worden vermeld in de
select
overzicht kolomoverzicht. - Bestel deze eindresultaten ingesteld op de kolommen/uitdrukkingen gespecificeerd in de
order by
clausule.
Je kunt twee dingen doen:
-
verander uw zoekopdracht om te testen op nietigheid:
where...( req.status is null OR req.status in (2,5) )...
-
verplaats de test tegen op
req.status
naar de deelnamecriteria:left join requests req on req.app_id = apps.id and req.uid = {$user_id} and req.status in (2,5)