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. 工作生活学习都需要勤总结,多思考,解决问题的过程, 记录解决问题的方式方法都是在提高自己.
