osi 一個 線程 查詢日誌 事務 發現 沒有 主從架構 應該

場景:
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。
綜上
由於沒有統一數據庫上線平臺和代碼審核機制，造成一些不規範的代碼以及數據庫設計在生產運行。建議上線使用規範化的數據庫上線平臺，由平臺自動發現數據庫設計、數據庫上線腳本問題，靠人肉上線難免會有疏漏，自動化運維勢在必行，研發團隊要使用代碼規範檢查工具避免不規範的代碼上線。

binlog_format=ROW模式下mysql表無主鍵造成的從庫延遲（卡住）