在Spring Boot中使用JpaRepository的deleteById(ID id)方法刪除數(shù)據(jù)時，首先要使用existsById(ID id)方法判斷數(shù)據(jù)是否存在。如果存在，再刪除。

否則，刪除一個id不存在的數(shù)據(jù)會拋出org.springframework.dao.EmptyResultDataAccessException異常：

2019-01-02 15:57:24.122 WARN org.springframework.boot.autoconfigure.orm.jpa.JpaBaseConfiguration$JpaWebConfiguration$JpaWebMvcConfiguration Line:234 - spring.jpa.open-in-view is enabled by default. Therefore, database queries may be performed during view rendering. Explicitly configure spring.jpa.open-in-view to disable this warning2019-01-02 15:57:24.673 ERROR org.apache.catalina.core.ContainerBase.[Tomcat].[localhost].[/].[dispatcherServlet] Line:175 - Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed; nested exception is org.springframework.dao.EmptyResultDataAccessException: No class com.qiqi.model.entity.UserBean entity with id 33 exists!] with root causeorg.springframework.dao.EmptyResultDataAccessException: No class com.qiqi.model.entity.UserBean entity with id 33 exists! at org.springframework.data.jpa.repository.support.SimpleJpaRepository.lambda$deleteById$0(SimpleJpaRepository.java:150) at org.springframework.data.jpa.repository.support.SimpleJpaRepository$$Lambda$798/1206249587.get(Unknown Source) at java.util.Optional.orElseThrow(Optional.java:290) at org.springframework.data.jpa.repository.support.SimpleJpaRepository.deleteById(SimpleJpaRepository.java:149) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.springframework.data.repository.core.support.RepositoryComposition$RepositoryFragments.invoke(RepositoryComposition.java:359) at org.springframework.data.repository.core.support.RepositoryComposition.invoke(RepositoryComposition.java:200) at org.springframework.data.repository.core.support.RepositoryFactorySupport$ImplementationMethodExecutionInterceptor.invoke(RepositoryFactorySupport.java:644) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186) at org.springframework.data.repository.core.support.RepositoryFactorySupport$QueryExecutorMethodInterceptor.doInvoke(RepositoryFactorySupport.java:608) at org.springframework.data.repository.core.support.RepositoryFactorySupport$QueryExecutorMethodInterceptor.lambda$invoke$3(RepositoryFactorySupport.java:595) at org.springframework.data.repository.core.support.RepositoryFactorySupport$QueryExecutorMethodInterceptor$$Lambda$787/1363172555.get(Unknown Source) at org.springframework.data.repository.util.QueryExecutionConverters$$Lambda$786/1029051888.apply(Unknown Source) at org.springframework.data.repository.core.support.RepositoryFactorySupport$QueryExecutorMethodInterceptor.invoke(RepositoryFactorySupport.java:595) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186) at org.springframework.data.projection.DefaultMethodInvokingMethodInterceptor.invoke(DefaultMethodInvokingMethodInterceptor.java:59) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186)

在使用其他方法時，例如：deleteAllByName(name)，不進(jìn)行判斷也可以刪除，不會拋出異常。

前一段用springboot寫了篇 springboot整合多數(shù)據(jù)源小博文，從三個數(shù)據(jù)庫里面抓取合適的數(shù)據(jù)。存在另外一個數(shù)據(jù)庫里面。在客戶生產(chǎn)環(huán)境運行了一段時間，感覺似乎很良好。

客戶覺得意猶未盡，又提了點需求，順便提了點bug,于是乎又改了改代碼。客戶居然提出一個問題，說有時候查不出數(shù)據(jù)來，過一會又好了，我在本地試了試，發(fā)現(xiàn)在本地竟然也存在這個問題。問題其實一直都有，只是似乎不影響什么，所以便沒當(dāng)一回事。

經(jīng)過反復(fù)測試，原來是往數(shù)據(jù)庫寫數(shù)據(jù)的時候卡住了，有點奇怪。大概過程是先把表里面數(shù)據(jù)清除，然后再寫入，數(shù)據(jù)不到1000條，居然耗時差不多10秒，什么springboot,什么jpa太不靠譜了吧？

看代碼 ，Repository

package net.springboot.repository.sqlserver;import java.util.List;import org.springframework.data.jpa.repository.JpaRepository;import net.springboot.entity.sqlserver.RealData;public interface XXDataRepository extends JpaRepository<XXData, String>{}

調(diào)用代碼也是簡單明了

db.deleteAll();db.saveAll(list); //組合list這里就不寫了

其實說白了，沒有自己的代碼，都是springboot + jpa 框架實現(xiàn)的，框架難道有問題，這個一般不會吧。把SQL放出來看看。

原來這個樣子，刪除全表數(shù)據(jù)，居然是一條一條數(shù)據(jù)刪除，批量保存居然是先查詢一下，然后再插入，JPA難道不考慮效率的嗎？

問題找到了，怎么解決了？刪除功能好辦，自己寫SQL嘛，簡單方便，翠花上川菜，代碼拿來。

@Transactional@Modifying@Query(value = 'TRUNCATE TABLE table',nativeQuery = true)int TruncateTable();@Transactional@Modifying@Query(value = 'delete from table',nativeQuery = true)int deleteTable();

效果是立竿見影，刪除效率上來了。清空表里數(shù)據(jù)一秒不到。不過，后來又仔細(xì)看了一下，jpa似乎還提供了另外一個刪除全部數(shù)據(jù)的方法 deleteAllInBatch，這個方法在刪除前似乎沒有查詢，懶得做測試了，習(xí)慣了自己寫SQL解決問題。

但是批量插入這個不好辦了，總不可能自己寫成一條一條插入啊，那還不如不改了。百度一下，網(wǎng)上說改一下配置文件即可。

spring.jpa.properties.hibernate.jdbc.batch_size=500spring.jpa.properties.hibernate.jdbc.batch_versioned_data=truespring.jpa.properties.hibernate.order_inserts=truespring.jpa.properties.hibernate.order_updates=true

但是好像效果不行，show sql 還是一樣，先查詢后插入，效率依然不行。想了很多，百度了很多，為什么了，為什么啊？JPA這玩意為什么會在插入前查詢一下了，查詢又是怎么個查詢方式了？這個應(yīng)該與主鍵ID有關(guān)系。所以改一下實體類，id統(tǒng)一為uuid模式。

@Id @GenericGenerator(name = 'id-generator', strategy = 'uuid') @GeneratedValue(generator = 'id-generator') @Column(name = 'pid') public String pid;

效果明顯，問題立馬解決。但是有的系統(tǒng)主鍵ID是生成好的，有自己的規(guī)則，不可以隨便uuid,比如我這個系統(tǒng)就是，都是在各個系統(tǒng)里面已經(jīng)生成好了，而且還因為業(yè)務(wù)需要不能改。

沒辦法只有另加一個字段做為@id 雖然沒啥實際意義，但是批量寫入數(shù)據(jù)的問題得到徹底解決，你好，我好，大家好。

不過話說回來，插入前查詢一下，這個功能是可以有，在大多數(shù)的業(yè)務(wù)場景也是很有用的。springboot的jpa就這樣，在系統(tǒng)中，具體怎么用，碼農(nóng)們各顯神通。

也算是趟過 springboot,jpa框架的兩個坑。

以上為個人經(jīng)驗，希望能給大家一個參考，也希望大家多多支持好吧啦網(wǎng)。