DBeaver导出日期显示为45365是因Excel未识别单元格类型；需确保数据库字段为DATE/TIMESTAMP、JDBC驱动正确返回类型，并配置dateStringFormat等参数控制输出格式。
导出后日期显示为45365这类数字，说明Excel把它当成了序列值
这不是DBeaver导出错了，而是Excel打开时没识别出单元格类型。DBeaver 24.3.0+直出.xlsx时，日期字段会以Excel原生日期类型写入——但前提是目标列在数据库里确实是DATE或TIMESTAMP类型，且JDBC驱动能正确返回类型信息。如果数据库字段是VARCHAR存的"2026-11-03"，DBeaver就只能当文本导出，Excel自然不会转成日期。
验证方法：导出后用Excel打开，选中一个日期列的任意单元格，看编辑栏里显示的是2026-11-03还是46220（对应2026-11-03的序列值）。前者是文本，后者才是真日期但格式被设成了“常规”。
- 数据库字段类型必须是日期类（
DATE、TIMESTAMP），不能是字符串 - MySQL用户需确认连接URL含
useSSL=false&serverTimezone=Asia/Shanghai，否则JDBC可能把时间转成UTC再丢给DBeaver - PostgreSQL用户注意
timestamp without time zone和with time zone行为差异，后者在导出时可能触发时区转换
导出前强制指定日期格式，避免依赖Excel自动识别
DBeaver本身不提供“导出时统一设Excel单元格格式”的图形选项，但可以通过JDBC连接参数间接控制日期字符串的呈现方式。这招对VARCHAR型日期字段或需要固定显示样式的场景特别有用。
操作路径：数据库连接 → 编辑连接 → 驱动属性 → 添加新属性：
-
dateStringFormat值设为yyyy-MM-dd（影响DATE字段的字符串化输出） -
timestampStringFormat值设为yyyy-MM-dd HH:mm:ss（影响TIMESTAMP） - Oracle用户额外加
oracle.jdbc.mapDateToTimestamp=false，防止把DATE全映射成TIMESTAMP
这样导出的.xlsx里，即使日期被当成文本写入，内容也是标准格式字符串，后续在Excel里用DATEVALUE()批量转换也更稳。
低版本DBeaver（
老版本没有原生XLSX导出器，走CSV中转时极易出问题：用逗号分隔遇上字段含逗号、纯UTF-8编码被Excel误判为ANSI导致中文乱码、日期字段被Excel当成文本但格式又设错——结果就是双击单元格才变日期。
把记录数组导出为带样式的 Excel(xlsx) 或带 BOM 的 CSV。支持列配置（表头/宽度/顺序）、表头冻结首行、斑马纹、布尔值转「是/否」、数组换行、CSV 中文防乱码。零依赖。触发词：导出 Excel、导出 CSV、记录转表格、列配置导出、数据导出、表格美化、JSON 转表格。
关键配置必须一步到位：
- 导出格式选
CSV文件，编码选UTF-8 with BOM（不是“UTF-8”） - 分隔符强制改成
\t（制表符），避开文本内逗号干扰 - 勾选
使用文本限定符，字符选"（双引号） - Excel导入时走
数据 → 从文本/CSV，第二步手动勾选制表符，第三步逐列点开设类型：日期列选日期 → YMD
跳过“直接双击打开CSV”这个动作，那是所有日期崩坏的起点。
导出大结果集时日期列突然变空或报错，检查内存与驱动边界
导出超10万行以上数据时，DBeaver可能因内存不足或Apache POI驱动限制，跳过类型推断逻辑，把所有列当字符串处理。此时即使数据库字段是TIMESTAMP，导出的XLSX里日期列也会变成空或#VALUE!。
临时缓解办法：
- 在SQL里显式转换：
TO_CHAR(created_at, 'YYYY-MM-DD') AS created_date（Oracle）或DATE_FORMAT(created_at, '%Y-%m-%d') AS created_date（MySQL） - 导出前在DBeaver设置里调高堆内存：
-Xmx4g（帮助 → 编辑配置 → vmoptions） - 确认DBeaver使用的Apache POI版本 ≥ 5.2.4（关于 → 安装详情里可查，旧版POI对大文件日期写入有已知bug）
真正稳定的解法，是升级到24.3.0+并用原生XLSX导出——它绕过了CSV解析链，直接调用POI写入二进制流，类型保留率接近100%。
