【爭作優秀博主】大話MySQL之愛恨情仇

在數據庫的發展過程當中，安全-->穩定-->高效-->低成本四個有序的要點一直如影隨形，後者離開前者就是空談。10月19日晚上MySQL發佈了8.0.22版本，其中一個新功能（Automatic connection failover for Async Replication Channels）引發個人注意，也很感興趣，做爲一個DBA老兵，百感交集，在過去的20多年，故障切換功能一直是三方後孃工具在主導，是幾代DBA的痛，互聯網最流行的數據庫，在這塊一直爲人詬病。此功能尚未測試，無論如何，至少在這塊官方終於開始出手解決了。夜深人靜，整理了一下思路，對於MySQL產品截至目前的發展狀況，作了一下總結，基本走如下幾個方向發展：
一、主從同步方向：異步同步到半同步，在到加強半同步，再到組複製；走同步的安全策略，到提高同步的效率，走單線程複製到並行複製，致力於下降主從延遲問題，但相對的同步絕對的延遲伴隨其發展全過程至今。
二、性能優化方向：多線程，線程池（原版MySQL的企業版支持，社區版不支持）；各類日誌各類獨立，截止8.0.22版本，保證安全與問題記錄的日誌基本所有獨立了，能夠動態調整參數單獨控制關閉和打開；重構核心引擎Innodb，優化各類鎖，獨立鎖，優化事務操做等。各類的一頓騷操做優化，使得最新版的MySQL性能也達到了史無前例的高度。
三、多模數據庫方向：關係型數據、JSON半結構化數據、對象數據、內存型以及全文檢索引擎等等多個數據引擎，走支持OLTP業務開始拓展至OLAP業務（Oracle雲上支持的Analytics Service），雖然只有它本身的雲上支持。
四、借鑑其餘數據庫方向：最大的借鑑爲ORACLE數據庫，如今的各類語法和一些用法愈來愈ORACLE了；借鑑了MongoDB的一些功能，如MIC中的相關設置、自動搭建從節點的克隆功能等，不過在使用中確實有點複雜。
五、智能化運維方向：支持各種在線DDL，對業務幾乎無感知，這個爲之後智能自助動態優化索引打下堅實的基礎；重點的性能參數差很少都支持在線修改；支持持久化動態調整參數，保證重啓後參數與重啓前一致；關閉MySQL時能夠把內存的熱數據持久化到硬盤，啓動時從新由硬盤加載到內存，減小了數據庫預熱，使數據庫重啓後快速進入以前的戰時狀態；SQL語句的重寫功能，不變動業務代碼狀況下重寫SQL；能夠支持根據硬件配置，啓動時自動調整部分參數配置，雖然可自動調整的參數有限，結合前幾項，爲將來MySQL在智能參數調優與自我優化方面、自治數據庫的發展奠基了基礎。
六、提高安全性方向：健全的日誌，保證在各類異常狀態下不丟失數據，這也是數據庫最基本的要求，MySQL也一直在努力加強再加強，努力打造金融級數據庫；加強的用戶驗證方式caching_sha2_password，強化認證模式，增長用戶認證串被暴力破解的難度。但最大的安全功能failove卻一直沒有。
七、下降成本方向：這個路線進度有點慢，目前在innodb的壓縮上有所發力，壓縮比有所改進；在加強用戶使用體驗，簡化使用操做等人力成本上一直在努力，不過有些操做比較畸形，操做配置使用複雜，好比MySQL innodb cluster的配置。
當然MySQL深受廣大人民喜好，裝機量也很大，其自己也特別優秀，但愛之深恨之切，依然有許多不足：
一、自動建立從節點：組複製剛自動增長新節點居然必需要有數據庫初始化開始所有的Binlog日誌才行（感受設計這個方案的產品腦仁有點小），不然就須要使用mysqldump手動搞定，至今增長新節點的操做依然很騷，依然不方便，操做依然複雜，反觀MongoDB就簡單多了，不論是操做仍是運維成本都很低。
二、故障切換：MySQL通過20多年的發展，至今故障切換依然依賴三方工具，故障自愈方面好好改進一下，不過至今爲止，不是很理想。其實在MySQL的JDBC中很早就相似MongoDB支持連接多數據庫多節點配置，可是自身沒有故障自動檢測和切換功能，這個功能一直是個擺設。MySQL8.0.22版本終於支持故障啓動切換，走配置參數來看，節操碎一地，估計差MongoDB的這個功能不是一星半點。期待官方在這塊投入更多的人力物力，使MySQL結束這種原始操做狀態，提高一下運維人員SLA和業務的不可用時間。
三、drop table/database刪除操做的優化：目前刪除大表和庫的時候對數據庫性能影響巨大，甚至能把數據庫給幹掛了。
四、假刪除或延時刪除庫表，作數據庫的刪除回收站，給數據庫定製後悔藥。
五、MySQL的MySQL Innodb Cluster目前是個雞肋，估計也沒啥人用，router和shell組件徹底能夠集成進MySQL中，組件越多運維等成本越高，這種管理模式用中間件不也挺好，還能私人訂製（畢竟修改中間件的成本沒有MySQL源碼的高），配置管理複雜，向MongoDB複製集看齊不香嘛？
六、遊手好閒：每一個產品都有其核心競爭力，MySQL如今的產品有忘記初心（安全、穩定、高效、低成本）的嫌疑，花活太多，想作的東西太多，想要參考其餘數據庫功能也不少，all database in MySQL行的通嘛？真的能一統數據庫江湖惟吾獨尊嘛？
傳說中的MySQL存儲與計算分離官方是否會支持？
數據庫的存儲與計算分離架構這兩年很火，這也是數據庫發展的一個方向，一方面硬件技術的進步，支持彈性伸縮，合理利用資源，下降成本，二來高併發大數據量的業務需求，特別是萬物皆爲雲的當下，這種架構的出現確實應時應景。MySQL若是支持這種架構，必然要對MySQL-Innodb的存儲引擎作大量的修改，並且還要有本身對應的分佈式文件系統，當前的MySQL架構可能要作大量的調整。MySQL官方爲了進一步下降主從同步延遲，可能會支持物理複製來優化延遲問題。至於存儲與計算分離我的感受官方不會支持，至少在在短期內不會支持，也許在MySQL13中會支持，由於我河南老鄉王守義說過十三香^-^
集多種數據庫優勢之大成，不忘初心，海乃百川，有容乃大，感受MySQL仍是不夠包容和開放。不少現成的成功案例和方案思路，借鑑過來便可，況且官方的研發人員也是全球頂級的，咋就學不會呢？不少事情咱也看不懂，咱也不知道，咱也不敢問，誰知道哪，說不定明天一覺醒來MySQL來個華麗轉身，穿個新娘妝跑步進入智能化、自治化數據庫時代呢？