Is smallest to largest the rule of thumb in a multi-table JOIN? Given this query,

SELECT a.*
FROM a
LEFT JOIN b ON b.a_id = a.id
LEFT JOIN c ON c.a_id = a.id
HAVING COUNT(DISTINCT b.id) &lt; COUNT(DISTINCT c.id)


if b is a significantly larger table than c, will there be performance implications to the order I do the joins? I read somewhere that the rule of thumb is to join smallest to largest, but that might've been referring to INNER JOINs.

I realize that the results will depend on the order of outer joins in many scenarios, but in one like the above where the order doesn't matter for veracity, will it likely affect performance?
SQL is declarative language, query is not executed the way you write it . Most modern RDMS have decent optimizer which is capable of choosing correct join order when relatively small number of tables is involved , statistics is up to date,  data not skewed, appropriate indexes exist, etc.  

Query optimization is a very broad topic, and it's quite specific to particular vendor. It may involve adding hints, creating materialized views, using fixed execution plans, caching tables in memory, and many other things. To some extent you may control join order with the way you write query (for instance,  subquery inside WITH  will be more likely executed first compared to the same subquery inside inline view, but again, it's very specific to RDMS you're using. 

As I rule of thumb, I'd recommend starting with a query that gives you expected results, and try optimizing it only if it's slow - the optimizer will do the rest. 

Side note: COUNT can appear in HAVING clause, not in WHERE ; the query will fail on the most RDMS.