MySQL升級過程中的一些心得-1

自己公眾號原文連結： https://mp.weixin.qq.com/s/k3sb-AqGXgx37zIrRVcktA

 我查了一下9月7日的公眾號發過《 MySQL8升級遇到的各式各樣問題 》感興趣的去看看。最近還發現了一些新的。但是我總結來說，問題歸問題，但是全都不是資料庫的問題。

     有人反饋說5.7升級到8以後個別功能寫入的時候失敗。很奇怪是個別功能，這些功能涉及的表有一個。報錯是寫入ERROR 1406 (22001): Data too long for column 。如圖。

這個比較明顯是長度不夠，問了一下這個是什麼欄位。回答是時間。第一感覺時間怎麼可能會出現超長？然後馬上想到一種情況，有些開發喜歡用字串代表時間（這是一個很不好的習慣，甚至可以說是錯誤的）。一看果然是字串。

     而這個表其他時間欄位是標準的時間。可能是歷史原因吧。我一看欄位是varchar(19) 。典型的硬套。因為比如2021-12-22 21:47:52帶上空格就是19位。那麼我們模擬一下。

給時間欄位和字串欄位寫入同樣的資料。而且是一樣的函式。結果是一樣。也就是說即使資料型別用錯了，只要按照資料庫標準獲取時間的函式來做也沒有問題。那怎麼模擬呢？

第3條資料在22後面多加了一個空格。超長了。也就是說的確是多一位是寫不進去的。很奇怪的。那麼我們先擴一下欄位，看看會發生什麼吧？

     欄位加到50以後，走一下程式邏輯，不報錯。寫入成功了，看了一下表在原有的時間後面加了.0  比如 2021-12-22 21:47:52.0  這都是為什麼？不知道，但是一定是框架或者是實現的時候選擇了非常規的方式去轉換。如果是用資料庫自帶的，即使資料型別錯誤也容錯了。但是遺憾的是，沒有這樣做。

上面的驅動典型的MySQL8 

執行結果

即使用程式寫和用命令列寫是一樣的。

小結一下：一定要按照規範定義資料結構。而且用常規手段運算元據庫最佳。不要用花裡胡哨的轉換。原生是最好的。

明天打算說另外一個問題。