MYSQL 8 日志系統到底比MYSQL 5.X好在哪里

MYSQL  8 日志系統到底比MYSQL 5.X好在哪里，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。

實際上MYSQL 5.x的日志系統存在兩個問題,導致一些性能問題,尤其在高并發寫入和對數據修改的情況下,其中的瓶頸的問題在于兩個瓶頸, 當多線程訪問數據在落入到 log_buffer 的情況下,還是需要獲取鎖讓寫入有順序性, 同時在獲取redo已經將數據頁面寫入后,也會在log_buffer中將寫入到日志中的順序進行一個重排,這也是需要有順序性.

有順序性則就會有鎖的需求,否則無法保證系統的硬性需求,所以性能的問題在這個部分就會產生. 下面的源代碼中 log_sys->mutex, log_sys->flush_order_mutex, 對于日志的寫入產生了兩個鎖.

為什么MYSQL 8 要解決這個問題,主要的原因是多CPU 在MYSQL中的使用越來越被支持,而瓶頸在于并發和順序之間的矛盾.

MYSQL 8 解決關于鎖的問題,采用了另一種方式,因為記錄必須有順序性,而不在增加鎖,則順序性如何完成, 這里MYSQL 8 采用的方式是預留空間的方式來對還未寫的日志預留空間,然后

通過預留的方式,將log_sys->mutex 數據鎖去掉 ,預留空間的方式可以進行并發的寫入,保證了之前的部分的順序性,但又沒有相關的寫入的強制的順序性.

但這還沒有完全解決問題,log_sys->flush_order_mutex 鎖是解決最終刷入到日志中的鎖. 如何避免這個鎖.

MYSQL 8 提出了新的一個數據結構,來解決以下幾個問題

1 填補的數據并沒有完全填充滿, 而其中有空洞的問題

2 怎么能不使用鎖來將信息繼續有序的刷入到日志中

這里MYSQL 8 采用了log_writer線程來檢測日志中LOG BUFFER 有沒有空洞的問題,如果有寫入就會等待,通過并集的方式來確認LOG BUFFER 寫入的日志是否有空洞,

上圖是官方給出的圖,通過并集很快的可以知道某個塊是否是空, 寫數據到log buffer也就從左到右的方式,并且看似是無序的但無序最終是有序的寫入,但不在使用原來的兩個鎖,進行寫入數據的控制.

通過更細化的設計,將原來的數據中的瓶頸化解, 這點的設計,其實和MYSQL GROUP REPLICATION 的化解原有數據復制的瓶頸的想法有共同的地方.

其中把log buffer 中的對應的dirty page 并不按照順序添加到flush list. 用戶寫完log buffer 可以將相應的 log buffer 對應的dirty page 添加到flush list列表中,InnoDB 用一個recent_closed 來記錄添加到flush list 的這一段log buffer 確認是否連續, 那么容易得出, flush list 上page lsn - recent_closed.size() 得到的lsn 用于做checkpoint同時InnoDB 后臺有Log_closer 線程定期檢查recent_closed 是否連續, 如果連續就把 recent_closed buffer 向前推進, 那么checkpoint 的信息也可以往前推進了.

這里借用某帖子關于MYSQL 8 改進后整體的數據寫入的流程總結

在整體將MYSQL 8 相關的改進過了一遍后, 發現以下幾個問題

1 有鎖的設計相對簡單,但有鎖的設計并發性差

2 無鎖的設計復雜,其中,中間段是優化的方面,將原來有序的寫入,變為了無序的寫入,加大了由于順序+鎖的方式造成的寫入的性能瓶頸

3 雖然是無鎖的設計,但最終數據的寫入與原先設計的方式并沒有區別,都是有序的.

這里面覺得相關的數據處理方式,由整體,變為分散處理,在重新歸位整體, 增加了多線程并發寫入的方式, 并且部分預處理了數據刷新到磁盤的方式提高了寫入的速度.

看完上述內容，你們掌握MYSQL  8 日志系統到底比MYSQL 5.X好在哪里的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！