JDBC针对SQLServer的sendStringParametersAsUnicode=false的验证

背景

部分客户的SQLServer数据库出现了大量死锁的情况.
虽然部分客户并没有反馈死锁影响了产品的正常使用
但是在大量业务时还是会出现卡顿等的现象 

基于此, 经过微软case的研究,发现是 JDBC4.0之后默认为ture的sendStringParametersAsUnicode
参数的影响. 会导致所有的varchar 字段经过JDBC后发给数据库的都变成了 nvarchar. 

导致他的执行计划和查询锁定的资源都发生了变化.
可能会导致一定概率的死锁. 

问题分析

前期学习整理过 
profiler 跟踪死锁
执行计划的学习

发现 隐式转换的确存在比较高的风险. 

结合 多种类型的数据库均没有出现类似的问题
只有SQLSERVER经常出现阻塞和死锁
只能往关于varchar类型隐式转换这方面进行考虑. 

需要说明, 这边所有的数据库的隔离级别都是
读已提交并且使用快照隔离. 

问题验证

更新应用对数据库的连接字符串, 并且增加参数:
sendStringParametersAsUnicode=false

开启profiler 进行跟踪
主要跟踪dead lock graph

发现经过一段时间的程序运行,没有出现之前经常出现的业务锁相关的内容

问题其实已经基本验证通过. 

其他问题

虽然业务锁没有了
但是大量跟踪到了 关于平台一个表的deadlock

这里就非常奇怪了.  其实在这次修改这个应用之前. 
我修改其他应用时也出现了大量的针对平台表的deadlock
但是当时没往这方面考虑. 现在只能够继续分析.

打开profiler 一边跟踪锁, 一边跟踪TSQL
在出现了新的deadlock 后 暂停TSQL的跟踪

ctrl + F搜索被锁的平台表, 发现执行的SQL为:
N'@P0 varchar(8000),@P1 varchar(8000),@P2 varchar(8000),@P3 varchar(8000)'

发现其实是符合预期的 传递的参数都变成了 varchar 字段.
但是不明确为啥会产生如此多的锁

突然想到这个表可能进行过一次国际化改造, 然后查询了一下表结构. 
发现果然大部分字段类型都已经是 nvarchar

相当于按下葫芦起来瓢

其实这个问题 本应该周三第一次修改验证时就已经发现. 
周三下午六点时已经发现了大量的 关于平台表的deadlock 
但是当时因为弄K8S-IPV6 没有进行深入的研究. 

所以才到周六加班时才发现. 

部分总结

虽然问题告一段落, 但是依旧有很多值得思考的地方: 
1. sendStringParametersAsUnicode=false 的确有效, 能够减少字段类型为 varchar的死锁
2. 如果业务代码不够规范, 没有实现强行的数据类型一致性. 应用程序varchar 自动给 nvarchar进行传值时
   如果没有sendStringParametersAsUnicode=true的保护, 对应的表会出现deadlock
3. 数据的一致性和代码的严谨性是非常重要的. 代码和数据库必须一致起来. 规范性的工作是产品优劣的最大区别之一. 
4. 不能小看任何技术细节, 技术细节可能不会让你发财, 但是很容易让你阴沟翻船. 
5. 工作必须要专注, 不能事项太多,不然很容易出现跟踪不彻底, 问题解决不透彻的情况. 
6. 技术储备非常重要. 需要多学习勤思考. 不要因为自己不知道就否决别人的观点, 需要自己多验证. 
7. 工作生活学习都需要勤总结,多思考,解决问题的过程, 记录解决问题的方式方法都是在提高自己.