互联网场景下为什么不建议用Join

第一：单机的数据库资源很稀缺，要同时服务读和写，都需要消耗CPU。为了能让数据库的吞吐变得更高，而业务又不在乎这几百微妙到毫秒级的延时差距。业务可以选择把更多计算放到service层做。毕竟计算机资源很容易扩展，数据库较难。所以大多数业务会把纯计算操作放到service层，而将数据库当成一种带事务能力的KV系统来使用，这是一个重业务，轻DB的架构思路。

第二：由于数据规模庞大，不得不对数据进行分表分库。对于分表分库的应用，使用join也受到了很多限制，需要业务能够很好地根据sharding key明确要join的两个表在同一个物理库中。而中间件一般对跨库join都支持不好。举一个很常见的业务例子，在分库分表中。要同步更新两个表，这两个表位于不同的物理库中。为了保证数据一致性，一种做法是通过分布式事务中间将两个更新操作放到一个事务中。但这样的操作一般要加全局锁，性能很差。

第三：不利于写操作。执行读操作时，会锁住被读的数据，阻塞其他业务对该部分数据的更新操作(U or D)。如果涉及多个聚合函数（缓存中没有max or min时），相当于同时锁住多张表，不能进行读写，直接影响其他业务，这影响了系统的整体性能.