[EmilIsberg]

Ursprungligen postat av totoo

Problemet då som tråden handlar om - det är alltså en bugg eller handlar det om att mysql helt enkelt vill ha någon annan typ av logik i frågesyntaxen?

Jag anser personligen att bakåtkompatibilitet är att föredra, särskilt när det gäller hur fråge-syntaxen tolkas.
Dock verkar det som om MySQL anser att den tidigare syntaxen var en bugg även om den ofta användes.

Buggen som Kjette länkade har rätt mycket matnyttig information och är rekommenderad läsning:

Originally posted by http://bugs.mysql.com/bug.php?id=13832+--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td>QUOTE (http://bugs.mysql.com/bug.php?id=13832)
With regards to William Finn's comment that changing the order of the joins helps, this is
true but is a misleading solution. Essentially William's query becomes the following:

SELECT * FROM t2 join (t1 left join t3 on t1.a = t3.c)

This is different than what is intended by the original query:

SELECT * FROM (t1 JOIN t2) LEFT JOIN t3 ON t1.a = t3.c

Which is still different than what the server is *actually* trying to do:

SELECT * FROM t1 JOIN (t2 LEFT JOIN t3 ON t1.a = t3.c)

[/b]

Originally posted by -http://bugs.mysql.com/bug.php?id=13832

If you read the comments in this bug report, your join clearly falls into the category of
statements that are affected by recent changed to the optimizer. Your query is expected
not to work as written, because of the order of tables in the FROM clause and the use of a
LEFT JOIN, which binds more tightly than the comma.

<!--QuoteBegin--http://bugs.mysql.com/bug.php?id=13832@

It is not a bug. Now MySQL 5 is in compliance with some rules of SQL that I'm not very
familiar with. By adding the parenthesis we are giving priority to the implicit join
expressed by the comma; after that JOIN, LEFT JOIN, RIGHT JOIN works the same way it used
to work in previous version.
[/quote]

Sammanfattningsvis är orsaken att MySQL helt har skrivit om SQL-tolken (optimizer) för att mer strikt följa SQL-standarden samt bättre hantera mer komplicerade frågor (där det exempelvis finns flera nyckelfält på tabeller).

<!--QuoteBegin--http://dev.mysql.com/doc/refman/5.0/en/join.html[/i]
SELECT u.uname, u.id, u.sex, u.city, u.score, u.numWarnings, u.numPosts, u.createDate as regDate, u.signature, p.*, pt.text, ue.uName as editUname FROM (com_posts p, users u, com_post_texts pt LEFT JOIN users ue ON (ue.id = p.editUser AND p.editUser > 0)) WHERE p.threadId = 1033 AND u.id = p.createUser AND pt.postId = p.postId ORDER BY p.createDate ASC LIMIT 0, 20[/quote]

Tidigare (4.x) kördes ihopslagningen (JOIN) av com_posts, users (u), com_post_texts innan users (ue), men numera (5.x) slås com_post, users (ue) ihop innan users (u) och com_post_texts.

Om jag tolkar MySQL-manualen rätt borde följande återfå det beteende som var innan 5.0.1:

SELECT u.uname, u.id, u.sex, u.city, u.score, u.numWarnings, u.numPosts, u.createDate as regDate, u.signature, p.*, pt.text, ue.uName as editUname FROM ((com_posts p, users u, com_post_texts pt) LEFT JOIN users ue ON (ue.id = p.editUser AND p.editUser > 0)) WHERE p.threadId = 1033 AND u.id = p.createUser AND pt.postId = p.postId ORDER BY p.createDate ASC LIMIT 0, 20