大家喜欢单表查询和还是多表连接?

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 id in(123,456,567,9989,8909);

我个人感觉下面那种查询效率貌似不会很慢,而且思维负担也挺轻的

  • 数据库

    据说 99% 的性能瓶颈都在数据库。

    281 引用 • 595 回帖 • 1 关注

赞助商 我要投放

欢迎来到这里!

我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。

注册 关于
请输入回帖内容 ...
  • 88250

    除了统计相关,能单表就单表,但单表有个麻烦的地方是条件和分页,多表连接的话这方面就简单一些,不用单独设计对应的表结构。

  • mymoshou

    如果能达成需求,当然是单表好。问题是有时候有些东西不连表就要加载好多数据下来

  • Ahian

    这个问题要结合使用场景,在 SQL 和代码之间权衡,单表查询的时候你需要写代码去处理关联这部分逻辑

    写完 SQL 后要 Explain 一下看看是否有优化的地方

  • liangchenzhou

    对,一般除了分页,基本能用代码解决的都用代码解决,写 SQL 感觉烦,能不写就不写

  • Eddie

    in 里面数据比较多的时候可能不走索引

  • zhaoyangkun

    个人习惯多表连接。

  • yoss

    有的人恨不得什么都在数据库层面实现;有的人恨不得什么都在应用层面实现。理解业务场景,不偏不倚,选择适当的方式才是合格的程序员,如果为了追求所谓“架构设计的一致性”而摒弃某种用法是愚蠢的。

  • wizardforcel 1 赞同

    高性能 MySQL 里面的建议是做一下性能测试,哪个快用哪个。

    我一般交给 ORM,如果用 qbc 这种 API 的话。

    如果非得提供 SQL,我还是倾向于单表。因为 SQL 和 rdbms 绑得非常紧,但 rdbms 也不是常青树,说不定啥时候就被取代了,而几个单表查询显然更容易切换到其他查询表达式(比如 bson)。

  • ghostsf

    trollface 都喜欢

请输入回帖内容 ...