推薦：MySQL Index Condition Pushdown(ICP)性能優(yōu)化方法實例
這篇文章主要介紹了MySQL Index Condition Pushdown(ICP)性能優(yōu)化方法實例,本文講解了概念介紹、原理、實踐案例、案例分析、ICP的使用限制等內(nèi)容,需要的朋友可以參考下 一 概念介紹 Index Condition Pushdown (ICP)是MySQL 5.6 版本中的新特性,是一種在存儲引擎層使用

 　　這篇文章主要介紹了MySQL 5.7增強版Semisync Replication性能優(yōu)化,本文著重講解支持發(fā)送binlog和接受ack的異步化、支持在事務(wù)commit前等待ACK兩項內(nèi)容,需要的朋友可以參考下

　　一 前言

　　前文 介紹了5.5/5.6 版本的MySQL semi sync 基礎(chǔ)原理和配置，隨著MySQL 5.7 的發(fā)布，新版本的MySQL修復(fù)了semi sync 的一些bug 并且增強了功能。

　　支持發(fā)送binlog和接受ack的異步化;

　　支持在事務(wù)commit前等待ACK;

　　在server層判斷備庫是否要求半同步以減少Plugin鎖沖突;

　　解除binlog dump線程和lock_log的沖突等等。

　　本文重點分析 第1,2個改進項，因為原來的模式的確會影響系統(tǒng)的tps，新的異步模式可以提高半同步模式下的系統(tǒng)事務(wù)處理能力。

　　二 優(yōu)化

　　1、支持發(fā)送binlog和接受ack的異步化

　　通過前面的介紹，我們知道Semisynchronous Replication模式下,app在主庫上提交一個事務(wù)/event，MySQL將每個事務(wù)寫入binary并且同步到到slave ，master會等待至少一個slave通知:slave 已經(jīng)接收到傳過來的events并寫入relay log，才返回給回話層 寫入成功，或者直到傳送日志發(fā)生超時,系統(tǒng)自動將為異步復(fù)制模式。

　　整體流程的邏輯圖

　　5.5 版本semi sync 設(shè)計的缺點：

　　從原理以及上圖來看，舊版本的semi sync 受限于dump thread ，原因是dump thread 承擔(dān)了兩份不同且又十分頻繁的任務(wù)：傳送binlog 給slave ，還需要等待slave反饋信息，而且這兩個任務(wù)是串行的，dump thread 必須等待 slave 返回之后才會傳送下一個 events 事務(wù)。dump thread 已然成為整個半同步提高性能的瓶頸在高并發(fā)業(yè)務(wù)場景下，這樣的機制會影響數(shù)據(jù)庫整體的TPS .

　　為了解決上述問題，在5.7.4版本的semi sync 框架中，獨立出一個 ack collector thread ，專門用于接收slave 的反饋信息。這樣master 上有兩個進程獨立工作，可以同時發(fā)送binlog 到slave ，和接收slave的反饋。整體流程的邏輯圖

　　大體的實現(xiàn)思路是:

　　備庫IO線程使用TCP協(xié)議和主庫交互,讀寫socket可以同時進行,在開啟主庫semisync時,啟動一個后臺線程,使用select監(jiān)聽備庫連接socket;

　　dump線程不再等待備庫ACK;在ack reciver線程等待ACK時,dump線程還能繼續(xù)發(fā)送下一組group commit的binlog,進而提升TPS.

　　2 支持在事務(wù)commit前等待ACK;

　　新版本的semi sync 增加了rpl_semi_sync_master_wait_point參數(shù) 來控制半同步模式下 主庫在返回給會話事務(wù)成功之前提交事務(wù)的方式。

　　該參數(shù)有兩個值：

　　AFTER_SYNC (默認值):master 將每個事務(wù)寫入binlog ,傳遞到slave，并且刷新到磁盤。master等待slave 反饋接收到事務(wù)并刷新到磁盤。一旦接到slave反饋，master在主庫提交事務(wù)并且返回結(jié)果給會話。 在AFTER_SYNC模式下，所有的客戶端在同一時刻查看已經(jīng)提交的數(shù)據(jù)。假如發(fā)生主庫crash，所有在主庫上已經(jīng)提交的事務(wù)已經(jīng)同步到slave并記錄到relay log。此時切換到從庫，可以保障最小的數(shù)據(jù)損失。

　　AFTER_COMMIT: master 將每個事務(wù)寫入binlog ,傳遞到slave 刷新到磁盤(relay log)，然后在主庫提交事務(wù)。master在提交事務(wù)后等待slave 反饋接收到事務(wù)并刷新到磁盤。一旦接到slave反饋，master將結(jié)果反饋給客戶端。

　　在AFTER_COMMIT模式下,如果slave 沒有應(yīng)用日志,此時master crash，系統(tǒng)failover到slave，app將發(fā)現(xiàn)數(shù)據(jù)出現(xiàn)不一致，在master提交而slave 沒有應(yīng)用。

分享：MySQL order by性能優(yōu)化方法實例
這篇文章主要介紹了MySQL order by性能優(yōu)化方法實例,本文講解了MySQL中order by的原理和優(yōu)化order by的三種方法,需要的朋友可以參考下 前言 工作過程中,各種業(yè)務(wù)需求在訪問數(shù)據(jù)庫的時候要求有order by排序。有時候不必要的或者不合理的排序操作很可能導(dǎo)致數(shù)據(jù)庫系統(tǒng)崩