Det kommer an på; køre dem begge for at finde ud af det; kør derefter en 'explain select' for at få en forklaring.
Den faktiske ydelsesforskel kan variere fra "stort set ikke-eksisterende" til "temmelig betydelig" afhængigt af, hvor mange rækker i A med id='12345', der ikke har nogen matchende poster i B og C.
Opdater (baseret på udsendte forespørgselsplaner)
Når du bruger INNER JOIN er det ligegyldigt (resultatmæssigt, ikke præstationsmæssigt), hvilken tabel du skal starte med, så optimizer forsøger at vælge den, den mener ville fungere bedst. Det ser ud til, at du har indekser på alle relevante PK/FK-kolonner, og du har enten ikke et indeks på friend_events.userid eller der er for mange poster med userid = '13006' og det bliver ikke brugt; enten måde optimizer vælger tabellen med færre rækker som "base" - i dette tilfælde er det zcms_users .
Når du bruger LEFT JOIN gør det det betyder noget (resultatmæssigt), hvilken tabel der skal startes med; altså friend_events er plukket. Nu hvorfor det tager kortere tid på den måde er jeg ikke helt sikker på; Jeg gætter på friend_events.userid tilstand hjælper. Hvis du skulle tilføje et indeks (er det virkelig varchar, forresten? ikke numerisk?) på det, kan din INNER JOIN også opføre sig anderledes (og blive hurtigere).