mysql 是三张表连接查询还是分开 2+1 然后在处理合并数据？

这么点数据，瞎 jb 操作都合理

最好业务层处理，查询 3 次，数据库层面不做任何拼表

做好索引 , 数据量不大的话单表 /连表都行的.

推荐 2 楼的做法

看情况吧，分开了好缓存

#2 +1，不要在数据库层面搞骚操作，交给业务逻辑去做。

a 连 b 连 c 的话 ，真不建议，一堆人搞不定的，
还不如按 2l 拆开来写

@moodasmood #2 为什么要查 3 次呢？查 3 感觉会比一次拉出来慢很多，还要消耗额外的连接数，组装数据时还会有内存和性能上的开销。

@DreamSpace 一次查询的话其实就是把应用层的性能开销转移到了数据库层，但数据库层的资源非常宝贵，所以一般都在应用层处理。

@DreamSpace 数据库的可扩展性比上层应用差得多，因此资源也就要珍贵得多，上层应用开销大点问题不大，内存不够了，cpu 不够了，加机器就是了，相比较而言数据库就没那么简单了

其实我也有一个疑问 都说在业务层自己拆开按照单表去查，但是这样的话如果有分页呢？还有就是假如第一次从 A 表中查出来有 100w 条数据，然后要把这 100w 条数据当作条件放到 B 表中去查询，这样的话生成的 sql(如 where id in(.........................................) )难道不会超出 mysql 限制吗(我知道 mysql 这个参数可以调整，但是这终究是一次很大的网络消耗，而且容易失败)？

@akira #6 真的有这么惨的吗。。。。
内部有个 sql plus 执行的简单报表，定时执行，经常手撸 SQL，连接时间设置的越来越长，已经 600 秒了

三表 join，索引做好了没有问题的

是不是问问你们的 DBA 啊

很少有人自己手写能比数据库跑的快的
mysql 除外，他的 join 本身就很烂

联表查过二十多张表……

四百多行的 SQL 语句，不过我是搞数据的

如果是 api 接口的一般拆 3 个 sql 再 redis 缓存
如果是数据统计.看业务吧.有些过滤可以是 redis 存 id 或者其它方式来过滤.再 sql.都可以.
具体看业务了.没有绝对的方法..为了性能还是为了好修改好写代码

@DreamSpace 想一想数据库的扩展性和应用程序服务器的扩展性。
数据库做一个集群代价很高，但是应用程序服务器你随便搞个几千台都不是问题。

@leon0903 你什么查询需要在 B 里查 100 万条记录？
如果真的有那么大的数据量过滤，放到 MySQL 内部做也不会更快。

@7654 报表性质不一样，24 小时能跑出来就行

如果表之间的关联是能命中索引，当然是写表关联了

还是觉得两张表 join,再处理数据好一点。