线上实例从库复制延迟，show slave status发现复制卡在一个位点不会动，如下图：

http://s14/mw690/002XPXs5zy7oHj4Lp9Ped&690

于是怀疑是主库上有大事务，在从库回放卡住了。之前一直以为，要查看是否卡在大事务上，需要到主库上去查看binlog，但是往往在主库上查看binlog，刷屏很久都看不到具体执行了什么大事务SQL。今天学到一种新方法，直接在从库上查看relay log，看卡在哪个地方（看Relay_Log_File和Relay_Log_Pos）：

 show relaylog events in 'relay-bin.267885' from 18842859 limit 10;

http://s9/mw690/002XPXs5zy7oHk6PNH238&690

可以看出，relay log卡在一个delete的事务，delete的表是：airbus_dw.app_serv_goods_inconfor_30d_d 这张表.

show create table发现这张表并没有主键，并且该实例的日志格式是ROW行模式的！这样带来的后果是在备库执行的delete的SQL执行效率会低，甚至可能是全表扫描，具体是不是全表扫描，需要分析具体的SQL.

那为什么说，如果添加了主键（比如和业务无关的自增ID），在binlog格式为row格式下，会降低主从复制延迟呢？其实道理很简单，row模式下，一个sql，比如：delete from a where stat = 100

如果不添加主键，那么这个SQL在binlog为行格式下，会被拆解为多条delete语句在备库执行，形如：

####DELETE FROM  `***.***`

###WHERE

###@1=***

###@2=***

###@3=***

####DELETE FROM  `***.***`

那如果我添加了主键，比如添加了和业务无关的自增长列id，此时binlog解析的SQL语句就是形如：

###@4=2

这里多了第四列@4（主键列id），可以看到binlog会根据主键id的值来进行delete，可以提高SQL的执行效率.

解决方案：

1、在表创建的时候，就应该要设计主键；

2、如果延迟已经发生，那么应该要在从库上为这个表添加主键或者索引.