最近線上頻繁的出現(xiàn)slave延時的情況，經(jīng)排查發(fā)現(xiàn)為用戶在刪除數(shù)據(jù)的時候，由于表主鍵的主鍵的缺少，同時刪除條件沒有索引，或或者刪除的條件過濾性極差，導(dǎo)致slave出現(xiàn)hang住，嚴重的影響了生產(chǎn)環(huán)境的穩(wěn)定性，也希望通過這篇博客，來加深主鍵在innodb引擎中的重要性，希望用戶在使用RDS，設(shè)計自己的表的時候，一定要為表加上主鍵，主鍵可以認為是innodb存儲引擎的生命，下面我們就來分析一下這個案例（本案例的生產(chǎn)環(huán)境的binlog為row模式，對于myisam存儲引擎也有同樣的問題）：
(1).現(xiàn)象slave:

slave的Seconds_Behind_Master一直在增加，slave出現(xiàn)hang住。
(2).解析當前slave執(zhí)行到的位置的binlog：

(3)分析：
模擬場景：
1.表中無主鍵，全表進行更新：
master:
表結(jié)構(gòu)：
CREATE TABLE `dmpush_message_temp` (
`clientid` varchar(36) DEFAULT NULL,
`infoid` bigint(10) DEFAULT NULL,
`endtime` varchar(14) DEFAULT NULL,
`stat` varchar(8) DEFAULT NULL
) ENGINE=innodb DEFAULT CHARSET=utf8;

mysql> update dmpush_message_temp set stat=1 ;
Query OK, 226651 rows affected (1.69 sec)
Rows matched: 226651 Changed: 226651 Warnings: 0
a.binlog中第一個出現(xiàn)的update事務(wù)日志：
mysqlbinlog -vvv /home/mysql/data3006/mysql/mysql-bin.000007 >/tmp/test.log

2281772 ### UPDATE qianyi.dmpush_message_temp
2281773 ### WHERE
2281774 ### @1='fb5c72c9-0ac2-4800-93b2-b94dc9e1dd54′ /* VARSTRING(108) meta=108 nullable=1 is_null=0 */