这是一个创建于 1997 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近项目需要优化 DAO 层，优化查询速度。
从博客上偶然发现原来使用 JPA 进行分页，更新，删除，多表这些操作 JPA 的执行速度比 MyBatis 还慢，最快的是自定义 SQL，而且和自定义 SQL 相比，JPA 的速度差了好多！
那我们是不是需要多使用些自定义 SQL 呢？ JPA 还能不能优化呢？
从博客上偶然发现原来使用 JPA 进行分页，更新，删除，多表这些操作 JPA 的执行速度比 MyBatis 还慢，最快的是自定义 SQL，而且和自定义 SQL 相比，JPA 的速度差了好多！
那我们是不是需要多使用些自定义 SQL 呢？ JPA 还能不能优化呢？
 |
1
V2XEX 2018-10-30 13:55:41 +08:00 via Android
你打印 SQL 看看是不是程序执行了意料之外的语句
|
 |
2
janus77 2018-10-30 14:15:53 +08:00 via Android
量上去了就慢
|
 |
3
vjnjc 2018-10-30 14:22:52 +08:00
自定义 sql 是指定 select 内容吗？
|
 |
4
lihongjie0209 2018-10-30 14:36:10 +08:00
感觉是配置出问题了, JPA 有很多配置项可以在特定的场景下用来优化
|
 |
5
builder 2018-10-30 15:01:27 +08:00
个人觉得多表操作查询还是用存储过程快，没有 DBA 就直接 MyBatis 自己写 SQL，表和表之前不要用什么主外键关联，很慢的，而且后期维护特别不方便，更不方便拓展，所以 JPA 只用来进行简单的单表操作吧，能够节省一部分开发时间，运行效率没多大差距
|
 |
6
lsongiu 2018-10-30 15:18:51 +08:00
简单的 sql 还好，还可以配合二级缓存查询缓存使用，复杂的 sql 速度就明显不行了
|
 |
7
zacharyjia 2018-10-30 15:25:33 +08:00
jpa 是基于 hibernate 的吧，比 mybatis 慢是正常的
|
 |
8
lastpass 2018-10-30 15:51:18 +08:00 via Android
回复 @builder 然而我这里实际使用情况是，存储过程简直卡爆。
谁再把业务写在数据库上我打死他。 |
 |
9
johnniang 2018-10-30 16:05:59 +08:00 via Android
基本上都没有进行多表关联。而是拆分请求进行多表关联，或者使用自定义 sql。
|
 |
11
neoblackcap 2018-10-30 16:42:00 +08:00
@builder 外键不会特别地让查询变慢。外键带来的成本大概是使插入变慢，扩展性变差。
|
 |
13
wjh466587224 2018-10-30 23:19:55 +08:00
jpa 配合 mongo 吧，mongo 都是集成成一个 collection，都属于单表查询了
|
 |
14
rykinia 2018-10-31 08:28:58 +08:00
我在公司产品上用了 JPA，在简单的 CRUD 中，和 mybatis 不可能有可直接观察到的差距
我觉得你应该检查数据库的配置，以及主键、索引什么的 |
 |
15
colincat 2018-10-31 10:31:03 +08:00
JPA 我感觉就行，没必要 mybatis 了，都 8102 年了，还搞 mybatis 没啥意思，配置繁多，表又不能自动生成，大部分都是简单的 CURD，连表直接用 nativeQuery 就好了，不要搞什么外键，后期难拆
最重要的还是看项目规模，什么样类型的项目来选择，推荐 JPA，用的很爽，实在觉得慢可以加一层缓存。 |
 |
17
nezhaxiaozi OP @colincat 我们公司自己封装了 MyBatis 和 JPA，搞得好复杂的==...
|
|
18
builder 2018-11-09 14:52:40 +08:00
@lastpass 注意，存储过程是 DBA 写的，开发人员写的只能算得上 sql 集合，所以你还是 Mybatis 写 SQL 吧
|
|
19
builder 2018-11-09 14:58:30 +08:00
@neoblackcap 单独 sql 语句查询 外键没多大影响，但是一旦外键和 Hibernate JPA 结合 ，通过 java 调用，百分百慢
|
Select Language