No mezcle la sintaxis de combinación SQL-89 "estilo coma" con SQL-92 JOIN sintaxis. Hay problemas sutiles con la precedencia de estos dos tipos de operaciones de unión.
En su caso, la consecuencia es que está evaluando la condición de unión LEFT JOIN antes de la u existe un alias de tabla. Por eso no sabe qué u.usr_auto_key es.
Puede corregir este problema usando JOIN sintaxis para todas las uniones:
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)
No vi ninguna condición de unión entre u y s en su consulta, ¿supongo que pretende que este sea un producto cartesiano?
Para obtener más detalles sobre la interacción entre las dos formas de sintaxis para unirse, consulte la sección Cambios en el procesamiento de unión en MySQL 5.0.12 en la página http://dev.mysql.com/doc/ refman/5.0/en/join.html
Re tu comentario:como dije, tiene que ver con la precedencia del operador. Si tiene una consulta SQL con FROM A, B JOIN C luego evalúa el B JOIN C antes de que preste atención a A -- que incluye la asignación de alias de tabla. Entonces, si su condición de unión para B JOIN C usa el alias de la tabla para A recibe un error porque ese alias aún no existe.
Si lo invierte y ejecuta B, A JOIN C luego, al evaluar la condición de unión para A JOIN C el alias para A está disponible y funciona (al menos en este caso).
Pero esta es una solución frágil, porque es posible que también necesite una consulta que no se puede solucionar simplemente reordenando A y B . Es mejor simplemente dejar de usar la sintaxis de combinación obsoleta con comas. Entonces cualquier expresión de combinación tiene acceso a todos los alias de su tabla y nunca tendrá este problema en ninguna consulta.
