共计 1562 个字符，预计需要花费 4 分钟才能阅读完成。
起源：cnblogs.com/liboware/p/12740901.html
1. 对于 mysql，不举荐应用子查问和 join 是因为自身 join 的效率就是硬伤，一旦数据量很大效率就很难保障，强烈推荐别离依据索引单表取数据，而后在程序外面做 join，merge 数据。
2. 子查问就更别用了，效率太差，执行子查问时，MYSQL 须要创立长期表，查问结束后再删除这些长期表，所以，子查问的速度会受到肯定的影响，这里多了一个创立和销毁长期表的过程。
3. 如果是 JOIN 的话，它是走嵌套查问的。小表驱动大表，且通过索引字段进行关联。如果表记录比拟少的话，还是 OK 的。大的话业务逻辑中能够管制解决。
4. 数据库是最底层的，瓶颈往往是数据库。倡议数据库只是作为数据 store 的工具，而不要增加业务下来。
一、应用层关联的劣势
让缓存的效率更高。许多应用程序能够不便地缓存单表查问对应的后果对象。如果关联中的某个表产生了变动，那么就无奈应用查问缓存了，而拆分后，如果某个表很少扭转，那么基于该表的查问就能够反复利用查问缓存后果了。
- 将查问合成后，执行单个查问能够缩小锁的竞争。
- 在应用层做关联，能够更容易对数据库进行拆分，更容易做到高性能和可扩大。
- 查问自身效率也可能会有所晋升。查问 id 集的时候，应用 IN（）代替关联查问，能够让 MySQL 依照 ID 程序进行查问，这可能比随机的关联要更高效。
- 能够缩小冗余记录的查问。在应用层做关联查问，意味着对于某条记录利用只须要查问一次，而在数据库中做关联查问，则可能需
- 要反复地拜访一部分数据。从这点看，这样的重构还可能会缩小网络和内存的消艳。
- 更进一步，这样做相当于在利用中实现了哈希关联，而不是应用 MySQL 的嵌套循环关联。某些场景哈希关联的效率要高很多。
二、应用层关联的应用场景
- 当利用可能不便地缓存单个查问的后果的时候
- 当能够将数据分布到不同的 MySQL 服务器上的时候
- 当可能应用 IN（）的形式代替关联查问的时候
- 并发场景多，DB 查问频繁，须要分库分表
三、不举荐应用 join 的起因
1.DB 承当的业务压力大，能缩小累赘就缩小。当表处于百万级别后，join 导致性能降落；
2. 分布式的分库分表。这种时候是不倡议跨库 join 的。目前 mysql 的分布式中间件，跨库 join 体现不良。
3. 批改表的 schema，单表查问的批改比拟容易，join 写的 sql 语句要批改，不容易发现，老本比拟大，当零碎比拟大时，不好保护。
四、不应用 join 的解决方案
在业务层，单表查问出数据后，作为条件给下一个单表查问。也就是子查问。会放心子查问进去的后果集太多。mysql 对 in 的数量没有限度，然而 mysql 限度整条 sql 语句的大小。通过调整参数 max_allowed_packet，能够批改一条 sql 的最大值。倡议在业务上做好解决，限度一次查问进去的后果集是能承受的。
五、join 查问的劣势
关联查问的益处是能够做分页，能够用副表的字段做查问条件，在查问的时候，将副表匹配到的字段作为后果集，用主表去 in 它。
然而问题来了，如果匹配到的数据量太大就不行了，也会导致返回的分页记录跟理论的不一样，解决的办法能够交给前端，一次性查问，让前端分批显示就能够了，这种解决方案的前提是数据量不太，因为 sql 自身长度无限。
最初，关注公众号 Java 技术栈，在后盾回复：面试，能够获取我整顿的 MySQL 系列面试题和答案，十分齐全。
近期热文举荐：
1.600+ 道 Java 面试题及答案整顿 (2021 最新版)
2. 终于靠开源我的项目弄到 IntelliJ IDEA 激活码了，真香！
3. 阿里 Mock 工具正式开源，干掉市面上所有 Mock 工具！
4.Spring Cloud 2020.0.0 正式公布，全新颠覆性版本！
5.《Java 开发手册（嵩山版）》最新公布，速速下载！
感觉不错，别忘了顺手点赞 + 转发哦！
