看錯誤碼，首先確定是你程式碼違反了約束條件，還是資料庫的問題，如果沒辦法檢視error.log，最偷懶的辦法是用navicat之類的工具建立一個新表，欄位隨意，手動插入資料，如果可插入則資料庫無誤，那需要檢查你的應用與資料庫的連線，如果還無誤，那基本就是程式碼問題了。另外還有種可能，資料庫是叢集中的只讀庫，檢視global read_only是否為1

資料寫入資料庫失敗，該怎麼辦？

寫入資料庫失敗情況分析

要知道怎麼辦，必須先了解下失敗情況

1.網路原因，如：寬頻不穩定2.Mysql本身穩定性，如：低版本的一些BUG3.寫了錯誤的SQL導致，如：insert 表 資料 唯一主鍵衝突了4.程式碼有BUG導致，如：高併發獲取mysql資料庫連線，導致連線物件被吃光。5.其他我還沒想到解決辦法

分析完失敗的種種原因，下一步就是具體針對解決問題

Mysql本身的BUG、網路問題，當然是找網管和DBA啦，應該升級的升級，加寬頻的加。排查清楚是mysql本身問題還是程式程式碼問題，有了這個思路下面問題才能針對性解決他。我舉個程式碼問題案例：某業務更新邏輯，上線前期很穩定，可是後來跑了半年後，mysql連線經常超時，mysql大量請求還阻塞住了，經過開發定位分析，發現是有個update sql寫的有效能問題，前期資料量小沒影響，後面資料量上來了，mysql生產環境有抗不住了，各種請求一直等待卡死了。mysql本身是很強大的，但程式設計師操作sql的能力都參差不齊，通常解決問題從 操作mysql的程式碼方面和 mysql本身配置方面去分析。DBA和程式設計師配合最終定位解決掉問題。

這種情況很可能是磁碟有問題了，當然具體真正還要看具體服務的日誌來分析。

磁碟有問題很多可能是因為空間滿了

linux下可以透過 df -h來檢視磁碟空間，如果使用%100，剩餘0那就是這種情況了。

我們知道mysql如果開啟bin日誌而不清理的話會佔用大量空間，最終導致空間佔滿報錯。

清理bin日誌，root賬號登陸到mysql提示符:

mysql> purge binary logs to "mysql-bin.000066";

這樣這個bin日誌及之前bin日誌都會清理掉。

或者，按照時間

purge master logs before"2018-07-01";

7月1日之前日誌都會清理。

注意不要直接rm -f日誌檔案，那樣是不會釋放空間的。

好了這就是空間滿原因排查及處理的方法，這也是常見問題，當然如果是其他原因也要針對原因具體處理。詳細可以附上跟多日誌和證據，關注蟲蟲，蟲蟲會幫你分析和解決的。

我們遊戲用阿里雲資料庫，存的都是二進位制資料，量比較大，所以經常遇到因為binlog檔案過大，資料庫被鎖的情況，鎖了之後就是瘋狂報警，所有資料都無法讀取和寫入。

當然，如果想完全避免這種問題，就需要花很大的代價。第一，資料庫可能需要雙寫，其中一個出錯起碼還能頂一會。第二，業務層增加快取系統和緩寫系統，減少db訪問頻率。第三，業務層增加重試和報警系統，短期內如果因為資料庫峰值問題可以稍後再嘗試。出錯一定要有報警和日誌，便於查詢問題和後續補救。