我用两个服务器(可写主服务器和只读从服务器(设置了一个非常经典的MariaDB 10.4.13复制GTID设置。
一段时间以来，我注意到我的一些应用程序SELECT查询路由到slave中存在一些不一致。。经过一些故障排除；Seconds_ Behind_Master"；值增长到10000秒(！(。
通过在从属服务器上执行SHOW PROCESSLIST，我注意到长查询，如：
11 | system user | | NULL | Slave_SQL | 14 | Delete_rows_log_event :: find_row (-1) | DELETE FROM `mytable` WHERE` id` = 5580
每一个都需要超过20秒的时间来执行(！(，所以它们会累积并导致滞后。。。
在主机上启动的相同删除查询是即时的(0.031秒(-此外，从机硬件比主机更强大(4核CPU对2核CPU(，从机上的平均负载/CPU非常低。
我已经尝试过增加平行的">slave_allel_threads"；到从属CPU的数量(4(正如这里所解释的，但没有任何好处。
有关于如何解决此问题或提高复制性能以保持主/从同步的线索吗？
DELETE FROM mytable WHERE id = 5580是整个查询吗？(也许除了表名。(
id上没有索引吗？
如果id是UNIQUE或PRIMARY，则这应该只需要几毫秒。
slave_parallel_threads——其他线程是否接触同一张表？
如果要删除大量行，请参见http://mysql.rjweb.org/doc.php/deletebig
也许那张桌子上正在上演一场盛大的ALTER？
是的，问题是由于应用程序中的表设计不好。
表缺少UNIQUE / PRIMARY密钥，因此从机上的DELETE查询花费了很长时间，如所述
我在表上创建了一个主索引，然后重建了SLAVE，到目前为止不再滞后：(