前言
今天一個很久前做的專案突然找到我，說是之前做的專案中，頁面上資料彙總和列表中的資料的總數存在對不上的問題。說是列表是對的，但是根據列表統計出來的資料要比正常小很多。
排查
這個專案已經好幾年了，之前用了很久都是正常的，不可能會突然出問題了；我覺得這個統計肯定是沒問題了，很大可能就是統計是對的，但是匯入的資料不對。
第一步，我瀏覽一遍這個功能的原始碼，找到統計和列表的執行的SQL語句，查詢在資料中查詢，手動使用sum函式再計算一下，發現和頁面上統計出來的是一致的，這個時候我強烈懷疑是不是他算錯了就是這個，這個時候我也注意到，列表查詢的資料行數和匯入資料的行數不一致，詢問後那邊回覆，有少數資料為0，匯入後手動刪除了。至此，沒有找到具體的問題。
第二步，將列表中的資料匯出為Excel檔案，使用Excel求和，結果發現這個資料是對的；我都開始懷疑是不是Excel的求和計算有什麼問題；發現兩邊計算不多時，我就將這一列的資料複製到vscode中，寫了一個python將一列放到List中，使用sum(list) 計算，因為資料行有幾百上千，我不可能一個個刪除換行符，手動插入逗號，所以我是將換行符直接替換為逗號，結果發現計算出來的值，既和Excel計算的不一致，也和mysql sum函式計算的不一致，我就在列印了一行list的資料，發現比資料行多了幾個；我當時還懷疑是不是複製的時候不小心多，我就有重新複製了一份，就上下滾動看一了一行，發現裡面超過千的資料都有一個分隔符，突然我就想到會不會分隔符的問題，手動刪除了，在重新計算了一遍，發現資料是對的，至此，問題已經找到，就是匯入資料時，數字中包含分隔符，所以計算有問題。樹洞修改資料庫中帶分隔符的資料，資料正常。
結論
排查問題時，還是犯了慣性思維的錯誤，總覺得這麼久的功能不可能是有問題的。最後發現確實bug導致。
導致這個問題出現的原因是，資料庫設計時，數字欄位使用了varchat欄位，匯入資料時沒有判斷是否為數字。其次是mysql資料在字串做計算時，會自動將字串轉化為數字，但是如果文字不為數字時，會從前往後提取數字，一旦碰到非數字的就直接忽略後續所有的字元。
以下為轉化數字文字的具體事例：
