MYSQL 的 程序設計中的坑有哪些

這篇文章將為大家詳細講解有關MYSQL 的 程序設計中的坑有哪些，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

最近ORACLE 12C 的某個BUG 霸占了微信公眾號，仔細看了看，其實也還好。每種數據庫在上了新版本后都會有問題，其實不光是數據庫，每個軟件都包含著BUG，而發現了BUG 后如何處理，倒是變得重要。

以MYSQL 舉例,使用的是 percona 5.7.23 的 MGR 一個測試庫，磁盤的環境不是太理想，這是我們早先就知道的，I/O 緩慢。然后就有了這樣一個設計，因為要進行客戶的信息處理，將信息發送給銀行，而在驗證用戶的過程中，原先的設計是批量的驗證插入，發現有一個客戶的信息有問題，就直接對這一批次的信息進行打回， 而后期由于業務需求，說要一個個的來，這樣不會耽誤這個包中符合的客戶信息被打回。（業務上考慮是有道理的）

然后就在程序修改后，MYSQL 的MGR 的集群中的服務器開始出現下面的NOTE，很明顯，復制出現了點問題。

上圖中的的NOTE 雖然不是ERROR ，但顯然是 waited at clock conflicts 的數值不斷的升高， 以及 when workers occupied 后面的數字（毫秒）。

經過和程序員的溝通后，發現原先是批量的插入，現在是單條的插入。而數據庫ERS 都知道，任何數據庫的插入都傾向于 批量的插入和提交，（請不要誤會批量的含義，這里的批量是指批量類似存儲過程似的綜合性的事務，例如像ORACLE  更新幾十萬條語句就寫一個 UPATE 語句這樣的糟糕設計）。這和數據庫的本身的原理有關，批量的插入產生的I/O消耗，和 單條快速的循環插入對于數據庫的I/O系統的壓力是不一樣的，并且不光是插入而且在插入的時候還要對插入表的唯一索引進行一個CHECK，所以帶唯一索引的表，在高速插入的時候的性能消耗會更大。（其實一個程序的設計要考慮的事情很多，有時想的很簡單，但業務，系統本身的限制，給程序的開發者們提出了更高的要求，同時一個數量級的不同，也直接回影響系統的整體設計）

其實這里還應該想到一種應用級別的監控與系統性能監控的綜合體，很多時候系統性能不佳，往往伴隨著，剛剛更改系統的代碼，新功能的添加，等等，如何搭建一個能反應系統詳細問題的監控系統就變得很重要了。

最后的結果，程序人員去嘗試修改不大符合數據庫使用的原理的程序，然后再看。

關于MYSQL 的 程序設計中的坑有哪些就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。