共計 2414 個字符，預計需要花費 7 分鐘才能閱讀完成。
本篇內容主要講解“分析數(shù)據(jù)庫 Seconds_Behind_Master 延遲的原因”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓丸趣 TV 小編來帶大家學習“分析數(shù)據(jù)庫 Seconds_Behind_Master 延遲的原因”吧!
一、總結（1）第一類：
這一類延遲情況可能造成服務器有較高的負載，可能是 CPU/IO 的負載。因為從庫在實際執(zhí)行 Event，如果我們服務器的負載比較高應該考慮這幾種情況。
大事務造成的延遲，其延遲會不會從 0 開始增加，而是直接從主庫執(zhí)行了多久開始。比如主庫執(zhí)行這個事務花費的 20 秒，要么延遲就會從 20 開始，可以自己細心觀察一下很容易看到。這是因為 Query Event 中沒有準確的執(zhí)行時間。
大表 DDL 造成的延遲，其延遲會從 0 開始增加，因為 Query Event 記錄了準確的執(zhí)行時間
表沒有合理的使用主鍵或者唯一鍵造成的延遲。這種情況不要以為設置 slave_rows_search_algorithms 參數(shù)為 INDEX_SCAN,HASH_SCAN 就可以完全解決問題。
由于參數(shù) sync_relay_log，sync_master_info，sync_relay_log_info 不合理導致，特別是 sync_relay_log 會極大的影響從庫的性能。原因我們在第 26 節(jié)進行過描述，因為 sync_relay_log 設置為 1 會導致大量 relay log 刷盤操作。
是否從庫開啟了記錄 binary log 功能即 log_slave_updates 參數(shù)開啟，如果不是必要可以關閉掉。這種情況我遇到很多次了。
（2）第二類：
這一類延遲情況往往不會造成服務器有較高的負載。它們要么沒有實際的執(zhí)行 Event，要么就是做了特殊的操作造成的。
長期未提交的事務可能造成延遲瞬間增加，因為 GTID_EVENT 和 XID_EVENT 是提交時間其他 Event 是命令發(fā)起的時間。這個我們在第 27 節(jié)中舉例描述過了。
Innodb 層的行鎖造成的延遲，這種是在從庫有修改操作并且和 SQL 線程修改的數(shù)據(jù)有沖突的情況下造成的，因為我們前面 23 節(jié)說過 SQL 線程執(zhí)行 Event 也會開啟事務和獲取行鎖，下面我們進行測試。
MySQL 層的 MDL LOCK 造成的延遲，這種情況可能是由于 SQL 線程執(zhí)行某些 DDL 操作但是從庫上做了鎖表操作造成。
MTS 中不合理的設置參數(shù) slave_checkpoint_period 參數(shù)導致。
在從庫運行期間手動改大了從庫服務器時間。
二、相關測試
因為上面的延遲情形很多我們都已經測試和講述過了。下面我們測試鎖造成的延遲情形。
（1）Innodb 層的行鎖造成的延遲
這個很容測試，我只要先在從庫做一個事務和 SQL 線程修改的數(shù)據(jù)相同即可以出現(xiàn)，大概測試如下：
從庫：mysql begin;
Query OK, 0 rows affected (0.00 sec)
mysql delete from tmpk;
Query OK, 4 rows affected (0.00 sec)
主庫執(zhí)行同樣的語句
mysql delete from tmpk;
Query OK, 4 rows affected (0.30 sec)這個時候你會觀察到延遲如下：
如果查看 sys.innodb_lock_waits 能看到如下的結果：
當然如果查看 INNODB_TRX 也可以觀察到事務的存在，這里就不截圖了，大家可以自己試試。
（2）MySQL 層的 MDL LOCK 造成的延遲
這種情況也非常容易測試，我們只需要開啟一個事務做一個 select，然后主庫對同樣的表做 DDL 就可以出現(xiàn)如下：
從庫：mysql begin;
Query OK, 0 rows affected (0.00 sec)
mysql
mysql
mysql select * from tkkk limit 1;
+------+------+------+
| a | b | c |
+------+------+------+
| 3 | 3 | 100 |
+------+------+------+
1 row in set (0.00 sec)
不要提交，表上 MDL LOCK 就不會釋放
主庫執(zhí)行語句：mysql alter table tmpk add testc int ;
Query OK, 0 rows affected (1.14 sec)
Records: 0 Duplicates: 0 Warnings: 0這個時候你將會看到如下的信息：
我們可以通過 state 看到這是等待 MDL lock 獲取而導致的延遲
三、總結
通過整個系列，我們應該清楚了 Seconds_Behind_Master 計算的方法，同時如果出現(xiàn)了延遲，我們首先查看從庫是否有負載，根據(jù)是否有負載進行區(qū)別對待，注意這里的負載一定要使用 top - H 查看 io/sql/woker 線程的負載。我曾不止一次的遇到朋友問我延遲問題，當我問他負載如何的時候他告訴我負載不高啊整體負載也就不到 2，這里我們應該注意的是對于一個線程只能使用到一個 CPU 核，雖然整體負載不到 2 但是可能 io/sql/worker 線程已經跑滿了，實際上負載已經很高了，我們來看下面的這個截圖就是 sql 線程負載高的截圖如下：
這個截圖我們發(fā)現(xiàn)雖然整體負載不高在 1 多一點，但是 Lwp 號 20092 的線程已經跑滿了，這個線程就是我們的 sql 線程，這個時候出現(xiàn)延遲是很可能的，這個截圖正是來自一個沒有合理使用主鍵或者唯一鍵造成的延遲的案例。
我們查看 CPU 負載應該使用 top - H 去查看，查看 io 負載可以使用 iotop，iostat 等工具。我需要強調一下看 MySQL 負載的時候我們必須用線程的眼光去看。
到此，相信大家對“分析數(shù)據(jù)庫 Seconds_Behind_Master 延遲的原因”有了更深的了解，不妨來實際操作一番吧！這里是丸趣 TV 網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續(xù)學習！
