ROW模式下表無主鍵造成mysql從庫延遲怎么處理

下文主要給大家帶來ROW模式下表無主鍵造成mysql從庫延遲怎么處理，希望這些內容能夠帶給大家實際用處，這也是我編輯ROW模式下表無主鍵造成mysql從庫延遲怎么處理這篇文章的主要目的。好了，廢話不多說，大家直接看下文吧。

場景:
MySQL-5.6.30, 主從架構,  只讀從庫的SQL線程卡在某一個事務兩個多小時沒有動過, show processlist發現從庫當時沒有連接和慢查詢語句;
show open TABLES where In_use >0; 發現一個表被鎖定如下：

mysql> show open TABLES where In_use >0;
+----------+---------------+--------+-------------+
| Database | Table         | In_use | Name_locked |
+----------+---------------+--------+-------------+
| cxx      | t_post_xxxxxx |      1 |           0 |
+----------+---------------+--------+-------------+

結論
從庫沒有線程，說明鎖定的表是從主庫同步過來的語句鎖定的，應該是主庫對此表的大事務操作造成。
分析
1.通過show slave status 確定的position去分析主庫的binlog，發現生成了大量的刪除 t_post_xxxxxx的語句；
2.查看慢查詢日志，發現 delete from  t_post_xxxxxx;
3.在主庫查看 t_post_xxxxxx表結構，發現竟然沒有主鍵也沒有索引；
4.select count(*) from  t_post_xxxxxx;發現此表20多萬條數據；
5.真相大白了，沒有主鍵直接delete刪除全表會生成20多萬條delete語句在binlog中，沒有主鍵同步到從庫需要執行20多萬次全表掃描，20W*20W=400多億，嚇人！；
6.MySQL同步的時候, 會去利用主鍵來搜索需要修改的行(或者是一些二級索引)。
解決方案
1.增加主鍵；
2.跟研發溝通delete from t_post_xxxxxx改為truncate table t_post_xxxxxx。
綜上
由于沒有統一數據庫上線平臺和代碼審核機制，造成一些不規范的代碼以及數據庫設計在生產運行。建議上線使用規范化的數據庫上線平臺，由平臺自動發現數據庫設計、數據庫上線腳本問題，靠人肉上線難免會有疏漏，自動化運維勢在必行，研發團隊要使用代碼規范檢查工具避免不規范的代碼上線。

對于以上關于ROW模式下表無主鍵造成mysql從庫延遲怎么處理，大家是不是覺得非常有幫助。如果需要了解更多內容，請繼續關注我們的行業資訊，相信你會喜歡上這些內容的。