简介：适用于Linux ARM 64位环境的DBeaver社区版21.2.5安装包，采用不含JDK的tar.gz格式封装。DBeaver是功能全面的通用数据库管理工具与SQL客户端，支持MySQL、PostgreSQL、Oracle、DB2、MSSQL、Sybase、HSQLDB、Derby及其他兼容JDBC的数据库，提供图形化界面用于查看库表结构、执行SQL查询与脚本、浏览导出数据、处理BLOB/CLOB数据及修改数据库结构等，适合开发者在ARM服务器或嵌入式Linux平台上部署使用。压缩包共578个文件，总大小67.6MB，主体为392个jar插件与运行库，辅以css/html界面资源、properties/xml配置、签名校验文件、md/txt说明文档及启动脚本，目录组织完整，可解压即用。目前已有945人学习下载。该版本为aarch64架构专门构建，无需自行安装JDK，适合离线部署；包内核心模块与辅助资源分区存放，升级排查较为便利，是一个开箱即用的数据库客户端解决方案。
1. DBeaver 在 aarch64 Linux 上的免安装包：先搞清楚它是什么
DBeaver 是我在多个数据库之间切换时最常打开的桌面工具，这次要在一台国产 aarch64 服务器上做日常巡检，手边正好缺一个能用的 SQL 客户端。DBeaver 是开源社区里用户量最大的通用 SQL 客户端之一，连接 MySQL、PostgreSQL、Oracle、SQL Server 都不在话下，还支持结果集图表、批处理执行和 ER 图查看。标题里的 dbeaver-ce-21.2.5-linux.gtk.aarch64-nojdk.tar.gz 表示这是社区版 21.2.5，Linux 平台基于 GTK 图形库，aarch64 架构，且没有捆绑 Java 运行时。
这个包解决的是“在 ARM64 Linux 设备上快速获得一个能统一管理多种数据库的 GUI 工具”的问题，适合在鲲鹏、飞腾、树莓派这类 aarch64 设备上做开发或运维的人。下面我把它从解压开始讲，一直落到连接数据库和排错，中间会写清楚参数怎么设置、启动脚本怎么配，以及我在实际环境里踩过的几个坑。
2. 为什么选 tar.gz 的 nojdk 包：依赖关系和版本场景
2.1 先读懂文件名里的每个字段
DBeaver 的官方发布包命名不是随便写的。dbeaver-ce-21.2.5-linux.gtk.aarch64-nojdk.tar.gz 这段字符串可以拆成五部分，每一部分都对应一个选型决策：
| 文件名片段 | 含义 |
|---|---|
| dbeaver-ce | 社区版，免费无授权限制 |
| 21.2.5 | 版本号，这套命名是 2021 年之后 DBeaver 采用的日期化版本规则 |
| linux.gtk | Linux 下基于 GTK 图形框架的客户端 |
| aarch64 | ARM 64 位指令集，专门给鲲鹏、飞腾、Apple Silicon 这类 CPU 使用 |
| nojdk | 压缩包内不携带 Java 运行时，需要系统已安装 JDK |
很多人下载时会直接挑最上面的文件，看到“linux”就下，结果在 aarch64 机器上跑出 Exec format error。原因很简单：同一个版本的 DBeaver 在 Linux 下会同时提供 x86_64 和 aarch64 两种包，少数发行版还会区分 armhf 的 32 位 ARM 包。标题这个包就是给 aarch64 准备的，选错架构连解压后的二进制都无法执行。
2.2 nojdk 与自带 JDK 的差异，以及为什么值得选它
同一个版本通常有带 JDK 和不带 JDK 两种发布物。带 JDK 的包体积更大，因为里面塞了一个完整的 JRE，解压后能直接运行，适合给“机器上没有 Java 环境但又不想折腾”的用户。nojdk 包则不包含任何 Java 运行时，启动时依赖环境变量里配置的 JDK。
我个人在服务器上更倾向 nojdk 包，理由有三个：第一，服务器上通常已经装了 JDK 8 或 11，让 DBeaver 复用系统的 Java，能省掉一份 JRE 的磁盘占用；第二，显式设置 JAVA_HOME 可以避免自带 JRE 与系统里的 SSL 库、字体库发生冲突，这种冲突往往表现为启动闪退或字符乱码，玄学概率很高；第三，后续升级 JDK 时只需要替换系统默认版本，DBeaver 本身不用重装。
代价也很直接：nojdk 包要求机器上必须有一个 64 位 JDK，版本至少要 Java 8。如果系统只装了 32 位 ARM Java，或者根本没有 Java，启动脚本就会报“找不到 JVM”或“Java was started but returned exit code=13”。这一点我在后面的避坑章节会展开讲。
2.3 为什么 aarch64 不能直接拿 x86_64 包来用
aarch64 是 ARM 的 64 位指令集，和 x86_64 的二进制机器码完全不互通。x86_64 的 DBeaver 包在 aarch64 系统上根本无法运行，内核会在执行时直接拒绝。国产芯片里鲲鹏、飞腾，以及海思的服务器芯片，基本都是 aarch64 架构；树莓派 4B 之后的系统也是 aarch64 用户态。如果你所在的云平台售卖的是 ARM 实例，也需要用带 aarch64 的包。
此外，包名里的 gtk 说明它依赖 GTK 库来渲染图形界面。在无头服务器上，即使二进制解压成功、Java 配置正确，没有 DISPLAY 环境变量，DBeaver 也启动不了窗口。需要用 SSH 的 X11 转发或 VNC 远程桌面来承载界面。这个判断要在安装前做好，不然会卡在“装了打不开”这一步。
2.4 为什么不用发行版自带的 dbeaver 包
大部分发行版软件源里都提供了 dbeaver，Debian 系用 apt 能直接装上。但 aarch64 仓库里的 dbeaver 经常版本滞后，我在几个 ARM 源里见过停留在 20.x 的版本，和云端同事的客户端版本不一致会导致一些数据库特性测试结果有偏差。官方 tar.gz 包的好处是版本可以精确控制，团队统一用 21.2.5 时，同一个包反复拷贝到多台机器，行为完全一致。离线环境尤其适合——tar.gz 可以在有网的地方下载，然后拷贝到内网，配合本地已有的 JDK 就能直接用，省去在线安装器要联网拉驱动的麻烦。
3. 在 aarch64 Linux 上装好它：解压、环境与启动的完整流程
3.1 安装前检查：架构、JDK、图形库
不要下载完就直接解压。先用两分钟检查环境是否匹配：
uname -m java -version 2>&1 ldconfig -p | grep -E 'libgtk-x11|libxtst' ; true第一条 uname -m 输出必须是 aarch64。如果出来的是 x86_64，说明下载错了包，再往下解压也是浪费时间。第二条看 java 版本，注意要有“64-Bit”字样，并且版本不低于 1.8。如果 java 不存在，则后面启动必定失败。第三条用 ldconfig 查 GTK 和 X11 相关库，这里只是粗查，没有输出不代表没有库，但能提前发现明显的缺失。
我通常还会再看一眼 JAVA_HOME 是否指向正确目录：
echo $JAVA_HOME readlink -f $(which java)readlink 能拿到 java 命令的真实路径，比如 /usr/lib/jvm/java-11-openjdk-arm64/bin/java，往上一两级就是 JAVA_HOME。这样确认可以避免后续“Java was started but returned exit code=13”这种和架构错位相关的报错。
3.2 解压 tar.gz 并确认目录结构
我习惯把 DBeaver 放到 /opt 这类统一目录下，方便多用户共享。解压命令如下：
sudo mkdir -p /opt/dbeaver sudo tar -xzf dbeaver-ce-21.2.5-linux.gtk.aarch64-nojdk.tar.gz -C /opt/dbeaver --strip-components=1tar -xzf 表示解压 gzip 压缩包，x 解包，z 解压缩，f 指定文件名。-C 指定目标目录，--strip-components=1 表示把压缩包顶层的 dbeaver/ 目录剥掉，直接展开到 /opt/dbeaver 下。如果不加 --strip-components，解压后会多出一层 /opt/dbeaver/dbeaver，启动脚本的相对路径会偏移，DBeaver 能启动，但工作目录不干净。
解压完后检查目录：
ls -lh /opt/dbeaver应该能看到 dbeaver、dbeaver.ini、plugins、features 这些标准 Eclipse 布局。接着再执行：
ls /opt/dbeaver | grep -i jre ; true我不是真的想要 jre 目录，而是在确认这个包确实是 nojdk。如果 grep 没有输出，说明压缩包里没有自带 Java 运行时，符合“没有捆绑 JDK”的预期。如果输出一个 jre 目录，那就要重新检查文件是否下错成了带 JDK 的版本。
3.3 配置 JAVA_HOME 并完成首次启动
nojdk 包的启动脚本会先找 JAVA_HOME，找不到再从 PATH 里找 java。所以启动前必须把 JAVA_HOME 指对。我不建议只在当前 shell 里 export，因为你换一个会话就又没了。我一般写进 /etc/profile.d/dbeaver.sh：
sudo tee /etc/profile.d/dbeaver.sh > /dev/null <<'EOF' export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-arm64 export PATH="$JAVA_HOME/bin:$PATH" EOF source /etc/profile.d/dbeaver.sh然后把 JAVA_HOME 替换成实际路径。如果不确定，就先执行 readlink -f $(which java) 找到真实路径，再往上推。我见过很多人在这个文件里写错路径，启动时依旧提示找不到 Java，解决方法是先把那行 export 单独在终端跑一遍，确认可行后再固化到文件。
首次启动执行：
/opt/dbeaver/dbeaver第一次启动会初始化 workspace，界面响应会慢一些，属正常现象。看到主界面后，在帮助菜单里能确认版本。如果直接闪退，不要急着重新解压，先检查日志和系统库，这些我放在后面专门写。
3.4 给 DBeaver 加一个桌面启动器
服务器上用 RDP 或 VNC 登录后，每次都到终端敲 /opt/dbeaver/dbeaver 很麻烦。我习惯在用户目录放一个 desktop 启动器：
mkdir -p ~/.local/share/applications cat > ~/.local/share/applications/dbeaver.desktop <<EOF [Desktop Entry] Name=DBeaver Comment=Universal SQL Client Exec=/opt/dbeaver/dbeaver Icon=/opt/dbeaver/icon.xpm Terminal=false Type=Application Categories=Development;Database; EOF这里 Exec 指向启动脚本，Icon 指向解压目录里的图标文件。如果图标路径不对，桌面图标会变成空白，但启动不受影响。需要提醒的是，这个 desktop 文件里的路径必须是绝对路径，不能用 $HOME 变量，否则某些桌面环境解析不了。
4. 连接数据库的配置：从驱动参数到连接串的实操
4.1 驱动管理器的运作方式
DBeaver 本身不内置完整的 JDBC 驱动，它内置的是驱动定义。第一次使用某个数据库类型时，会在“数据库 -> 驱动管理器”里根据定义从 Maven 仓库下载对应 jar。网络通畅时这一过程是无感的；如果内网不通，连接测试会报“Can't download driver files”一类错误。
解决方法是手动添加本地 jar。以 MySQL 为例，在驱动管理器里选择 MySQL 条目，切到“库”页签，点击“添加 JAR”，把 mysql-connector-java.jar 指定进去。这些 jar 是纯 Java 字节码，不依赖 CPU 架构，所以 aarch64 上不需要考虑 ARM 适配。我习惯把常用驱动 jar 放到 /opt/dbeaver/drivers 目录，方便同一环境重复使用。
4.2 创建 MySQL 连接时的参数参考
创建工作区连接时选择 MySQL，填写主机、端口、数据库名、用户名和密码。DBeaver 会拼接出 JDBC URL，也可以手动覆盖。我在本地和服务器上常用的 MySQL 连接串如下：
jdbc:mysql://127.0.0.1:3306/test?useSSL=false&useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai这段参数拆开看：useSSL=false 是为了避免本地开发时因证书校验产生的 TLS 告警，生产环境如果允许 SSL 认证，不应该照抄；useUnicode=true 和 characterEncoding=utf8 是给中文数据保命，少了它很容易出现乱码；serverTimezone=Asia/Shanghai 是因为 MySQL 驱动 8.0 之后要求明确时区，不设置可能直接抛异常。
在连接设置里点“测试连接”，如果能显示服务器版本和驱动版本，说明驱动、网络、账号三者都通了。这里有个小习惯：测试连接时不要勾选“连接后读取全部元数据”，否则初始化会很慢，第一次连的时候容易误以为卡死。
4.3 PostgreSQL 和 SQL Server 的差异
PostgreSQL 的 URL 比 MySQL 短很多：
jdbc:postgresql://127.0.0.1:5432/mydb字符集主要由服务端决定，客户端参数不用像 MySQL 那样折腾。SQL Server 的 URL 则要注意数据库名和实例名：
jdbc:sqlserver://127.0.0.1:1433;databaseName=mydb驱动类名是 com.microsoft.sqlserver.jdbc.SQLServerDriver。我在 aarch64 上连 SQL Server 时遇到过一个奇怪问题：连接建立成功，左侧树也能展开库，但表列表一直空白。这个问题大概率是驱动版本太旧，对 SQL Server 2019 以后的一些元数据查询不兼容，把驱动换到官方最新版就能解决。这个坑不是 aarch64 特有的，但值得单独记一笔。
4.4 从日志定位连接问题
连接失败时，DBeaver 弹窗只给一句话，真正有用的信息在日志里。执行：
tail -n 200 ~/.dbeaver/.metadata/.log这个日志记录了驱动加载、连接尝试和异常堆栈。ClassNotFoundException 基本是 jar 缺失；Access denied 是账号权限；Connection reset 是网络或防火墙。看日志时我习惯把 ERROR 开头的行单独过滤：
grep -i "ERROR" ~/.dbeaver/.metadata/.log | tail -n 50先找第一个 ERROR，不要从头翻到尾。日志文件会越积越大，排查完可以清空，DBeaver 重启后会自动重建。
5. 避坑经验：aarch64 环境最容易翻车的几个点
下面是我在 aarch64 Linux 上安装和使用 DBeaver 过程中实际遇到的问题，每一条都按“现象 -> 原因 -> 解决”记录，适合直接当排查手册翻。
5.1 启动闪退：缺少 libgtk-x11-2.0.so.0
现象：执行 /opt/dbeaver/dbeaver 没有出现界面，终端里不报错，或者提示 cannot open display。用 ldd 检查二进制时，能看到 libgtk-x11-2.0.so.0 => not found。
原因：aarch64 Linux 服务器经常是最小化安装，只带了命令行环境，没有装 GTK2 图形库。DBeaver 21.2.5 这个版本用的 SWT 对 GTK2 依赖很重，系统缺这类库时，启动脚本会静默退出，或者因为 DISPLAY 为空而报 X11 错误。
解决：Debian/Ubuntu 系安装依赖：
sudo apt update sudo apt install -y libgtk2.0-0 libxtst6 libxrender1 libxi6装完再启动。有些机器装了 GTK3，但这一版的 DBeaver 对 GTK3 兼容并不好，优先考虑装 GTK2。这个问题解决后，DBeaver 才能正常画界面。
5.2 连接 SQL Server 后数据表不显示
现象：连接 SQL Server 成功，左侧数据库导航树能看到库，但表、视图列表一直为空，刷新也没有反应。
原因：我一开始怀疑是账号权限不够，后来发现是 DBeaver 21.2.5 内置的 SQL Server 驱动版本偏旧，对 SQL Server 2019 之后的元数据协议兼容有问题。不是所有环境都复现，但在一台 SQL Server 2019 + 新实例上很容易出现。
解决：在驱动管理器里把 SQL Server 的驱动替换成微软官方最新的 mssql-jdbc jar，然后重新建立连接。替换后不需要重启 DBeaver，重新加载驱动即可。如果替换后还是空白，那就检查账号是否能读取 target schema，比如用户是否被赋予了默认 schema 的权限。
5.3 nojdk 包提示 Java was started but returned exit code=13
现象：运行 dbeaver 后弹窗报错，提示 Java was started but returned exit code=13。终端里能看到同样信息。
原因：这个 exit code 13 在 Eclipse 系应用里，本质是 SWT 加载失败或 Java 版本/架构不匹配。常见于 JAVA_HOME 指向了 32 位 JVM，或者 JDK 版本低于 8。aarch64 机器上如果装了 armhf 的 JDK，java -version 会显示“32-Bit”，DBeaver 启动脚本跑起来就会撞上这个错误。
解决：先执行 java -version 确认 JVM 是 64-Bit、aarch64；再执行 readlink -f $(which java)，把 JAVA_HOME 指到真实 JDK 路径。如果系统只有 JRE，也要换成完整 JDK，因为 SWT 可能需要 javac 相关组件。装一个 openjdk-11-jdk-headless 后重新设置，问题就能解决。
5.4 中文乱码：查询结果全是问号
现象：查询结果里中文全部变成 ?，写入中文后读取也是乱码。
原因：客户端连接参数没指定 Unicode 字符集，或者服务器端字符集不是 utf8。MySQL 5.7 时代这里坑最多，DBeamer 默认按 URL 推断，有时候推断结果不是实际编码。
解决：在连接 URL 上加上 useUnicode=true&characterEncoding=utf8，MySQL 环境下还可以在驱动属性里配置 connectionInitSql 为 set names utf8mb4。改完重启连接。如果是 PostgreSQL，可以用 psql 检查 server_encoding，通常是服务端字符集本来就乱。有一点容易忽略：修改 DBeaver 编辑器的字体并不能根治乱码，核心必须放在 JDBC URL 上。
6. 最后一步：验证安装与确认连接状态的三个习惯
安装和排错都跑通后，不要急着高兴，把验证流程固定下来。我现在每次在 aarch64 Linux 上装完 DBeaver，都强制走一遍下面三个步骤。
第一步，确认工作空间能正常初始化。在启动命令前先看日志：
rm -f ~/.dbeaver/.metadata/.log /opt/dbeaver/dbeaver & sleep 10 grep -i "error" ~/.dbeaver/.metadata/.log ; true这不是让你真的删日志，而是用一个干净的日志来验证启动过程。如果 grep 没有输出，说明启动阶段没有致命错误。如果输出内容，优先看第一行 error 出现的位置，不要被后续刷屏干扰。
第二步，在能连接数据库之前，我习惯先用命令行模拟一次 JDBC 连接，排除 GUI 干扰。这个步骤可以省略，但如果你想确认“DBeaver 安装本身没问题”，直接在 DBeaver 里打开 SQL 控制台执行 SELECT 1 是最快的。看到返回值，说明驱动、网络、账号都通，安装环节到此结束。
第三步，把环境变量写入持久化配置并重新登录验证：
env | grep -E 'JAVA_HOME|DBEAVER'如果重新登录后 JAVA_HOME 还在，说明 profile.d 里的配置生效了。我自己的习惯是，把这三步写进一个 deploy 脚本，下次装新版时直接跑，不再靠记忆操作。
从那以后我每次给 aarch64 Linux 装 DBeaver，都会先花两分钟把“架构、JDK、GTK 依赖”这三样对一遍，再往下走。机器不同，坑却总是那几个，提前绕开比事后修快得多。希望这份笔记能帮你少走点弯路。
本文还有配套的精品资源，点击获取
