Java 项目中，从数据库获取数据，一条 sql 写完，还是复用以前的 sql 查询多次？

[ymz]

• 项目中有现成的单表查询语言

• 现有需求需要多表查询获取数据

  • 复用前面的单表查询语句

  • 新写 sql 连接，一次查出来所有

大概知道，一次查询可以少访问数据库，但和数据库建立连接不是长连接么(现在默认等待时间 86400s)，而且有线程

池可以复用，这样多次查询获取和单次获取会差很多么？大佬们在这方面有没有具体的学习资料推荐？

[wellsc]

要考虑减少 IO 次数

[ymz]

@wellsc 大佬有没有博客、书籍或者视频推荐

[yidinghe]

这描述太模糊了，为什么要查多次，一样的 SQL 查多次不还是一样的结果

[ymz]

@yidinghe 我需要 C 表的数据，但是我要先去 A B 表找到相应数据，才能真正获取 C 表数据。 类似逻辑外键。

[KentY]

写 join 查询吧，如果涉及表的索引，数据量没问题的话。
优劣你可以自己测试出来，分别写两个方案，禁用掉 orm 的 cache，放在同一个比如 10000 次循环中比较下

[yeqizhang]

事实上我也像这样一次一次查这么干过，
但总感觉不太好，数据库对连接查询应该有优化快过三次查询吧。
项目要求不高可以这么干。
看后面有没有大佬比较懂数据库的了……

[ymz]

@KentY 有没有加强底层了解的资料推荐

[est]

先实现一个多次查询的性能差的版本，然后下个季度有空了优化成查询一次的。一鱼多吃。一个需求变 2 个 KPI

[ymz]

@est 2333333333333

[wangyanrui]

绝大多数项目 QPS 都不到百，真的没必要考虑性能问题，JPA 一把梭就完了~~
等被喷！

[mseasons]

先照常写，如果有性能问题再优化 join，前期写代码还是代码清晰度第一

[loryyang]

干就完事了，提前的优化是万恶之源。不过写代码之前，最好写 SQL 查几次试试
PS： 留下优化点也是给后续工作留饭吃

[jiangwenjie]

1.多次查询存在网络时延，如果是 DB 和应用服务器处于同一局域网下这个问题不明显。
2.数据库在读取数据的时候要从磁盘读取，存在 I/O 开销，为了减少 I/O 开销，DB 会把有关联的数据放在临近的磁盘块里，一次读取 N 个块，这就带来一个问题，你使用 join 引起的 I/O 次数（可能一次的 N 块就满足你的所有数据了）要少于你执行多次查询。

[ymz]

@jiangwenjie 大佬有相关资料推荐么

[jiangwenjie]

@ymz 任意一本数据库实现的书应该都有提到，我已经记不清自己在哪看的了