在多线程副本上，Performance Schema 表 replication_applier_status_by_coordinator 并 replication_applier_status_by_worker 分别显示副本的协调线程和应用程序worker线程的状态信息。对于具有多个通道的副本，标识每个通道的线程。
如果详细设置设置为显示信息性消息，多线程副本的协调线程还会定期将统计信息打印到副本的错误日志中。根据协调线程分配给应用程序worker线程的事件量打印统计信息，最大频率为每 120 秒一次。该消息列出了相关复制通道或默认复制通道（未命名）的以下统计信息：
-
已用秒数
当前时间与上次将此信息打印到错误日志的时间之间的差异（以秒为单位）。
-
分配的事件
自协调器线程启动以来，协调器线程已排队到所有应用程序worker线程的事件总数。
-
worker队列已满溢出级别
当前排队到任何应用程序worker线程的事件数量超过了溢出级别，该级别设置为 16384 个事件的最大队列长度的 90%。如果此值为零，则没有应用程序worker线程在其容量上限运行。
-
由于worker队列已满而等待
由于应用程序worker线程的队列已满，协调线程必须等待调度事件的次数。如果此值为零，则没有应用程序worker线程耗尽其容量。
-
由于总大小而等待
由于已达到
replica_pending_jobs_size_max或 限制 ，协调器线程必须等待调度事件的次数 。slave_pending_jobs_size_max此系统变量设置可用于持有尚未应用的事件的应用程序worker线程队列的最大内存量（以字节为单位）。如果一个异常大的事件超过了这个大小，事务就会被保持，直到所有应用程序的worker线程都有空队列，然后处理。所有后续交易都将保留，直到大笔交易完成。 -
等待时钟冲突
由于事件所依赖的事务尚未提交，协调器线程必须等待调度事件的纳秒数。如果
replica_parallel_type或slave_parallel_type设置为DATABASE（而不是LOGICAL_CLOCK），则此值始终为零。 -
worker占用时等待（计数）
协调器线程短时间休眠的次数，它可能在两种情况下这样做。第一种情况是协调器线程分配一个事件并发现应用程序worker线程的队列被填充超过最大队列长度的 10% 的欠载水平，在这种情况下，它最多休眠 1 毫秒。第二种情况是在哪里
replica_parallel_type或slave_parallel_type设置为LOGICAL_CLOCK并且协调器线程需要将事务的第一个事件分配给应用程序worker线程的队列，它只对具有空队列的worker执行此操作，因此如果没有队列为空，则协调器线程会休眠直到一个队列变为空。 -
worker占用时等待
协调器线程在等待空的应用程序worker线程队列时休眠的纳秒数（即在上面描述的第二种情况下，其中
replica_parallel_typeorslave_parallel_type设置为LOGICAL_CLOCK并且需要分配事务的第一个事件）。
