为什么 MySQL 不推荐使用 join？

　1. 对于 mysql，不推荐使用子查询和 join 是因为本身 join 的效率就是硬伤，一旦数据量很大效率就很难保证，强烈推荐分别根据索引

单表取数据，然后在程序里面做 join，merge 数据。

　　2. 子查询就更别用了，效率太差，执行子查询时，MYSQL 需要创建临时表，查询完毕后再删除这些临时表，所以，子查询的速度会

受到一定的影响，这里多了一个创建和销毁临时表的过程。

　　3. 如果是 JOIN 的话，它是走嵌套查询的。小表驱动大表，且通过索引字段进行关联。如果表记录比较少的话，还是 OK 的。大的话

业务逻辑中可以控制处理。

　　4. 数据库是最底层的，瓶颈往往是数据库。建议数据库只是作为数据 store 的工具，而不要添加业务上去。

　　让缓存的效率更高。许多应用程序可以方便地缓存单表查询对应的结果对象。如果关联中的某个表发生了变化，那么就无法使用查

询缓存了，而拆分后，如果某个表很少改变，那么基于该表的查询就可以重复利用查询缓存结果了。

　　将查询分解后，执行单个查询可以减少锁的竞争。

　　在应用层做关联，可以更容易对数据库进行拆分，更容易做到高性能和可扩展。

　　查询本身效率也可能会有所提升。查询 id 集的时候，使用 IN（）代替关联查询，可以让 MySQL 按照 ID 顺序进行查询，这可能比随机的关联要更高效。

　　可以减少冗余记录的查询。在应用层做关联查询，意味着对于某条记录应用只需要查询一次，而在数据库中做关联查询，则可能需

要重复地访问一部分数据。从这点看，这样的重构还可能会减少网络和内存的消艳。

　　更进一步，这样做相当于在应用中实现了哈希关联，而不是使用 MySQL 的嵌套循环关联。某些场景哈希关联的效率要高很多。

当应用能够方便地缓存单个查询的结果的时候

当可以将数据分布到不同的 MySQL 服务器上的时候

当能够使用 IN（）的方式代替关联查询的时候

并发场景多，DB 查询频繁，需要分库分表

1.DB 承担的业务压力大，能减少负担就减少。当表处于百万级别后，join 导致性能下降；

2. 分布式的分库分表。这种时候是不建议跨库 join 的。目前 mysql 的分布式中间件，跨库 join 表现不良。

3. 修改表的 schema，单表查询的修改比较容易，join 写的 sql 语句要修改，不容易发现，成本比较大，当系统比较大时，不好维护。

　　在业务层，单表查询出数据后，作为条件给下一个单表查询。也就是子查询。 会担心子查询出来的结果集太多。mysql 对 in 的数量没有限制，但是

　　mysql 限制整条 sql 语句的大小。通过调整参数 max_allowed_packet ，可以修改一条 sql 的最大值。建议在业务上做好处理，限制一次查询出来的结果集是能接受的。

　　关联查询的好处时候可以做分页，可以用副表的字段做查询条件，在查询的时候，将副表匹配到的字段作为结果集，用主表去 in 它，但是问题来了，如果匹配到的数据量太大就不行了，也会导致返回的分页记录跟实际的不一样，解决的方法可以交给前端，一次性查询，让前端分批显示就可以了，这种解决方案的前提是数据量不太，因为 sql 本身长度有限。