必须先执行sql查询，否则导出按钮置灰或导出为空；navicat结果集默认仅预览前1000行，需手动运行带where的sql并确认结果正确后，再通过右键“导出结果”或导出向导选择all records导出。
必须先执行 sql 查询，否则导出按钮置灰或导出为空——这是最常被忽略的前提，也是所有问题的根源。
导出前没运行查询，导出按钮是灰色的
Navicat 的「结果集」窗口不会自动加载全表数据。你双击一张表看到的只是 LIMIT 1000 的预览，和你要导出的“满足条件的数据”完全无关。右键菜单里的「导出结果」或工具栏的 Export Result 按钮，在没执行过任何查询时直接不可用。
- 确认当前处于「Query」标签页，且已输入类似
SELECT * FROM orders WHERE status = 'shipped' AND created_at >= '2026-07-01'的语句 - 点击绿色三角形 ▶ 执行按钮，等待下方
Result标签页出现真实数据行（注意看行数是否符合预期） - 如果仍灰显，检查是否误在「Table」视图下右键——那里导出的是整张表，不是你的查询结果
导出时只拿到表头、没数据，大概率是 LIMIT 没关掉
Navicat 查询编辑器右下角默认勾选「Limit rows」并设为 1000，这个限制只影响显示，但导出向导若未明确选择「All records」，会沿用该限制，导致只导出前 1000 行（甚至更少，取决于缓存状态）。
- 执行查询前，先取消勾选右下角的
Limit rows，或把数值改为0（表示不限制） - 走「导出向导」时，在第二步「Options」里务必勾选
All records，而不是默认的Current page或Selected records - 如果用快捷导出（
Export Result），它默认导出当前结果集全部可见行——所以必须确保你已看到全部匹配数据（即已关 LIMIT）
WHERE 条件生效但导出顺序乱，是因为没加 ORDER BY
MySQL 等引擎不保证无 ORDER BY 时的返回顺序稳定。今天导出是按主键递增，明天可能变成随机块读顺序，尤其在分库分表或高并发写入场景下。生产数据迁移、比对、归档时，顺序错位会导致后续校验失败。
- 在导出用的 SQL 里显式加上
ORDER BY id或业务关键字段，例如：SELECT id, order_no, amount FROM sales WHERE dt = '2026-07-26' ORDER BY id - 避免依赖 Navicat 自动排序或“看起来有序”的错觉——它只是渲染时按内存顺序排，不等于存储或查询逻辑顺序
- 导出 CSV/Excel 时，列顺序也由 SELECT 字段顺序决定，别指望导出向导能重排字段
导出后发现字段缺失或类型异常，检查是否用了函数或别名
Navicat 导出时会原样使用查询结果集的列名和值。如果 SQL 里用了 DATE(created_at)、CASE WHEN 或 AS alias，导出文件的表头就是函数表达式或别名，而非原始字段名；某些格式（如 Excel）还可能因类型推断错误把数字当文本处理。
- 导出前在结果集里右键 →「Column Settings」，确认每列显示名称是你期望的，必要时用
AS显式命名 - 避免在 SELECT 中直接用函数包裹关键字段，如需转换，优先在目标端处理，或导出后再用脚本清洗
- 导出为 CSV 时，勾选
Export column names并确认编码为UTF-8 with BOM，防止中文列名在 Excel 里乱码
真正容易被绕开的点只有一个：你以为自己在导出「查询结果」，其实 Navicat 此刻记住的只是上一次成功执行的那条 SQL 的缓存结果。换条件后没点运行，就点导出——导出来的还是三天前的测试数据。生产环境里，多一次回车，少一次确认，代价可能是重跑整个 ETL 流程。
