最近线上频繁的出现slave延时的情况，经排查发现为用户在删除数据的时候，由于表主键的主键的缺少，同时删除条件没有索引，或或者删除的条件过滤性极差，导致slave出现hang住，严重的影响了生产环境的稳定性，也希望通过这篇博客，来加深主键在innodb引擎中的重要性，希望用户在使用RDS，设计自己的表的时候，一定要为表加上主键，主键可以认为是innodb存储引擎的生命，下面我们就来分析一下这个案例(本案例的生产环境的binlog为row模式，对于myisam存储引擎也有同样的问题)：

(1).现象slave:

slave的Seconds_Behind_Master一直在增加，slave出现hang住。

(2).解析当前slave执行到的位置的binlog：

(3)分析：

模拟场景：

1.表中无主键，全表进行更新：

表结构：

a.binlog中第一个出现的update事务日志：

b.binlog中最后出现的update事务日志：

注意这里由于表中没有主键，所以导致了每一个事务条目的更新都是全表扫描，如果表中很很多的数据，则备库执行该更新的事务条目的时候，就会出现很多的全表扫描更新；

c.计算有多少事务条目：

mysql> select 2521492/11;—-11为一个update事务条目占用的行数

可以看到，binlog的条目数和该表的数据量查不多是一致，也就是在全表更新的时候(在row模式下)更新多少行，就有多少事务的事务条目；

2.为dmpush_message_temp表添加主键：

解析binlog中的事务条目：

可以看到这里的事务条目中由于已经有了主键，也就是@5(第一个事务条目更新和第二个事务条目更新的@5是递增的，即主键),这样事务日志就会根据主键来更新，备库执行则不会卡住；

解决：

问题的原因已经找到了，由于表中没有主键，ROW模式下，每删一条数据都会做全表扫，也就是说一条delete，如果删了10条，会做10次全表扫。。。。所以slave一直卡住；

1.slave:停止slave；

2.这个时候，发现slave已经卡住，无法进行任何操作，这个时候只有强行kill掉mysql进程

由于我们的slave复制是在mysqld启动的时候自动启动，所以这里我们需要将其关闭：

vi /etc/my3006.cnf中加入：skip-slave-start，在用mysqld_safe启动；

2.由于主库的binlog已经传入备库，这个时候，slave执行没有主键更新的事务日志就会hang住，这个时候可以采取一种巧妙的方法来避过，就是将备库中的这张表进行数据清空，slave在执行realy log的时候，就会报1032错误，我们写一个脚本进行skip掉这些错误，当备库追赶上主库后，我们在把主库的表通过mysqldump，或者insert select 还原到备库，这样就可以让slave正常的运行起来，然后在通知客户进行主键的改造；

a。slave上执行以下命令：

slave:清空备库上有问题的表

跳过该表上的错误：

b.等备库追上主库后，执行以下命令：

c.最后让应用改造，添加上主键：

3.当slave卡住的时候，可以通过解析binlog来看看，slave到底卡住在那里，是那个事务，下面是一个简单的方法，来看当前salve打开的表：

可以看到这里dmpush_message_temp一直处于打开状态，这里就可以直接定位问题的根源了；

总结：主键对于innodb来说，是非常重要的，每张表的设计的时候，都应该把主键默认的加上，不管你需不需要他，而且主键的设计最好选择自增型的主键，这里也可以略提一下自增主键的好处：

a.自增型主键以利于插入性能的提高；

b.自增型主键设计(int,bigint)可以降低二级索引的空间，提升二级索引的内存命中率；

c.自增型的主键可以减小page的碎片，提升空间和内存的使用。

--转自