如何使用sys schema快速定位MySQL复制延迟根因-mysql教程-PHP中文网

mysql 8.0.26+ 可用 sys.schema_replication_analysis 快速定位复制延迟瓶颈，它聚合 performance_schema 中 io/sql 线程状态、事务耗时、锁等待等指标，一行结果直指问题层。

如何使用sys schema快速定位mysql复制延迟根因

直接看`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。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

用`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 回放会因索引不一致失败。