MySQL 8.0.26+ 可用 sys.schema_replication_analysis 快速定位复制延迟瓶颈，它聚合 performance_schema 中 IO/SQL 线程状态、事务耗时、锁等待等指标，一行结果直指问题层。
直接看sys.schema_replication_analysis能省掉一半排查时间
MySQL 8.0.26+ 自带的 sys schema 里，schema_replication_analysis 视图是专为复制延迟设计的“快照诊断器”。它不依赖 Seconds_Behind_Master，而是直接聚合 performance_schema 中 IO/SQL 线程状态、事务执行时长、锁等待、relay log 积压等关键指标，一行结果就能告诉你瓶颈大概率在哪一层。
执行它前确保：performance_schema 已启用（默认开启），且 events_statements_history_long 和 events_waits_history_long 的消费者已打开（可通过 UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME LIKE 'events_%_long'; 补开）。
典型输出中重点关注三列：thread_type（IO_THREAD 或 SQL_THREAD）、latency_ms（最近事件耗时毫秒）、wait_event（如 wait/io/file/innodb/innodb_data_file 或 wait/synch/mutex/sql/LOCK_table_cache）。若 SQL_THREAD 行的 latency_ms 持续 >5000 且 wait_event 是磁盘或锁相关，基本可跳过日志比对，直奔大事务或索引缺失问题。
sys.replication_applier_status_by_worker 显示并行复制真实吞吐
即使你设了 slave_parallel_workers = 16，也不能默认所有 worker 都在干活。这个视图会暴露并行复制是否“假并发”——比如 16 个 worker 中只有 1 个 APPLYING，其余全是 IDLE 或 RETRIEVING，说明逻辑时钟分组失效，根源往往在主库没开 binlog_transaction_dependency_tracking = WRITESET，或从库 slave_parallel_type 被误设为 DATABASE（而业务其实单库写）。
常见误配组合：
-
slave_parallel_type = DATABASE+ 主库多表混写 → 所有事务被塞进同一个 database group，退化为单线程 -
slave_parallel_workers > 0但slave_parallel_type = DATABASE且从库只同步一个库 → 实际只有一个 worker 可用 - 主库
binlog_format = STATEMENT→WRITESET依赖失效，无法做行级依赖计算
修复前先确认：主库 SELECT @@binlog_transaction_dependency_tracking; 必须是 WRITESET，从库 SELECT @@slave_parallel_type; 必须是 LOGICAL_CLOCK。
用sys.x$ps_digest_95th_percentile_by_avg_us揪出“隐形慢回放语句”
从库 SQL 线程回放的语句不会进慢查询日志（slow_query_log 默认只录客户端发起的查询），但它们会记录在 performance_schema.events_statements_summary_by_digest 中。视图 sys.x$ps_digest_95th_percentile_by_avg_us 把 digest 按平均执行时间排序，顶部几条大概率就是卡住复制的元凶。
执行后重点筛这些特征：
-
digest_text包含UPDATE/DELETE且无WHERE条件，或ALTER TABLE -
avg_timer_wait> 1e9（即 >1 秒），且count_star很小（比如 1–5）→ 单次执行就超长，不是高频小语句 -
schema_name是业务库名，而非mysql或information_schema
拿到 digest 后，用 SELECT * FROM performance_schema.events_statements_history_long WHERE DIGEST = 'xxx'\G 查具体语句和参数，确认是否真在回放一个百万行更新。
sys.schema_table_statistics_with_buffer 揭示索引缺失导致的回放抖动
当 schema_replication_analysis 提示 SQL_THREAD 在某张表上频繁 Updating，但 wait_event 是 wait/io/file/innodb/innodb_data_file，下一步要查这张表有没有主键或高效索引。RBR 复制下，从库回放 UPDATE 或 DELETE 时，若目标表无主键或唯一索引，MySQL 会退化为全表扫描匹配行——这会导致 rows_examined 暴涨，sys.schema_table_statistics_with_buffer 的 rows_examined 列会明显高于其他表，且 buffer_pool_pages_dirty 持续高企。
验证方法：
- 查该表 DDL：
SHOW CREATE TABLE db_name.table_name\G，确认是否有PRIMARY KEY或UNIQUE KEY - 查历史扫描量：
SELECT table_name, rows_examined FROM sys.schema_table_statistics_with_buffer WHERE table_schema = 'db_name' ORDER BY rows_examined DESC LIMIT 5; - 若
rows_examined是表总行数的数倍，基本可判定索引缺失是根因
注意：加索引必须在主库操作，且避免在高峰期执行；从库不能单独加，否则 binlog 回放会因索引不一致失败。
