DBeaver连接数据库时间差8小时，主因是未正确配置时区参数：MySQL需设serverTimeZone=Asia/Shanghai，PostgreSQL需关preferQueryMode并设timezone=Asia/Shanghai，ClickHouse需同时启用use_server_time_zone、use_server_time_zone_for_dates并设use_time_zone=Asia/Shanghai，且所有修改后必须断开重连才生效。
连上数据库后时间差8小时，不是服务器或数据错了，大概率是 DBeaver 没正确传递时区参数——它默认不强制同步服务端时区，也不自动读取系统时区。
MySQL 连接里改 serverTimeZone
MySQL 驱动对时区最敏感，尤其用 datetime 字段时。DBeaver 不会从操作系统或 MySQL 服务端自动推断时区，必须手动指定。
- 右键连接 → “编辑连接” → “驱动属性” 选项卡
- 找
serverTimeZone这一项，值设为Asia/Shanghai（不能写GMT+8或Shanghai） - 如果找不到该字段，点击右下角“添加”按钮，手动加：名称填
serverTimeZone，值填Asia/Shanghai - 保存后必须断开重连，否则设置不生效
PostgreSQL 和 GaussDB 要关掉 preferQueryMode 再设时区
PostgreSQL JDBC 驱动（pgjdbc）默认启用 preferQueryMode=extended，这个模式下某些时区参数会被忽略，导致 timezone 设置无效。
- 在“驱动属性”里先确认
preferQueryMode值是extended还是simple - 改成
simple，再添加或修改timezone字段，值为Asia/Shanghai - GaussDB 同理，且需额外检查服务端
TimeZone参数是否为'Asia/Shanghai'（查SHOW timezone;）
ClickHouse 必须开两个开关 + 指定时区
ClickHouse 存储时间全用 UTC，显示层靠客户端解释。DBeaver 默认不启用服务端时区，所以即使服务器设了 Asia/Shanghai，查询结果仍是 UTC 时间。
- 在“驱动属性”中确保三项都存在且正确：
-
use_server_time_zone=true -
use_server_time_zone_for_dates=true -
use_time_zone=Asia/Shanghai
-
- 缺任意一个，时间都会偏移；设成
false或留空，等于没设 - 服务端也要验证：
SELECT timezone()返回值必须是Asia/Shanghai，否则客户端设了也没用
所有数据库共通的坑：连接复用和缓存
DBeaver 的连接对象一旦建立，会复用底层 JDBC 会话。改完驱动属性不重启连接，旧会话里的时区上下文不会刷新。
- 改完任何时区相关参数，必须执行“断开连接” → 等状态变灰 → 再“连接”
- 不要只点“测试连接”，它只校验链路通不通，不重置会话时区
- 如果连的是带连接池的中间件（如 ProxySQL、pgBouncer），时区可能被池子覆盖，这时得去中间件配，DBeaver 端设了也白搭
真正容易被忽略的是：不同数据库驱动对同一参数名的处理完全不同。MySQL 认 serverTimeZone，PostgreSQL 认 timezone，ClickHouse 却要三个参数配合。填错名字、拼错大小写、漏掉布尔值，都会让设置静默失效。
