看到不要三表以上关联查询的建议，去看了一下原因：
- 如果条件限制宽泛的话，三张表关联产生的笛卡儿积非常庞大，缓存机制什么的可能扛不住
- 这和表的大小很有关系
- 都在索引上性能应该不会差，但万一不在，服务器遭罪
- 跨多个表的join查询在大数据量下需要的对比与运算量是会急速增长的，所以这条规约除了限制join个数之外，还提及了「join字段类型必须一致并有索引」
如何更好的处理
很多时候，可以将查询转换一种写法，让它拥有更好的性能。也可以通过代码逻辑，以更好的方式完成查询。
复杂/简单
传统实现中由于网络通信、查询解析和优化通常代价很高，但如今 MySQL 在设计上已经让连接更加轻量级，返回一个小的查询结果更加高效，而且现在网络通信的带宽和延迟都比以前快很多。某些版本的 MySQL 在一般服务器上也能够运行每秒超过10万次查询，千兆网卡也能满足每秒两千多次的查询，所以如今多个小查询已不算大问题了。
这样做的好处有：
- 将查询分解后，执行单个查询可以减少锁竞争
- 应用层做关联，更容易拆分数据库，提高性能与扩展性
- 使用 IN() 代替关联查询，由于ID顺序固定，可能比随机的关联更加高效
- 减少冗余记录的查询
- 相当于在应用层中实现了哈希关联，而不是 MySQL 的嵌套循环关联
- 缓存效率的提高，用 IN() 查的时候，里面如果有查过的就会直接返回，而关联插叙当表更改后缓存就失效了
总之计算机解决问题，性能和存储空间往往只能取其一，有时候冗余也是很好的解决方法
参考：