首先還是給出我見過的一些延遲可能：
本案例是乙個朋友的，從各方面進行展示故障
按照他的描述是在主庫進行了大量形如delete from where col=''；的操作，每次delete會刪除大量的行。主庫刪除並不慢，但是從庫追不上。
下面是現象：
這裡這個5g是binlog的拷貝。
首先我們要明白沒有i/o壓力代表了什麼，沒有i/o壓力代表了我們常說的fsync沒有壓力，對應的不會是下面幾個引數的問題：
也就是跟i/o相關的調整我們是不需要考慮的。
我們再來看cpu的問題，用top -hu可以看到執行緒的資源消耗如下：
我們可以清楚的看到某個mysql執行緒耗用cpu為100%，因為是5.7我們可以方便的使用語句
select a.thd_id,b.thread_os_id,a.user ,a.conn_id,b.type,a.source,a.program_name from sys.processlist a,performance_schema.threads b where b.thread_id=a.thd_id;我們可以清楚看到是我們的sql_thread，所以我們找到的根源是sql_thread耗用了過多的cpu資源但是i/o並不是問題。
一般來講我們遇到sql_thread可能伴隨著i/o問題，但是這裡並沒有，所以瓶頸可能在快取資料的查詢方面。我們使用perf進行一下分析排名靠前的如下：
其中btr_search_guess_on_hash適合ahi自適應的hash索引相關的函式，而rec_get_offsets_func是對索引的每個flied進行定位的函式(當然我也沒仔細看過原始碼只是看了一下所在的檔案位置和函式描述資訊)，也就是他們貌似都是二級索引資料的查詢有關，我們再來看這個表的表結構如下：
我們發現這個表除了二級索引並沒有主鍵，問題基本已經定位，也就是我開始給除的延遲中的一條：
所以原因可能就是，因為沒有主鍵或者唯一鍵，event回放的時候使用到了二級索引讓回放速度慢且進行了大量的記憶體資料查詢造成了cpu 100%而沒有i/o的現象。
也就是對本表加乙個自增字段作為主鍵，速度馬上提高了。當然這個解決辦法其實我很最早就猜測到了，但是我想盡量找到為什麼會這樣。perf中的函式具體的邏輯等我學習ahi的在分析。呵呵呵呵！本次分析中唯一的遺憾是沒有pstack棧幀，否則會更加清晰和有力。
故障排除（一）
本機或本地伺服器執行緩慢時 機器執行緩慢通常是由於消耗太多系統特定的資源，資源有cpu，ram，磁碟i o以及網路。解決這個問題，考慮的問題 1 平均負載 uptime 可能是最先用到的基本度量標準，並且平均負載不會因為cpu的數量而改變。2 使用top命令解決負載問題。檢視id cpu空閒時間 如...
MySQL乙個延遲案例
突然接到報警顯示mysql主從之間延遲過大，隨後盡快到集群上面看看，進行排查。首先我們檢視延遲是由什麼造成的，排查一遍過後發現不是網絡卡和從庫機器的負載，那就要從其他地方來排除了 檢視binlog日誌發現binlog日誌檔案多並且還大 由於binlog重新整理過快，因此很快就寫滿乙個檔案，可以確定出...
RabbitMQ 實戰指南 一 延遲佇列
延遲佇列中儲存延遲訊息，延遲訊息是指當訊息被傳送到佇列中不會立即消費，而是等待一段時間後再消費該訊息。延遲佇列很多應用場景，乙個典型的應用場景是訂單未支付超時取消，使用者下單之後30分鐘內未支付成功，則把訂單取消。rabbitmq 本身沒有直接支援延遲佇列的功能，但是可以通過過期時間ttl和死信佇列...