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