公司的数据库一直是sybase，用起来也挺好的，最新客户现场出现一个问题，数据无法传输了，看日志非常简单，一下就定位到了原因。

     很简单，参数超过了2000个，因为这个功能是根据主表的主键查询子表，方法用的是where 主表id in (?,?,?,?……)方式，参数问号最多是是2000个，不过这就奇怪了，直接使用sql查询sybase，5000个参数也没问题，看来是jdbc驱动的问题了。

     我们公司用sybase也有十多年了，这方面还是很有研究的，请教了几个人，jdbc连接sybase的驱动之前用官方的jconn，后来因为存储大对象时有个bug，后来统一换成了jtds的驱动，jtds驱动参数是有限制，我又在本地试了试两个驱动：

     jconn，我本地环境中，参数可以超过2000，最多4096个，再多就报错：

     

     显然sybase把in(?,?)这种看成使用or了，每个表达式限制是1024个，不过不知道为啥我这最大是4096，但是让现场更换驱动后，现场环境最多1024个，超过1024就报上面的错误，又请请教了几个人，他们都知道有这个限制，可能和具体环境有关，但什么关系也没人能说出来。

     jtds驱动比较简单，参数不能超过2000个，超过就会报错。

     后来网上查了查，DbaSpot里面有个人也碰到这个问题，有人告诉他可以使用下面命令查看服务器的限制：

dbcc traceon(3604)
dbcc serverlimits

     结果现场环境情况如下，表达式最多4096，AND/OR最多1024个：

     

     知道限制大小了就好办，现场问题解决办法，先把一部分数据挪到其他表中，然后剩下数据量较小，sql是可以支持的，这些数据传输完毕后，再把数据挪回来，再传输，一点点的弄，最终解决了问题。代码中也修改了，由于接口已经固定，不能修改太多，所以只使用大量主表id查询子表的方法，查询前拆分一下这些id，每800个（可配置）查询一次，多查几次就行了。

     问题是解决了，但是根据实际情况不会出现这种问题，平均几十个就发一次，为什么攒了这么多呢，查看日志发现是FTP空间满了，文件上传到FTP报错，导致数据库状态没有更新，就这么一直卡住了，攒了一个月的数据，后来FTP扩容了，但是数据太多就发送失败了。可见，真实环境什么情况都有，什么都可能发生，开发时考虑不全面真能引起不少问题呀。