公司的數據庫一直是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
知道限制大小了就好辦，現場問題解決辦法，先把一部分數據挪到其他表中，然後剩下數據量較小，sql是可以支持的，這些數據傳輸完畢後，再把數據挪回來，再傳輸，一點點的弄，最終解決了問題。代碼中也修改了，由於接口已經固定，不能修改太多，所以只使用大量主表id查詢子表的方法，查詢前拆分一下這些id，每800個（可配置）查詢一次，多查幾次就行了。
問題是解決了，但是根據實際情況不會出現這種問題，平均幾十個就發一次，爲什麼攢了這麼多呢，查看日誌發現是FTP空間滿了，文件上傳到FTP報錯，導致數據庫狀態沒有更新，就這麼一直卡住了，攢了一個月的數據，後來FTP擴容了，但是數據太多就發送失敗了。可見，真實環境什麼情況都有，什麼都可能發生，開發時考慮不全面真能引起不少問題呀。