Navicat定时同步本身不直接拉高目标库CPU，真正原因是其生成的SQL引发锁争抢、全表扫描、索引维护及频繁事务提交；需确保主键/索引完备、用自增ID分段+ORDER BY、禁用autocommit批量提交。
navicat定时同步任务本身不直接让目标库cpu飙升，真正拉高目标库cpu的是它生成并执行的sql——尤其是全量同步、无主键表比对、或高频on duplicate key update这类语句，在目标库上引发锁争抢、缓冲池刷脏、索引重建等高开销操作。
同步卡在“Comparing records”时，目标库CPU为何突然上涨
这个阶段Navicat已在本地拉取源表全量数据，但目标库仍要承受大量SELECT查询（用于校验是否存在）和INSERT/UPDATE语句。若目标表缺失主键或UNIQUE NOT NULL索引，Navicat会退化为逐行查+逐行插，触发大量全表扫描或范围扫描：
- MySQL中
SELECT COUNT(*) FROM huge_table WHERE id = ?没走索引 → 触发全表扫描，CPU直线上升 - PostgreSQL中
EXISTS (SELECT 1 FROM target WHERE pk = ?)因索引缺失变成Seq Scan，缓冲池压力陡增 - 同步过程中目标库若同时跑报表或ETL，MDL锁等待会放大CPU空转——Navicat线程反复重试，目标库CPU在“等待锁”和“执行语句”间高频切换
并发线程数设太高，反而让目标库更忙
Navicat「高级」里调高线程数（比如设成8），不会让同步更快，却会让目标库瞬间面对多路并发写入请求：
- 每条线程都尝试执行
INSERT ... ON DUPLICATE KEY UPDATE，触发InnoDB行锁争抢和死锁检测开销 - MySQL的
innodb_thread_concurrency若未调优，多线程写入会加剧内核态调度和锁队列排队 - 实测发现：局域网环境下，线程数从2升到6，目标库CPU使用率常从40%跳到90%+，而总耗时反增15%～30%
- 检查
SHOW PROCESSLIST，若看到大量Updating或Locked状态，就是线程过载信号
增量同步用时间戳字段，目标库CPU悄悄吃紧
用updated_at > '2026-06-09 02:00:00'做增量条件看似轻量，但隐患极深：
- 若该字段无索引，每次同步都触发全表扫描；加了索引，但写入频繁导致B+树分裂和页分裂，CPU花在维护索引上
- 跨时区场景下，Navicat本地时区与目标库
time_zone不一致，查询条件被隐式转换，索引失效 - 更隐蔽的是：批量UPDATE更新
updated_at时，触发二级索引回表+undo log写入+purge线程加速清理，CPU负载成倍叠加
为什么改用自增ID分段同步后，目标库CPU回落明显
自增ID天然有序、索引覆盖好、无类型转换风险，但关键不在ID本身，而在分段逻辑是否规避了热点：
- 错误做法：
WHERE id BETWEEN 1 AND 100000→ 首次同步快，但后续BETWEEN 100001 AND 200000仍需扫描前段索引页，CPU不降 - 正确做法：记录上一次最大
id值，下次查WHERE id > 100000 LIMIT 10000→ InnoDB可定位到对应叶子节点起始位置，扫描路径最短 - 务必配合
ORDER BY id，避免排序内存溢出触发磁盘临时表，否则CPU会被Creating sort index吃掉大半
最容易被忽略的一点：Navicat同步任务默认不关闭目标库的autocommit，每条INSERT都是一次独立事务提交，redo log刷盘+binlog fsync频繁触发，CPU周期性尖刺。真要压降，得在同步前手动执行SET autocommit = 0，同步完再COMMIT——但这要求你绕过Navicat GUI，用外部脚本驱动。这点多数人根本没想到要动。
