目录
问题描述：
晚上20:00以后，收到一个TDSQL-MySQL实例所有从库延迟超过900秒告警。
环境信息：
TDSQL-MySQL版本-10.2.3
实例类型-集中式
DB内核版本-8.0.24
问题分析：
1、从库状态检查
a）登录3台从库，执行show slave status \G，检查从库seconds_behind_master，延迟确实在逐渐增加。
b）查询从库回放线程状态，执行select * from perofrmance_schema.replication_applier_status_by_worker limit 10 \G，查看参数信息APPLYING_TRANSACTION_LAST_TRANSIENT_ERROR_MESSAGE提示Deadlock found when trying to get lock；try restarting transaction
2、检查从库ERROR日志
检查从库error日志，在error日志中找到了对应的死锁记录，死锁是因为两个事务同时操作一张有唯一索引的表，执行语句为insert，执行insert时，由于有唯一索引，两个事务都需要先获取对应行记录的S锁，然后再申请X锁。问题就来了，从库并行回放的时候事务一和事务二同时获得了同一行的S锁，并且都需要申请同一行的X锁，而X锁和S锁不兼容，事务一申请X锁需要等待事务二释放S锁，事务二申请X锁也需要等待事务一的S锁释放，都持有锁且互相等待对方释放，故形成了死锁。
解决方案：
临时解决方案：
从库死锁是因为MTS多线程并行回放事务造成的，临时将从库的slave_paraller_workers参数值从64调整为0，让从库变成单线程回放，即可避免死锁。临时调整完参数等待了约两小时，预计批量已经结束，将参数调整回64，从库延迟慢慢就追平了。
长久解决方案：
a）业务侧修改批量逻辑，避免产生锁冲突。
b）尽量避免使用唯一索引，唯一索引执行insert into replace语句时，会进入duplicate key判重逻辑，需要申请S锁，有把锁放大的情况。