このSQLはどのように間違っているのでしょうか？私は何を見ていませんか？

SQL-89の「コンマスタイル」の結合構文とSQL-92のJOINを混在させないでください。構文。これら2種類の結合操作の優先順位には微妙な問題があります。

あなたの場合、結果は、結合条件LEFT JOINを評価しているということです。 uの前テーブルエイリアスが存在します。そのため、u.usr_auto_keyが何であるかがわかりません。です。

この問題は、JOINを使用して修正できます。すべての結合の構文：

SELECT 
  `u`.`usr_auto_key` AS `u__usr_auto_key`, 
  `s`.`set_auto_key` AS `s__set_auto_key`, 
  `u2`.`usr_auto_key` AS `u2__usr_auto_key`, 
  `u2`.`set_auto_key` AS `u2__set_auto_key`, 
  `u2`.`value` AS `u2__value` 
FROM `User` `u` JOIN `Setting` `s`
LEFT JOIN `User_Setting` `u2` ON `u`.`usr_auto_key` = `u2`.`usr_auto_key` 
WHERE (`s`.`sct_auto_key` = 1 AND `u`.`usr_auto_key` = 1 AND admin_property is null)

uの間に結合条件が表示されませんでしたおよびs クエリで、これをデカルト積にするつもりだと思いますか？

joinの2つの構文形式間の相互作用の詳細については、MySQL5.0.12でのJoinProcessingの変更のセクションを参照してください。ページ上の http://dev.mysql.com/doc/ refman / 5.0 / en / join.html

コメントを再確認してください：私が言ったように、それは演算子の優先順位と関係があります。 FROM A, B JOIN Cを使用したSQLクエリがある場合次に、B JOIN Cを評価します。 Aに注意を払う前に --これにはテーブルエイリアスの割り当てが含まれます。したがって、B JOIN Cの参加条件が Aのテーブルエイリアスを使用しますそのエイリアスがまだ存在しないため、エラーが発生します。

それを逆にしてB, A JOIN Cを実行すると次に、A JOIN Cの結合条件を評価します。 Aのエイリアスが利用可能であり、機能します（この場合は少なくとも）。

ただし、これは脆弱なソリューションです。Aを並べ替えただけでは修正できないクエリも必要になる場合があるためです。およびB 。カンマを使用した古い結合構文の使用を停止することをお勧めします。そうすれば、どの結合式もすべてのテーブルエイリアスにアクセスできるため、どのクエリでもこの問題が発生することはありません。