必须在从库操作或避开高峰期，勾选“Use WHERE clause”分段导出、启用“Export data in batches”设为5万，并改用CSV格式导出以降低主库CPU和IO压力。
导出大表时 CPU 和 IO 突增，主库响应变慢怎么办
直接在 navicat 上右键「导出向导」→ 选整张千万级表 → 开始执行，大概率会拖慢生产库。因为默认导出走的是 select * 全表扫描，且不带 where 或 limit，mysql 会加载全部数据到内存再发给客户端，同时锁住相关页（尤其 myisam 或未加索引的 innodb 表），连带影响其他查询。
- 必须避开业务高峰期，最好在从库（read-only）上操作；若只有主库，务必确认已开启
innodb_buffer_pool_dump_at_shutdown并调低innodb_buffer_pool_size防止挤占缓存 - Navicat 默认使用「快速导出」模式（即直接读取物理文件），但仅对本地 MySQL 有效，远程连接一律走 SQL 查询路径 —— 这点常被忽略
- 导出前先执行
SHOW CREATE TABLE `orders`;确认引擎、字符集、主键结构，避免导出后建表失败
Navicat 导出设置里哪些选项真正影响性能
关键不是「导出格式」选 CSV 还是 SQL，而是底层查询方式和分片逻辑。Navicat 的「导出向导」里有三个隐藏开关决定负载大小：
-
Use WHERE clause：必须勾选，手动填id BETWEEN 1000000 AND 2000000类分段条件，否则就是全表扫 -
Export data in batches：勾选并设为50000（别超过 10 万），它会让 Navicat 自动拆成多个SELECT ... LIMIT 50000 OFFSET xxx，降低单次内存占用 -
Disable foreign key checks和Use extended inserts只影响导入端，对导出过程无压力，可忽略
为什么用 Navicat 导出比 mysqldump 慢得多
Navicat 是图形客户端，所有数据经由网络协议（MySQL Client API）逐行 fetch，再拼装成文件；而 mysqldump 在服务端直接生成文本流，绕过客户端解析开销。实测同一张 800 万行表，Navicat 导出耗时约 23 分钟，mysqldump --single-transaction --skip-triggers -t -T /tmp/ orders 仅需 4 分钟左右。
QuickBooks Mileage CSV
下载
使用 qbo-mileage CLI 及用户凭证，从 Airtable、Outlook 或 Google Calendar 记录生成 QuickBooks Online 里程 CSV 文件。
- 如果必须用 Navicat，至少关闭「导出时显示进度条」—— 它每 1% 触发一次
SELECT COUNT(*)，对大表是额外负担 - 不要选「导出为 INSERT 语句」，改选「导出为文本文件（CSV/TXT）」，避免 JSON 序列化和 SQL 转义开销
- 导出目标路径尽量选本地 SSD 盘，避免写入 NAS 或远程 SMB 共享目录，I/O 延迟会放大超时风险
导出中途断了怎么续传
Navicat 本身不支持断点续传。所谓「续导」只能靠人工分段 + 记录最大 ID。假设你上次导到 id = 1234567，下一次就在 Use WHERE clause 里填：id > 1234567 ORDER BY id LIMIT 50000。
- 务必确保该字段是主键或有高效索引，否则
ORDER BY id LIMIT会触发 filesort - 导出前先查
SELECT MAX(id) FROM orders;，预估总批次，避免最后一批漏数据 - 每次导出后保存一个
last_id_20260728_03.csv这样的带时间戳+序号的文件名，防止覆盖
真正麻烦的不是导出动作本身，而是分段逻辑没对齐索引、WHERE 条件写错范围、或者误在主库执行未限流查询 —— 这些错误不会报错，但会悄悄拖垮线上服务。
