实时QPS和同步位点必须分开查；QPS通过SHOW GLOBAL STATUS两次采样计算差值获得，同步位点则依赖SHOW SLAVE STATUS中Master_Log_File、Read_Master_Log_Pos、Relay_Master_Log_File、Exec_Master_Log_Pos四字段组合判断，Seconds_Behind_Master不可靠。
实时QPS和同步位点必须分开查，不能靠一个命令或一个指标覆盖两者；QPS是主库性能指标，同步位点是从库复制状态的核心坐标。
查QPS：用SHOW GLOBAL STATUS算差值，别信单次快照
MySQL不直接暴露“每秒查询数”，Queries是累计值，必须采样两次再做减法：
- 执行
SHOW GLOBAL STATUS LIKE 'Queries';，记下数值（比如125000） - 等5秒后再次执行，得到新值（比如
125420） - QPS = (125420 − 125000) / 5 = 84
注意：mysqladmin status输出第6列也是Queries，适合脚本提取；但避免用mysqladmin extended-status——字段太多、解析慢、易受干扰。采样间隔建议5–30秒，太短波动大，太长失去实时性。
查同步位点：只认SHOW SLAVE STATUS\G里的四组字段
同步是否真在推进，不看Seconds_Behind_Master，而看这四个字段的组合变化：
-
Master_Log_File和Read_Master_Log_Pos：IO线程拉到了哪（应持续接近主库SHOW MASTER STATUS的File/Position） -
Relay_Master_Log_File和Exec_Master_Log_Pos：SQL线程执行到了哪（应逐步追上上面那组值）
若Read_Master_Log_Pos长期不动 → 网络断、主库dump线程挂、或权限失效；若Exec_Master_Log_Pos不动但Read_Master_Log_Pos涨 → SQL线程卡住，常见于锁等待、DDL阻塞、或唯一键冲突。
为什么不能用Seconds_Behind_Master判断同步进度
这个值是MySQL用事件时间戳反推出来的，依赖主从系统时钟一致、且事务提交时间可比对：
- 主从服务器时间不同步时，结果直接失真（比如显示延迟300秒，实际只是时钟差）
- 大事务回放中，SQL线程在执行一条耗时UPDATE，但
Seconds_Behind_Master可能仍为0 - 值为
NULL不是“延迟很大”，而是SQL线程根本没启动或刚启动还没执行任何事件
所以它只能当辅助参考，一旦发现异常，必须立刻切到日志位点比对。
脚本里怎么安全提取位点和QPS
避免密码明文写进命令行（会被ps aux看到），改用配置文件：
- 创建
~/.my.cnf，设权限600：[client] user = repl password = your_secure_password host = 127.0.0.1
- 脚本中用
mysql -N -s -e "SHOW GLOBAL STATUS LIKE 'Queries'"取QPS原始值（-N -s去头去格式） - 用
mysql -N -s -e "SHOW SLAVE STATUS\G" | awk '/Master_Log_File|Read_Master_Log_Pos|Relay_Master_Log_File|Exec_Master_Log_Pos/ {gsub(/^[ \t]+|[ \t]+$/, ""); print}'精准抓四行
真正难的不是取值，而是把Read_Master_Log_Pos和Exec_Master_Log_Pos的差值趋势化——单次差几百KB没意义，连续5分钟差值扩大才说明SQL线程在掉队。
