MYSQL 的 程序設(shè)計中的坑有哪些

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

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

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

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

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

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

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

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

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