JDBC 使用 SQL Server 数据库容易发生死锁的原因

为什么80%的码农都做不了架构师？>>>   

通过druid监控发现某些单表update的语句特别慢(1s以上)，而且容易发生死锁，始终找不出原因，后来查阅网站：http://emransharif.blogspot.com/2011/07/performance-issues-with-jdbc-drivers.html

连接字符串中的参数：sendStringParametersAsUnicode 会影响性能，把该参数设置为false，死锁问题没有出现过。

微软官方（https://msdn.microsoft.com/zh-cn/library/ms378988.aspx）对该参数的解释是：

sendStringParametersAsUnicode    boolean

1. 如果 sendStringParametersAsUnicode 属性设置为“true”，String 参数将以 Unicode 格式发送到服务器。
2. 如果 sendStringParametersAsUnicode 属性设置为“false”，String 参数将以非 Unicode 格式（如 ASCII/MBCS ）而不是 Unicode 格式发送到服务器。
3. sendStringParametersAsUnicode 属性的默认值为“true”。 Note: 仅在使用 CHAR、VARCHAR 或 LONGVARCHAR JDBC 类型发送参数时检查.sendStringParametersAsUnicode 属性。 新的 JDBC 4.0 国家字符方法（例如 SQLServerPreparedStatement 和 SQLServerCallableStatement 类的 setNString、setNCharacterStream 和 setNClob 方法）始终将它们的参数值以 Unicode 格式发送到服务器，而不考虑此属性的设置。 为了使 CHAR、VARCHAR 和 LONGVARCHAR JDBC 数据类型获得最佳性能，应用程序应将 sendStringParametersAsUnicode 属性设置为“false”并使用 SQLServerPreparedStatement 和 SQLServerCallableStatement 类的 setString、setCharacterStream 和 setClob 非国家字符方法。 当应用程序将 sendStringParametersAsUnicode 属性设置为“false”并使用非国家字符方法访问服务器端（如 nchar、nvarchar 和 ntext）上的 Unicode 数据类型时，如果数据库排序规则不支持非国家字符方法传递的 String 参数中的字符，则某些数据可能丢失。 请注意，对于 NCHAR、NVARCHAR 和 LONGNVARCHAR JDBC 数据类型，应用程序应使用 SQLServerPreparedStatement 和 SQLServerCallableStatement 类的 setNString、setNCharacterStream 和 setNClob 国家字符方法。

据说某些情况下，会遇到编码问题，但目前观察了一段时间，暂未出现问题。

转载于:https://my.oschina.net/tam/blog/680798