可使用独立连接分别运行executeQuery与executeBatch吗？

基础可行性结论 #

你说的用两个连接分别处理即时查询和批量操作的方案是完全可行的。
数据库服务端天生支持多连接并发访问，只要你的数据库实例的最大连接数配置没有被打满，独立持有两个连接分别处理两类业务逻辑没有任何技术障碍。JDBC中的Connection对象和数据库服务端的会话一一对应，每个连接的事务状态、执行上下文都是独立隔离的，只要你做好连接生命周期管理（避免长时间闲置被服务端主动回收、操作结束后正常关闭/归还连接），两类操作不会互相干扰。

一致性风险说明 #

这个方案的一致性问题完全取决于你的业务逻辑是否要求两类操作具备事务原子性：

• 如果你的逻辑仅需要把即时查询的结果作为批量操作的输入参数，不需要保证「查询读到的数据和批量操作写入的数据处于同一个一致的状态快照」，且可以接受查询之后、批量写入之前这部分数据被其他请求修改，那么不存在一致性问题。
• 如果你的业务要求两类操作绑定为一个原子事务（比如先查商品库存，再批量生成订单，要求库存查询和订单生成要么一起成功要么一起失败，且查询到的库存不能被其他请求中途修改），那么用两个连接就会出现一致性问题：不同连接的事务是完全独立的，你无法通过数据库的事务隔离级别来避免跨连接的不可重复读、幻读问题，也无法实现跨连接的事务提交/回滚。

不同记录操作场景的结论 #

如果两类查询操作的是完全不重叠的记录，这个方案非常合理，没有任何问题。
原理层面：支持行级锁的数据库（比如MySQL InnoDB）只会对修改的行加锁，操作不同记录不会出现锁冲突，也不会互相阻塞；其次两类操作没有重叠的数据，不存在跨操作的一致性依赖，自然也不会出现前面提到的跨连接事务异常。这种场景下用两个连接反而能避免单连接上不同类型操作互相等待的问题，性能表现更好。

• JDBC核心概念：重点理解Connection、Statement、ResultSet三类对象的生命周期，连接和数据库会话的对应关系，setAutoCommit()方法对事务的影响。
• 数据库事务基础：掌握ACID四大特性的含义，重点理解事务隔离性的四个标准级别（读未提交、读已提交、可重复读、串行化）分别能解决哪些异常（脏读、不可重复读、幻读）。
• 数据库锁机制：区分表锁、行锁、间隙锁的适用场景，了解锁等待、死锁的产生原因和规避方案。
• 连接池原理：实际生产环境不会手动持有长连接，都是通过HikariCP等连接池组件管理连接，了解连接池的核心配置参数（最大连接数、空闲超时时间等）的配置逻辑。

内容的提问来源于stack exchange，提问作者xvzf