I've only looked at the execution plan in SQL server, but they're the same. Because of the way they're set up you'll get an index seek and an index scan when using the ANSI syntax or the older style. The WHERE clause join does not apply a bunch of filtering on an intermediate state.
They are effectively the same but only because the set theory algebra lets the optimizer move things around.
The first one says 'put these two tables together then apply the where conditions that link them together and other stuff'. The second one says 'put these together but pay attention to this on condition when doing so and some other stuff'.
Now the set theory algebra lets the optimizers pick out parts of the where condition and move them up to the matching part. You see that in your query plan. The optimizer will also add other coditions such as what you see with the index pick and the type of matching/filtering it is using.
I personally have used/abbused the on condition to make things more clear things that really only apply to that table and matching.
Now he does ask is it the same with MySQL. Probably but someone would need to look at the query plan it spits out. But my guess is yes.
The question is sort of like asking is x + y = z the same as y + x = z. Well yeah sorta mostly. You can get weird cases where doing the order of operations differently gets you different speed profile results though. But the output is the same. But that is the fun of playing with optimizers and your knowing your platform characteristics.
> ON table1.foreignkey = table2.primarykey
The calculated dataset is the result, after the ON clause.