MySQL主从复制延迟主要由批量INSERT未分批、表缺失主键或索引、锁阻塞及单线程回放导致；需拆分大事务、确保主键存在、启用LOGICAL_CLOCK并行复制并排查MDL锁。
INSERT 语句本身不会直接导致延迟，但它的执行方式会放大复制瓶颈
主从延迟不是由 INSERT 这个动作决定的，而是由它在主库如何产生 binlog、在从库如何回放，以及是否触发了复制链路上的低效环节所决定。单条小 INSERT 几乎无感；但批量、无索引、跨事务的 INSERT 就容易卡住 SQL 线程。
大批量 INSERT 没有分批，导致 relay log 回放阻塞
主库执行 INSERT INTO t VALUES (...),(...),(...) 插入 10 万行，会生成一个大事务（或多个大 event），从库 SQL 线程必须串行执行完才能推进 Exec_Master_Log_Pos。期间其他所有变更都得排队。
- 避免写成单条超长
INSERT：拆成每 1000 行一批，用循环或脚本控制 - 确认 binlog 格式：若为
ROW，且表无主键，从库回放时会全表扫描匹配每一行 —— 延迟指数级上升 - 检查
slave_parallel_workers是否生效：MySQL 5.7+ 需同时满足slave_parallel_type = 'LOGICAL_CLOCK'才能对同一库内的多INSERT并行
INSERT 操作缺少主键或二级索引，让从库回放变慢
当 binlog 是 ROW 格式（推荐），从库应用 INSERT 时虽不依赖索引，但后续若紧跟 UPDATE 或 DELETE，或者该表被用于 JOIN 查询，就会暴露索引缺失问题。更关键的是：如果 INSERT 后立刻有基于 WHERE 条件的 UPDATE，而表没主键/索引，从库就要全表扫 —— 这才是真正拖慢复制的“隐形炸弹”。
- 所有参与复制的表必须有显式主键（
PRIMARY KEY），禁止使用ALTER TABLE ... DROP PRIMARY KEY - 若业务限制无法加主键，在高频更新列上建
INDEX（如status,created_at），降低UPDATE/DELETE回放成本 -
SHOW CREATE TABLE t查看表结构，重点确认PRIMARY KEY存在且非NULL
INSERT 触发锁等待或元数据锁（MDL），冻结整个 SQL 线程
从库 SQL 线程是单线程（除非启用并行复制），一旦遇到锁，后面所有操作全部挂起。典型场景：主库刚执行完 INSERT，紧接着发来 ALTER TABLE；而从库上某个慢查询正持有该表的 MDL 读锁，ALTER 就卡住，连带所有后续 INSERT 都等在队列里。
- 查从库是否有长事务：
SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(NOW() - trx_started) > 60 - 查阻塞源：
SELECT * FROM performance_schema.metadata_locks WHERE OBJECT_SCHEMA = 'db' AND OBJECT_NAME = 't' - 业务 DDL 必须避开高峰期，且从库应禁用非必要长查询（如报表类
SELECT ... GROUP BY）
真正难排查的，不是某条 INSERT 慢，而是它把后面一堆操作都“焊死”在 SQL 线程队列里 —— 尤其当 Seconds_Behind_Master 突然跳涨几十秒，往往意味着前面有个没被注意到的锁或大事务正在闷头执行。
