mysql使用左外连接过滤结果
我的查询:
SELECT content.*, activity_log.content_id FROM content
LEFT JOIN activity_log
ON content.id = activity_log.content_id
AND sess_id = '$sess_id'
WHERE activity_log.content_id IS NULL
AND visibility = $visibility
AND content.reported < ".REPORTED_LIMIT."
AND content.file_ready = 1
LIMIT 1
该查询的目的是从内容表中获取用户未查看过的1行(由session_id标识),但它仍然返回已查看过的内容。怎么了? (我已经检查了表,确保 content_ids 存在)
注意:我认为这比使用子查询更有效,想法?
my query:
SELECT content.*, activity_log.content_id FROM content
LEFT JOIN activity_log
ON content.id = activity_log.content_id
AND sess_id = '$sess_id'
WHERE activity_log.content_id IS NULL
AND visibility = $visibility
AND content.reported < ".REPORTED_LIMIT."
AND content.file_ready = 1
LIMIT 1
The purpose of that query is to get 1 row from the content table that has not been viewed by the user (identified by session_id), but it still returns contents that have been viewed. What is wrong? ( I have checked the table making sure that the content_ids are there)
Note: I think this is more efficient than using subqueries, thoughts?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
问题显然出在你的 JOIN 条件上。当您对内部联接结果感兴趣时,您正在使用的优化(将条件应用于基表)是有意义的,但在外部联接的情况下,其读作如下:查找
content
和当内容 id 匹配且会话 id 匹配时,返回activity_log
行;当内容 id 的日志丢失或内容 id 不丢失,但未丢失时,为activity_log
行返回 null 会话 ID 不是指定的。这几乎不是你想要的。您的查询应该如下所示:
如果性能不是最佳,您可以考虑在 (sess_id,visibility,fileready,reported) 上创建复合索引。
The problem is obviously in your JOIN condition. The optimization you are using (applying a condition to the base table) makes sense when you are interested in inner join results, but in case of an outer JOIN this is read as following: find correspondences between
content
andactivity_log
rows when the content id matches and session id matches, and return nulls foractivity_log
rows when either logs for the content id is missing, or content id is not missing, but the session id is not the one specified. And it is hardly what you want.Your query should should look like this:
If the performance is not optimal, you can consider creating a composite index on (sess_id, visibility, fileready, reported).