最常见原因是时间字段类型（TIMESTAMP/DATETIME）与WHERE条件中字符串'2024-01-01'隐式转换失败，实际等价于'2024-01-01 00:00:00'，而数据起始时间可能为08:00:00；应显式写完整边界如create_time >= '2024-01-01 00:00:00'。
导出时 WHERE 条件里时间字段类型不匹配，查不到数据
最常见的情况是：表里时间字段是 TIMESTAMP 或 DATETIME，但你在导出向导里直接写 '2024-01-01' —— 这会被当字符串处理，隐式转换可能失败或范围不对。DBeaver 默认用 JDBC 执行 SQL，不会自动补时分秒，'2024-01-01' 实际等价于 '2024-01-01 00:00:00'，而你的数据可能从 08:00:00 开始。
实操建议：
- 显式写出完整时间边界：
WHERE create_time >= '2024-01-01 00:00:00' AND create_time （推荐用左闭右开，避免跨天重复） - 如果字段是
DATE类型，才可用WHERE create_date BETWEEN '2024-01-01' AND '2024-01-31' - 不确定字段类型？右键表 → 编辑表 → 看“列”页签里对应字段的
Data Type - PostgreSQL 用户注意：
TIMESTAMP WITHOUT TIME ZONE不会自动转时区，服务器时区和客户端不一致时，得手动加AT TIME ZONE
导出向导里写 SQL 时，不能用变量或参数占位符
DBeaver 的“导出数据”向导（右键表 → 导出数据 → 选 SQL 或 CSV）不支持 :start_time、${date} 这类参数语法。你填的 SQL 必须是静态可执行的完整语句。
实操建议：
- 别写
WHERE update_time > :since—— 会报错Parameter ':since' is not set - 真要动态时间？先在 SQL 编辑器里写好带具体时间的查询，执行确认结果正确，再右键结果集 → 导出结果集
- 常用时间范围可存为“SQL 书签”：写好
SELECT * FROM orders WHERE order_time >= '2024-01-01'::timestamp，点工具栏书签图标保存，下次一键调用
导出 CSV 时中文时间字段乱码或格式异常
不是时间逻辑错了，而是导出编码或格式化惹的祸。比如 MySQL 的 DATETIME 导出成 CSV 后显示为 2024-01-01 15:30:45.0（多出 .0），或 Windows 记事本打开全是方块。
实操建议：
- 导出前点向导里的 配置 → 格式 标签页 → 把
Date format改成yyyy-MM-dd HH:mm:ss（去掉毫秒） - 编码务必选
UTF-8 with BOM（尤其 Windows 上用 Excel 打开），否则中文字段（含时间字段旁的备注）易乱码 - 如果时间字段参与了
CONCAT或函数计算（如DATE_FORMAT(create_time, '%Y年%m月')），确保函数返回的是字符串，而非二进制 blob
大数据量按时间分批导出卡死或内存溢出
直接 WHERE create_time BETWEEN '2023-01-01' AND '2024-12-31' 导出千万级数据，DBeaver 客户端容易假死 —— 它默认把整结果集加载进内存再写文件。
实操建议：
- 勾选导出向导里的 使用流式结果集（Stream result set）（MySQL/PostgreSQL 驱动支持，Oracle 需开启
oracle.jdbc.ReadTimeout） - 手动分段导出：用时间字段 + 主键双重限制，例如先导
WHERE create_time >= '2024-01-01' AND id ，再导id > 100000 AND id … - 终极方案：不走 DBeaver GUI，用命令行工具。例如 PostgreSQL 可在终端跑：
psql -d mydb -c "COPY (SELECT * FROM logs WHERE ts >= '2024-01-01') TO '/tmp/logs.csv' WITH CSV HEADER;"
时间条件导出真正麻烦的从来不是语法，而是数据库时区、字段精度、客户端缓存这三者的隐式交互——哪怕 SQL 写对了，一个没设对的 JDBC URL 参数（比如 serverTimezone=UTC）就能让整个范围偏移 8 小时。
