Không kết hợp cú pháp nối SQL-89 "kiểu dấu phẩy" với SQL-92 JOIN cú pháp. Có những vấn đề nhỏ với mức độ ưu tiên của hai loại hoạt động kết hợp này.
Trong trường hợp của bạn, hệ quả là nó đang đánh giá điều kiện tham gia LEFT JOIN trước u bí danh bảng tồn tại. Đó là lý do tại sao nó không biết những gì u.usr_auto_key là.
Bạn có thể khắc phục sự cố này bằng cách sử dụng JOIN cú pháp cho tất cả các phép nối:
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)
Tôi không thấy bất kỳ điều kiện tham gia nào giữa u và s trong truy vấn của bạn, vì vậy tôi cho rằng bạn dự định đây là một sản phẩm Descartes?
Để biết thêm chi tiết về sự tương tác giữa hai biểu mẫu cú pháp cho phép nối, hãy xem phần Tham gia các thay đổi xử lý trong MySQL 5.0.12 trên trang http://dev.mysql.com/doc/ refman / 5.0 / vi / join.html
Nhận xét của bạn:Như tôi đã nói, nó liên quan đến quyền ưu tiên của toán tử. Nếu bạn có một truy vấn SQL với FROM A, B JOIN C thì nó đánh giá B JOIN C trước khi nó chú ý đến A - bao gồm việc gán bí danh cho bảng. Vì vậy, nếu điều kiện tham gia của bạn cho B JOIN C sử dụng bí danh bảng cho A bạn gặp lỗi vì bí danh đó chưa tồn tại.
Nếu bạn đảo ngược nó và chạy B, A JOIN C sau đó khi nó đánh giá điều kiện kết hợp cho A JOIN C bí danh cho A có sẵn và nó hoạt động (ít nhất là trong trường hợp này).
Nhưng đây là một giải pháp mong manh, vì bạn cũng có thể cần một truy vấn không thể sửa được chỉ bằng cách sắp xếp lại A và B . Tốt hơn là chỉ nên ngừng sử dụng cú pháp nối lỗi thời với dấu phẩy. Sau đó, bất kỳ biểu thức nối nào đều có quyền truy cập vào tất cả các bí danh bảng của bạn và bạn sẽ không bao giờ gặp sự cố này trong bất kỳ truy vấn nào.
