Answers:
Seconds_Behind_Master真的很喜欢通过时间旅行来查看过去。
这样想：
同样，主服务器似乎正在同时处理许多查询。
您回头看从站，运行SHOW SLAVE STATUS\G，结果为200 Seconds_Behind_Master。该数字如何计算？从站的时钟时间（UNIX_TIMESTAMP（NOW（））-查询的TIMESTAMP完成并记录在主站的二进制日志中的时间。
除了，还有另一项指标可供考虑Seconds_Behind_Master。该指标称为Relay_Log_Space。这表示从站上所有中继文件的所有字节之和。默认情况下，最大的单个中继日志限制为1GB。如果Relay_Log_Space小于1GB，则表明在主服务器上并行执行了许多长时间运行的查询。不幸的是，由于Replication的SQL线程具有单线程性质，因此查询在一个后面执行。
例如，假设您在主服务器上具有以下情况：
当从站从其中继日志中读取这些查询并逐一处理它们时
Seconds_Behind_Master关于慢日志，long_query_time的默认值为10秒。如果您在中继日志中的所有查询少于10秒，则您将永远不会在慢查询日志中捕获任何内容。
对于主服务器和从属服务器，我都有以下建议
Apr 26, 2012：CPU性能与数据库服务器有关吗？Sep 20, 2011：多核和MySQL性能Sep 12, 2011：可能使MySQL使用多个内核？May 26, 2011：关于单线程与多线程数据库的性能Seconds_Behind_Master。如果要查看引起复制延迟的查询，请执行以下操作：
SHOW SLAVE STATUS\GRelay_Log_FileSTOP SLAVE;START SLAVE;cd /var/lib/mysql或写入中继日志的任何地方例如，让我们做 SHOW SLAVE STATUS\G
Slave_IO_State: Waiting for master to send event
Master_Host: 10.64.51.149
Master_User: replicant
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000009
Read_Master_Log_Pos: 1024035856
Relay_Log_File: relay-bin.000030
Relay_Log_Pos: 794732078
Relay_Master_Log_File: mysql-bin.000009
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB: search_cache
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 1024035856
Relay_Log_Space: 794732271
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 106451149
如果我运行STOP SLAVE; START SLAVE;，则中继日志将关闭，并打开一个新的日志。但是，您想要relay-bin.000030。
转储内容，如下所示：
cd /var/lib/mysql
mysqlbinlog relay-bin.000030 > /root/RelayLogQueries.txt
less /root/RelayLogQueries.txt
现在，您可以看到从站当前正在尝试处理的查询。您可以将这些查询用作调整的起点。
您使用哪种二进制日志格式？您正在使用ROW还是STATEMENT？
“ SHOW GLOBAL VARIABLES LIKE 'binlog_format';”
如果您将ROW用作binlog格式，请确保所有表都具有主键或唯一键：
SELECT t.table_schema,t.table_name,engine
FROM information_schema.tables t
INNER JOIN information_schema .columns c
on t.table_schema=c.table_schema
and t.table_name=c.table_name
and t.table_schema not in ('performance_schema','information_schema','mysql')
GROUP BY t.table_schema,t.table_name
HAVING sum(if(column_key in ('PRI','UNI'), 1,0)) =0;
如果在主服务器上执行例如一条delete语句以删除没有PK或唯一键的表上的100万条记录，则仅在主服务器侧进行一次全表扫描，而在从服务器上则不会。
当使用ROW binlog_format时，MySQL将行更改写入二进制日志（不是像STATEMENT binlog_format这样的语句），并且该更改将逐行应用于从属服务器的侧面，这意味着将进行一百万次全表扫描在从属服务器上仅反映主服务器上的一条删除语句，这会导致从属计算机滞后问题。
SHOW SLAVE STATUS中的seconds_behind_master值是主设备上的系统时间与从设备上的系统时间之差，该时间是在最初执行该事件时存储的，并记录在二进制日志中。
如果两个系统的时钟不同步，则落后于master的秒数将给出错误的值。