Question

在第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中实现的存储过程有多糟糕）？

Answer 1

在某些情况下，连接分解很有用，但在大多数情况下，连接速度会更快。

在你的情况下，我会坚持使用连接，而不是在IN子句中传入几千个ID。