在第159页的High Performance MySQL中,他们讨论了将复杂查询分解为简单查询的问题:
转换
SELECT * FROM tag
JOIN tag_post ON tag_post.tag_id=tag.id
JOIN post ON tag_post.post_id=post.id
WHERE tag.tag='mysql';
要
SELECT * FROM tag WHERE tag='mysql';
SELECT * FROM tag_post WHERE tag_id=1234;
SELECT * FROM post WHERE post.id in (123,456,567,9098,8904);
并且在您的应用程序中自己实际加入。
我的问题是,当最终查询具有需要匹配的几千个ID的where子句时,这是个好主意(实际表本身有大约500k个条目)。
我的意思是,对于像
这样的查询会有很大的代价SELECT * FROM post WHERE post.id in (123,456,567, ... <a few thousand IDs here> ... ,9098,8904);
而不是上面的join语句?将此逻辑移动到数据库内的存储过程是否有帮助(同时考虑在MySQL中实现的存储过程有多糟糕)?
答案 0 :(得分:2)
在某些情况下,连接分解很有用,但在大多数情况下,连接速度会更快。
在你的情况下,我会坚持使用连接,而不是在IN子句中传入几千个ID。