1。对于mysql，不推荐使用subquery和join，因为join本身的效率是有硬伤的。一旦数据量大了，效率就很难保证。强烈建议根据索引表取数据，然后在程序中做join，merge数据。2.不要使用子查询，效率太低。MYSQL在执行子查询时，需要创建临时表，并在查询完成后删除这些临时表。因此，子查询的速度会受到一定程度的影响。这里再介绍一个创建和销毁临时表的过程。3.如果是JOIN，则使用嵌套查询。小表驱动大表，通过索引字段关联。如果表记录比较少，还是可以的。如果很大，可以在业务逻辑中控制处理。4、数据库是底层，瓶颈往往是数据库。建议数据库只作为数据存储工具使用，不要添加业务。1、应用层关联的优势，让缓存更高效。许多应用程序可以方便地缓存单表查询对应的结果对象。如果关联中的表发生更改，则无法使用查询缓存。拆分后，如果一张表很少发生变化，基于该表的查询可以复用查询缓存的结果。查询被分解后，执行单个查询可以减少锁争用。通过应用层关联，更容易拆分数据库，更容易实现高性能和可扩展性。查询本身的效率也可能得到提高。在查询id集合时，使用IN()代替关联查询，让MySQL按照ID的顺序查询，可能比随机关联更高效。可以减少对冗余记录的查询。在应用层做关系查询意味着应用只需要查询某条记录一次，而在数据库做关系查询可能需要重复访问部分数据。从这个角度来看，这样的重构也可能减少网络和内存的遮蔽。而且，这样做相当于在应用程序中实现了一个hashjoin，而不是使用MySQL的嵌套循环join。在某些场景下，哈希关联的效率要高很多。2、应用层关联的使用场景当应用可以方便的缓存单个查询的结果，当数据可以分布到不同的MySQL服务器，当可以使用IN()方法代替关联查询时，有许多并发场景。频繁的DB查询需要分库分表。三、不推荐加入的原因1、DB的业务压力大，能减轻就减轻负担。当表在百万级时，join导致性能下降；2.分布式分库分表。目前不建议跨库加入。目前mysql的分布式中间件在跨库join上表现不佳。3.修改表的架构。修改单表的查询还是比较容易的。join写的sql语句需要修改，不好找，成本比较高。当系统比较大时，很难维护。4.不使用join的解决方案在业务层，单表查询数据后，作为下一次单表查询的条件。那是一个子查询。担心来自子查询的结果集太多。mysql不限制in的个数，但是mysql限制了整个sql语句的大小。通过调整参数max_allowed_pa??cket，可以修改一条sql的最大值。建议业务做好，限制一次查询的结果集是可以接受的。5、联合查询的优点关联查询的优点是可以分页，可以分表的字段作为查询条件。查询时，将子表匹配的字段作为结果集，主表放在其中。但问题来了。如果匹配的数据量太大，则无法正常工作。也会导致返回的分页记录与实际不一样。解决方案可以交给前端一次性查询，让前端批量展示，这个方案的前提是数据量不要太大，因为sql本身的长度是有限的。
