主从延迟大需先验证Seconds_Behind_Master是否真实：它易受网络抖动、时钟漂移、从库阻塞影响失真；应结合Read_Master_Log_Pos与Exec_Master_Log_Pos差值及Relay_Log_Space增长趋势判断积压。
主从延迟大，先看 Seconds_Behind_Master 是不是真延迟
很多场景下 Seconds_Behind_Master 显示几百秒，但实际业务读不到旧数据——因为这个值在 MySQL 5.7+ 中依赖 SQL 线程的 last_master_timestamp 和当前系统时间差，网络抖动、主库时钟漂移、从库长时间阻塞（如锁表、大事务回滚）都会让它失真。建议同时查：
SHOW SLAVE STATUS\G
里的 Read_Master_Log_Pos 和 Exec_Master_Log_Pos 差值，再结合 Relay_Log_Space 增长趋势判断是否真积压。
跨机房链路带宽和 RTT 是硬瓶颈，别只盯着 SQL 线程
跨机房（比如北京⇄广州）典型 RTT 在 30–60ms，单线程 IO 线程 + SQL 线程串行复制天然受限。即使主库写入不快，网络往返也卡住吞吐。解决思路不是调 innodb_flush_log_at_trx_commit，而是：
- 启用
slave_parallel_type = LOGICAL_CLOCK（MySQL 5.7+），配合slave_parallel_workers = 8~16，让不同 database 或事务组并行回放 - 确保主库开启
binlog_transaction_dependency_tracking = WRITESET（MySQL 8.0.22+），提升并行度识别精度 - 检查
max_allowed_packet是否过小——跨机房丢包重传会放大延迟，建议设为128M并同步调大从库
read_only=ON 从库上执行 DDL 还是会卡住 SQL 线程
哪怕从库设了 read_only=ON，手动执行 ALTER TABLE 或 DROP INDEX 仍会获取 MDL 全局锁，导致 SQL 线程等待。现象是 Slave_SQL_Running_State 卡在 Waiting for table metadata lock。排查命令：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
SELECT * FROM performance_schema.metadata_locks WHERE OBJECT_TYPE = 'TABLE';
实操建议：
- 所有 DDL 必须走主库，从库禁止任何写操作（包括
SET SESSION sql_log_bin = 0） - 若必须在从库做维护，先
STOP SLAVE，操作完START SLAVE，避免锁冲突 - 用
pt-online-schema-change时确认--execute指向的是主库，否则从库可能被误触发
大事务是跨机房复制延迟的“放大器”
一个在主库耗时 2 秒的 UPDATE，在跨机房从库上可能因锁等待、磁盘慢、buffer pool 不热等原因变成 20 秒执行——而它后面的全部事务都得排队。比优化单条 SQL 更有效的是拆解源头：
- 应用层加限流，禁止一次性更新 > 1w 行的语句；用
LIMIT+ 循环分批（注意WHERE条件必须走索引） - 监控
SHOW PROCESSLIST中State为executing且Time> 30 的线程，定期告警 - 对归档类任务，改用
mysqldump --where+LOAD DATA INFILE替代在线 UPDATE
真正卡住跨机房复制的，往往不是配置参数本身，而是主从之间那条看不见的 TCP 连接——它既承载 binlog 传输，又受丢包、乱序、Nagle 算法影响。如果 netstat -s | grep -i "retrans" 显示重传率 > 0.5%，就得和网络团队一起查中间设备了。
