Performance of native sql query and JPA

DarkCrow :

I have the following methods. The first one is native sql and the second one is JPA query.

@Query(value = "SELECT  id                  AS id," +
            "       col1                        AS col1," +
            "       col2                        AS col2," +
            "       col3                        AS col3," +
            "       col4                        AS col4," +
            "       col5                        AS col5," +
            "       col6                        AS col6," +
            "       col7                        AS col7," +
            "       col8                        AS col8," +
            "       col9                        AS col9," +
            "       col10                       AS col10," +
            "       col11                       AS col11," +
            "       col12                       AS col12," +
            "       col13                       AS col13" +
            "FROM foo " +
            "WHERE id = :id AND col1 = :col1", nativeQuery = true)
    List<Foo> findFooByIdAndCol1(@Param("id") final Long id, @Param("col1") final Long col1);
List<FooEntity> findByIdAndCol1(Long id, Long col1);

Logs

----Native sql -----
2020-02-26 10:17:04.908 DEBUG 3888 --- [           main] org.hibernate.SQL                        : SELECT id AS id, col1 AS col1, col2 AS col2, col3 AS col3, col4 AS col4, col5 AS col5, col6 AS col6, col7 AS col7, col8 AS col8, col9 AS col9, col10 AS col10, col11 AS col11, col12 AS col12, col13 AS col13 FROM foo WHERE id = ? AND col1 = ?
2020-02-26 10:17:04.915 TRACE 3888 --- [           main] o.h.type.descriptor.sql.BasicBinder      : binding parameter [1] as [BIGINT] - [1]
2020-02-26 10:17:04.915 TRACE 3888 --- [           main] o.h.type.descriptor.sql.BasicBinder      : binding parameter [2] as [BIGINT] - [1]

-----JPA query -----
2020-02-26 10:17:04.956 DEBUG 3888 --- [           main] org.hibernate.SQL                        : select foo0_.id as id1_0_, foo0_.col1 as col1_0_, foo0_.col2 as col2_3_0_, foo0_.col3 as col3_4_0_, foo0_.col4 as col4_5_0_, foo0_.col5 as col5_6_0_, foo0_.col6 as col6_7_0_, foo0_.col7 as col7_8_0_, foo0_.col8 as col8_9_0_, foo0_.col9 as col9_10_0_, foo0_.col10 as col10_20_0_, foo0_.col11 as col11_11_0_, foo0_.col12 as col12_12_0_, foo0_.col13 as col13_13_0_, foo0_.col14 as col14_14_0_, foo0_.col15 as col15_0_, foo0_.col16 as col16_16_0_, foo0_.col18 as col18_17_0_, foo0_.col19 as col19_18_0_, foo0_.col20 as col120_19_0_ from foo foo0_ where foo0_.id=? and foo0_.col1=?
2020-02-26 10:17:04.956 TRACE 3888 --- [           main] o.h.type.descriptor.sql.BasicBinder      : binding parameter [1] as [BIGINT] - [1]
2020-02-26 10:17:04.956 TRACE 3888 --- [           main] o.h.type.descriptor.sql.BasicBinder      : binding parameter [2] as [BIGINT] - [1]

Looks like when it runs its the issuing the same query in the logs. I tested this with 10k records in the db. Native query : 54.7s JPA : 74s

Is the native sql query better than JPA in my use case? Or is there any avenues to improve the performance of JPA. (Note: I know there is pagination and fetch types etc. But that's not what I am looking for)

Simulant :

The effective SQL executed on the DB should be the same. So you should exactly watch out for what you measure and what you want to use the result for.

JPA is designed for updating and storing object oriented data models into relational data structures, so you don't have to implement the mapping of Collections and relations manually.

Therefore the result of your JPA query is managed in the EntityManager and changes to your results can easily be stored back. Where the native query is just a select with a projection into a result Object, which is not managed by your EntityManager. So you remove the EntityManager overhead with the native query, you don't have optimized SQL.

So the first question is not "what is faster?", but "what is your usecase?". If you want to display read only results, you can go with the native query and save some overhead, which reduces execution time over all. If you want to store changes to your results back to the DB, you should go with the JPA query and you might also want to measure the store operation.

Depending on the usecase, it is also a valid option to go for the simpler code.

Guess you like

Origin http://10.200.1.11:23101/article/api/json?id=8079&siteId=1