navicat导入数据易触发undo log溢出，因其默认单事务逐行插入导致历史版本堆积；须启用“每x行提交一次”（建议1000）、禁用导入前清空表、配合调优purge线程及避免长事务。
navicat 导入数据时触发 undo log 溢出，本质不是 navicat 的问题，而是它默认用单条 insert 语句逐行提交（尤其在“插入前清空表”或“忽略重复”模式下），导致事务过长、历史版本堆积。直接调大日志空间只是掩耳盗铃，关键得控制事务粒度和生命周期。
为什么 Navicat 导入会压爆 Undo Log
Navicat 的“导入向导”在处理 Excel/CSV 时，默认将整批数据封装进一个事务执行（除非显式勾选“每 X 行提交一次”）。对 InnoDB 来说：
- 每一行
INSERT都生成对应的 undo 记录，用于回滚和 MVCC 读视图 - 整个事务不结束，这些 undo 记录就无法被 purge 线程清理
- 若导入 50 万行，
History list length可能瞬间飙到几十万，undo 表空间暴涨，甚至阻塞其他写操作
Navicat 里必须开启的分批提交设置
别信“自动优化”，手动锁死分批参数才是底线：
- 导入向导 → “高级”选项卡 → 勾选
每 X 行提交一次，值设为1000（不要超过 5000） - 取消勾选
导入前清空表，改用 Navicat 单独执行TRUNCATE TABLE（它不走 undo，且隐式提交） - 如果目标表有唯一索引或外键，勾选
禁用外键检查和禁用唯一性检查，减少约束校验开销 - 导入前确认连接使用的 autocommit=ON（Navicat 默认是 ON，但某些配置可能关掉）
MySQL 侧配合调整：不能只靠 Navicat
光靠客户端分批不够，服务端得给 purge 线程“松绑”：
- 确认
innodb_purge_threads≥4（默认是 1，高并发导入时严重不足） - 临时调高
innodb_max_purge_lag（如设为1000000），避免因 purge 滞后主动限流写入 - 检查
SHOW ENGINE INNODB STATUS\G中的History list length，若持续 > 50000，说明 purge 跟不上，需进一步调参或查长事务 - 严禁在导入期间执行
SELECT ... FOR UPDATE或长时间未提交的事务——它们会把最老读视图钉死，让所有 undo 都无法释放
真正安全的替代方案：绕过 Navicat 导入
当数据量超 10 万行，或表结构复杂（含 JSON、全文索引等），Navicat 导入就是定时炸弹：
- 用
mysqldump --skip-extended-insert导出为多行INSERT，再用mysql命令行导入（它天然按语句提交，且无 GUI 内存开销） - Excel 先另存为 UTF-8 编码的 CSV，用
LOAD DATA INFILE（要求文件在 MySQL 服务器本地，速度快、不走 undo） - 写个 Python 脚本，用
pymysql+executemany()批量插入，手动控制connection.commit()间隔
Undo Log 不是缓存，是事务一致性的基石。压爆它的从来不是数据量本身，而是“把 10 万次修改锁在一个事务里”这种反模式操作——Navicat 的图形界面容易让人忽略这层代价。
