主キーによる単純なHibernateのfindOne（）が長時間かかるのはなぜですか？

Question

私はan earlier questionからこれを分割して、「保存前に選択してください」という混乱を排除します。この例では、単純なfindOne（）を主キーで実行しようとしています。これは、最新のバージョンのブートおよびバネデータを使用して、既存のsqlserver dbに対して行われます。

私はロギングセットを持っているので、ハイバネートが生成したSQLを見ることができます。この例では、ロギングのタイミングに応じて、このクエリには約4秒かかります。これは主キーを使用して照会しています。 dbvisualizerのようなdbツールで生成されたhibernateを実行すると、予想通りサブ秒で返されます。

私は遅延がある場所を確認しようとする、レベルをトレースするために休止状態のパッケージのログを増加し、4秒の遅延の前と後に、次のが見つかりました：

2017-08-14 09:51:35.345 DEBUG 7532 --- [nio-8085-exec-1] org.hibernate.SQL      : select customer0_.customer_id as customer1_4_0_, customer0_.first_name as first_na2_4_0_, customer0_.last_name as last_nam3_4_0_ from xbr_customer_tab customer0_ where customer0_.customer_id=? 
Hibernate: select customer0_.customer_id as customer1_4_0_, customer0_.first_name as first_na2_4_0_, customer0_.last_name as last_nam3_4_0_ from xbr_customer_tab customer0_ where customer0_.customer_id=? 
2017-08-14 09:51:35.470 TRACE 7532 --- [nio-8085-exec-1] o.h.r.j.i.ResourceRegistryStandardImpl : Registering statement [org.apache.tomcat.jdbc.pool.StatementFacade$StatementProxy[Proxy=25287222; Query=select customer0_.customer_id as customer1_4_0_, customer0_.first_name as first_na2_4_0_, customer0_.last_name as last_nam3_4_0_ from xbr_customer_tab customer0_ where customer0_.customer_id=?; Delegate=SQLServerPreparedStatement:6]] 
2017-08-14 09:51:35.471 TRACE 7532 --- [nio-8085-exec-1] o.h.e.jdbc.internal.JdbcCoordinatorImpl : Registering last query statement [org.apache.tomcat.jdbc.pool.StatementFacade$StatementProxy[Proxy=25287222; Query=select customer0_.customer_id as customer1_4_0_, customer0_.first_name as first_na2_4_0_, customer0_.last_name as last_nam3_4_0_ from xbr_customer_tab customer0_ where customer0_.customer_id=?; Delegate=SQLServerPreparedStatement:6]] 
2017-08-14 09:51:35.479 TRACE 7532 --- [nio-8085-exec-1] o.h.type.descriptor.sql.BasicBinder  : binding parameter [1] as [VARCHAR] - [40666316] 
2017-08-14 09:51:35.488 TRACE 7532 --- [nio-8085-exec-1] o.h.l.p.e.i.AbstractLoadPlanBasedLoader : Bound [2] parameters total 
2017-08-14 09:51:39.426 TRACE 7532 --- [nio-8085-exec-1] o.h.r.j.i.ResourceRegistryStandardImpl : Registering result set [SQLServerResultSet:6] 
2017-08-14 09:51:39.434 TRACE 7532 --- [nio-8085-exec-1] o.h.l.p.e.p.i.ResultSetProcessorImpl  : Processing result set 
2017-08-14 09:51:39.434 DEBUG 7532 --- [nio-8085-exec-1] o.h.l.p.e.p.i.ResultSetProcessorImpl  : Starting ResultSet row #0 
2017-08-14 09:51:39.436 DEBUG 7532 --- [nio-8085-exec-1] l.p.e.p.i.EntityReferenceInitializerImpl : On call to EntityIdentifierReaderImpl#resolve, EntityKey was already known; should only happen on root returns with an optional identifier specified 
2017-08-14 09:51:39.436 TRACE 7532 --- [nio-8085-exec-1] l.p.e.p.i.EntityReferenceInitializerImpl : hydrating entity state 

なぜそれ私も思ったんだけどSQLに1つしかない場合、2つのパラメータがバインドされています。

なぜこの選択​​が長くかかるのですか？特に私の春のアプリでは、dbvisualizerのような別のクライアントではない？ここで

は実体である：

：

import javax.persistence.Entity; 
import javax.persistence.Id; 
import javax.persistence.Table; 

@Entity 
@Table(name = "my_customer_table") 
public class Customer { 

    @Id 
    private String customer_id; 
    private String first_name; 
    private String last_name; 

    protected Customer() {} 


    public Customer(String firstName, String lastName) { 
     this.first_name = firstName; 
     this.last_name = lastName; 
    } 

} 

はここCustomerRepository

import com.....Customer; 
import org.springframework.data.repository.CrudRepository; 

public interface CustomerRepository extends CrudRepository<Customer, String> { 
} 

とCustomerRepositoryがで@Autowiredさ@Serviceクラスから、顧客を検索するためのコードです

Customer customer = customerRepository.findOne(customerId); 

生成されたSQLは次のとおりです。

select customer0_.customer_id as customer1_4_0_, customer0_.first_name as first_na2_4_0_, customer0_.last_name as last_nam3_4_0_ from my_customer_table customer0_ where customer0_.customer_id=? 

Answer 1

データソース内の接続文字列に次のパラメータを追加することで修正されました。

sendStringParametersAsUnicode=false 

もっと詳しく： http://www.jochenhebbrecht.be/site/2014-05-01/java/fixing-slow-queries-running-sql-server-using-jpa-hibernate-and-jtds