mysql number类型引号问题
背景
?这几天在做数据自动化同步测试过程，发现一个诡异的现象。一批100条语句的更新过程中，同步到目标库去执行，总会有几条记录出现更新失败。
原因1. 查看了同步过程中的执行日志，也米有啥特别明显的问题，单就是update affect = 0 。
2. 问题的查找方式也是比较简单，针对底层执行的update语句，挨个字段确认，到底是哪一个字段影响了记录的定位。 最后发现是一个Decimal(19,8)的字段类型。
3. debug跟踪了下对应的mysql driver代码，发现针对setBigDecimal类型数据处理时，多了个单引号，字段内容就变成了 '1234.12312'. ?测试过程中手工去除引号，就可以正常的update.?
?
测试?
Due to a number of issues with the use of server-side prepared statements, Connector/J 5.0.5 has disabled their use by default. The disabling of server-side prepared statements does not affect the operation of the connector in any way
?
?
client-side和server-side的性能差别：
1. server-side需要和服务端的2次网络交互，一次进行prepare statement的构建过程，一次发送具体的bind数据。服务端可以缓存对应的prepare statement内容
2. client-side只需要一次和服务端的网络交互，但每次的sql都需要在服务端进行parse
?
所以针对server-side模式，如果不在jdbc客户端层面开启prepare statement cache，性能还不如client-side模式。而dbcp开启prepare statement cache，可能又会引发另外的问题： statement异常关闭。 在之前的dbcp测试过程中遇到过，后来就关闭了dbcp的prepare statement cache.?
?
?
?
?
