很久沒有寫博客了，疫情期間大部分時間都是在家辦公，能看出來公司線上活動業務迭代越來越快，快速的迭代一些新的線上活動產品也是適應疫情的環境。就在前兩天基本沒有接一些新的產品就繼續了原來業務的開發，過程中就遇到一個問題java.sql.SQLException: Error writing file '/tmp/MYxcgCfo' (Errcode: 28 - No space left on device)，這個異常會報很多錯，往上找就能找到這段報錯信息，這個異常沒有必要把所有的報錯信息都貼出來，這樣看不到重點，簡單的翻譯一下這句話的大概意思就是不能往這個目錄'/tmp/MYxcgCfo寫文件，原因是沒有足夠的空間。tmp這個名字看起來就感覺是臨時表，mysql在執行一些查詢等操作的時候有時候會生成臨時表，這些臨時表就會寫入磁盤，當磁盤空間不足時就會拋出如上的異常，當然寫入的大小一定是跟表中的數據大小成正比的。怎么看自己的查詢語句是否創建了臨時表，我們可以通過執行計划來看，我們是否使用來了臨時表，詳細介紹可以看我的文章sql優化，里面介紹了EXPLAIN結果的個個列的結果，看最后一一列extra就能看出來我們的sql是否使用了臨時表。當我們知道了問題的原因，我們就可以去驗證一下，由於我們測試服務器已經將磁盤里沒有的東西刪除了，這里就不截圖展示了，當時msql的安裝目錄的磁盤占用率是100%。我們可以通過dh -f命令查看。所以這個問題很容易解決，可以修改mysql的配置文件，把目錄改到磁盤空間充足的目錄，然后重啟mysql服務，我們當時這台服務器的兩個幾百G的目錄使用率都是100%，所以就刪除了一些文件，項目不用重啟，直接就可以用了，問題就解決了。
隨便說一個其它的小問題，我們開發連接數據庫工具有很多SqlYog，navicat等一些軟件，修改表字段，該字段大小等都喜歡通過工具修改，而不是通過語句修改，這就容易導致鎖表，正常的查詢操作都無法進行，昨天剛好有同事這樣操作，導致我無法讀取表的數據。
關於sql這個問題最早不是我發現的，前一天我還在家里辦公的時候就已經有了，同事把自己的代碼傳上去，然后整個項目就報錯了，同事還以為是他代碼哪里有問題，直到我第二天去了公司使用了這台服務器的數據庫才知道的，其實這個問題遇到了慢慢找就能找到原因，不要因為很多報錯信息就看不下去，在解決問題的過程，也是你在積累經驗的過程，就像前幾天幫助前端同事找她js里的bug一樣，慢慢看，順着邏輯總會找到問題。