Navicat自动导出生效需满足：1. schedule用标准5段Cron表达式且匹配服务器本地时区；2. {datetime}占位符仅支持{datetime}或{datetime:yyyyMMddHHmmss}；3. charset和dateFormat对XLSX无效。
导出任务里 schedule 参数怎么设才真正生效
navicat 企业版的“自动导出”不是点一下“启用计划”就完事——schedule 必须是合法的 cron 表达式，且时区默认是系统本地时间（不是 utc，也不是 navicat 客户端所在时区）。很多人填了 0 0 * * * 却发现每天 0 点没执行，其实是服务器时间比你预期快/慢几小时。
-
schedule字段只认标准 Cron 格式（5 段），不支持@daily这类别名 - Windows 服务模式下，Navicat 后台服务以 LocalSystem 身份运行，它读取的是服务器系统时间 + 系统时区设置
- 如果服务器在阿里云上海节点，但系统时区设成了
UTC，那0 0 * * *就真在 UTC 凌晨 0 点跑，相当于北京时间早上 8 点 - 验证方式：在任务日志里找第一行时间戳，对比服务器
date命令输出
导出文件名里的 {datetime} 占位符为什么总报错
这个占位符看着方便，但实际只支持有限格式，且大小写敏感。写成 {DateTime} 或 {datetime:yyyy-MM-dd} 都会静默失败——导出目录空空如也，日志里只有一句 Failed to generate filename。
- 合法写法只有
{datetime}（无参数）或{datetime:yyyyMMddHHmmss}（仅支持该固定格式字符串） - 不支持
yyyy-MM-dd HH:mm:ss中的空格、冒号、短横以外的符号；斜杠/会导致路径解析错误 - 如果导出路径是
D:\reports\{datetime}_sales.xlsx，而当前时间是 2024-06-12 14:30:45，则生成D:\reports\20240612143045_sales.xlsx - 注意：该占位符在 Windows 和 Linux 下行为一致，但路径分隔符需手动用
\或/，不能混用
MySQL 大表导出卡住或超时，fetchSize 和 timeout 怎么调
默认导出走的是 Navicat 内置 JDBC 驱动的一次性 fetch，10 万行以上就容易 OOM 或触发 MySQL 的 wait_timeout。关键不是调大内存，而是控制单次拉取量和网络等待。
-
fetchSize建议设为5000～10000（整数），值过大会抵消流式优势，过小则频繁网络往返 -
timeout是连接级超时（单位秒），必须大于单次查询预计耗时 × 分页次数；例如查 50 万行、fetchSize=5000，共 100 次 fetch，每页平均 2 秒，那就至少设220 - MySQL 侧要同步检查
net_read_timeout和net_write_timeout，建议 ≥timeout值 - 不建议改
max_allowed_packet来硬扛，导出过程不走 packet 拆包逻辑
导出 Excel 时中文乱码、日期变数字，charset 和 dateFormat 到底管不管用
这两个参数只对 CSV 有效，对 XLSX 完全无效。Navicat 导出 XLSX 用的是 Apache POI，字符集由 JVM 启动参数决定，日期格式则取决于 Excel 自身单元格类型。
- CSV 场景下：
charset=UTF-8可解决中文乱码，dateFormat=yyyy-MM-dd HH:mm:ss控制时间字段文本呈现 - XLSX 场景下：乱码大概率是 Navicat 启动脚本里没加
-Dfile.encoding=UTF-8；Windows 上常见默认 GBK - XLSX 里日期显示为 44723 这种数字，是因为 POI 写入的是 Excel 序列号，不是字符串——这是正常行为，双击单元格或设置单元格格式为日期即可恢复
- 真要导出纯文本日期，只能换 CSV +
dateFormat，或者导出后用 Python 脚本二次处理 XLSX
事情说清了就结束。最常被忽略的是：Cron 时区、{datetime} 格式硬编码、以及 XLSX 本质不认 charset——这三处一错，整个自动化就静默失效，连错误提示都藏得深。
