linux版navicat执行超大sql脚本易崩溃，核心原因是其electron架构在linux下内存管理、gpu加速和字体渲染更脆弱，300mb以上脚本常触发oom killer主动终止进程。
Linux 版 Navicat 执行超大 SQL 脚本更容易崩溃，核心原因不是系统本身，而是它默认运行在 Chromium 渲染引擎（Electron 架构）上，且 Linux 下的内存管理、GPU 加速和字体渲染链路更脆弱——尤其当脚本 >300MB 时，进程常因 OOM killer 主动终止，而非像 Windows 那样卡死在 GUI 线程。
为什么 Linux 下 Navicat 进程会被系统直接 kill
Linux 内核的 OOM killer 会在物理内存 + swap 耗尽时，按 oom_score 选中“最该杀”的进程。Navicat（Electron 应用）在解析大 SQL 时：
- 全量读入内存并构建 AST 树，堆内存占用线性增长
- Chromium 默认启用 GPU 加速，但多数 Linux 桌面环境（如 X11 + 开源显卡驱动）无法稳定释放纹理内存
- 字体回退机制（fallback font）在解析含中文注释的 SQL 时反复触发 fc-cache，额外吃掉数百 MB 内存
结果就是：top 看到 navicat 进程 RSS 突然飙到 4GB+，紧接着 dmesg | tail 显示 “Out of memory: Kill process navicat (PID xxx) score yyy”
Linux 下「运行 SQL 文件」比 Windows 更容易报 Packet too large
这不是服务端 max_allowed_packet 没调，而是 Navicat 自身在 Linux 下对 TCP 缓冲区处理更保守：
- 它用 libcurl 封装 MySQL 协议，但未显式设置 CURLOPT_BUFFERSIZE，依赖系统默认 socket 缓冲区（通常仅 256KB）
- 当遇到一条超长 INSERT INTO ... VALUES (),(),()...（比如单条 8MB），Navicat 尝试一次性 send()，内核返回 EMSGSIZE，它误判为 “Packet too large”，弹窗报错并中断
- 同样的 SQL 文件，在 Windows 下因 Winsock 的缓冲区自适应策略，可能侥幸分片发出去
Linux 下必须禁用的三项 GUI 特性
这些功能在 Linux 桌面环境下极易引发内存泄漏或渲染阻塞：
- 禁用硬件加速：启动时加 --disable-gpu 参数（如 ./navicat --disable-gpu），否则 Qt/Chromium 混合渲染会卡死在 glXMakeCurrent
- 关闭字体平滑：在 ~/.navicat/system.conf 中添加 font_antialias=false，避免解析含 emoji 或 CJK 注释时触发 freetype 多次重排
- 强制使用 X11 后端：即使你用 Wayland 桌面，也加 QT_QPA_PLATFORM=xcb 环境变量，Wayland 下 QPainter 对大文本控件支持极差
真正容易被忽略的是：Linux 下 Navicat 的自动任务（Scheduled Task）根本不会触发系统级内存回收——它不像 Windows 那样有 Session 0 隔离，所有后台线程共享主进程地址空间，一旦某个 SQL 解析失败，AST 树残留、连接池句柄不释放、日志缓冲区膨胀，下次任务启动时直接复用脏状态，OOM 概率翻倍。
