記錄一次預釋出環境的 Bug
背景
今天在跟測試進行倉店資料的驗收的過程中，測試那邊在預釋出環境發現了一個很奇怪的 bug，提出來的異常是 non-transactional table。由於倉店資料的批次生成涉及到多張表的寫入，因此使用了事務進行資料一致性的控制。在測試環境和開發環境的時候使用相同資料都沒有出現問題，只有預釋出環境出現了這個問題，因此開始進行排查
解決過程
首先考慮到是不是事務失效的問題，當時首先考慮到的是在開發環境裡面模擬出一樣的資料和條件進行復現，但是失敗了，因為開發環境的資料生成一切正常。當時就很疑惑，而且這個異常資訊在網上也鮮有資料，因此陷入到了一個怪圈。
後面跟同事進行了一下交流，表示也沒有遇到過類似的問題，然後折騰了很久，包括嘗試遠端連線預釋出環境進行除錯，但是由於沒有許可權，最後還是失敗。
最後兜兜轉轉還是回到了原點：檢視報錯資訊。因為實在是沒別的方法了。然後這次盯著 non-transactional table 的時候有了靈感。既然報錯資訊顯示是 non-transactional table，也就意味著預釋出環境的表是非事物的表。而最常見的不支援事務的執行引擎就是 MyISAM，而且由於這個環境很久沒碰過了，之前的維護也是直接透過 sql 進行維護，因此找 leader 要了一下 staging 環境的資料庫。這下好了，發現還真是！測試環境和開發環境的表執行引擎預設都是 Innodb，而 staging 環境卻是 MyISAM，完全不支援事務。最後將 staging 環境的表執行引擎進行了修改，完成了測試。
思考
其實異常都在報錯資訊裡，但是有時候因為英文或者是從未碰到過的原因，會使得自己不會主動去琢磨報錯資訊，而是直接谷歌，但是谷歌的效果也不會每次都盡如人意，因此說到底，還是要多研究報錯資訊，以後碰到類似的這麼坑的問題才好入手，而不是反覆考慮是不是自己的程式碼出錯。