DBeaver驱动包一次集齐30+数据库JDBC驱动：下载配置效率翻倍，告别反复折腾
项目地址: https://gitcode.com/gh_mirrors/db/dbeaver-driver-all 一个让我凌晨还在重装DBeaver的夜晚
那天下班前，我收到一条消息："新项目要连一套Oracle 11g，另外还要看ClickHouse和SQLite的数据。"我把这三件事记在便签上，心想：不过是打开DBeaver点几下的事。
结果我在新电脑上装好 DBeaver，新建连接时，界面卡在"正在下载驱动程序"——公司内网访问不了公共仓库，进度条转了两分钟直接失败。退而求其次，我手动去官网找 Oracle 的 JDBC 驱动，下回来的 jar 版本和 DBeaver 预设的驱动类名对不上，连接一直报 ClassNotFoundException。等我把三个库全部配通，已经是凌晨一点。
那晚之后我悟出一个道理：DBeaver 配置的痛，从来不在软件本身，而在那堆 JDBC 驱动 jar 包。于是我开始留意有没有"打包好、一次搞定"的现成方案，然后遇到了 dbeaver-driver-all——一个把几乎所有主流数据库的 JDBC 驱动收进一个仓库的 DBeaver 驱动包，clone 下来就能用，再也不用满世界搜 jar。
最快的上手方式：一条命令 + 一次复制，两分钟搞定
如果你想最快跑通，不用看任何配置文档，照着下面两步做：
第一步，拉取驱动包仓库：
git clone https://gitcode.com/gh_mirrors/db/dbeaver-driver-all
第二步，把 drivers 目录整个复制到 DBeaver 的驱动目录：
| 系统 | DBeaver 驱动目录 |
|---|---|
| Windows | C:\Users\<用户名>\AppData\Roaming\DBeaverData\drivers\ |
| macOS | ~/Library/DBeaverData/drivers/ |
| Linux | ~/.local/share/DBeaverData/drivers/ |
复制完重启 DBeaver，打开驱动管理器你就会看到一排熟悉的数据库：mysql、postgresql、oracle、mssql、clickhouse……全部躺在本地。这种方式最省事，适合"先把它用起来再说"的场景。
一次完整实战：给 DBeaver 配一个干净的 Oracle 驱动
批量复制适合尝鲜，但如果你对驱动版本有要求（比如生产环境锁定 ojdbc8），推荐走"单库精细配置"路线。下面这套流程就是 dbeaver-driver-all 作者在 README 里演示的标准操作，我实际走了一遍，把每一步的关键点记下来。
第 1 步：进入驱动设置。 新建数据库连接，选好 Oracle 后别急着填地址，先点左下角的"驱动设置"入口。
第 2 步：编辑驱动，清掉默认包。 在弹出的驱动管理窗口里点"编辑驱动"，切到"库"（类路径）标签页，把 DBeaver 自带的默认 jar 全部选中删掉。这一步很关键——默认包不删干净，后面加的驱动会和它打架，轻则版本冲突，重则连接报错。
第 3 步：从驱动包目录里选 jar。 打开文件选择器，定位到 dbeaver-driver-all/drivers/oracle/。你会看到 ojdbc8、ojdbc11、orai18n、ucp 等一堆文件。这里有个小讲究：主驱动 jar（ojdbc 系列）必须选，字符集相关（orai18n）、连接池（ucp）这些配套 jar 建议也一起选上，省得后面遇到奇怪的编码乱码问题。
第 4 步：测试连接。 回到连接配置界面，填好主机、端口、服务名，点"测试连接"。如果报错也别慌，多数是连接参数问题而非驱动问题——驱动本身已经就位了。
整个流程 3 分钟，比之前那个"下载失败→到处找 jar→版本对不上"的循环不知道快了多少倍。
这个驱动包真正的设计巧思：它连"依赖"一起打包了
用过 JDBC 驱动的人都知道，很多数据库驱动根本不是单文件。以 ClickHouse 为例，光靠一个 clickhouse-jdbc-0.2.6.jar 根本跑不起来，它还需要 httpclient、jackson-databind、guava、slf4j 这一串配套库。官网上往往只给主 jar，缺的依赖要你自己去 Maven 仓库一个个扒，扒回来还经常版本对不上。
dbeaver-driver-all 的做法很朴素也很实用：每个驱动目录里，主驱动和它的一整套依赖 jar 整整齐齐躺在一起。打开 drivers/clickhouse/ 就能看到完整依赖清单，打开 drivers/redshift/ 能看到 aws-java-sdk 全家桶。这意味着"复制即可用"，不用再赌自己的依赖记忆。
这一点用一句话总结：它不是在收集"驱动文件"，而是在收集"能直接用的驱动单元"。
再来看看多版本策略。同一个数据库，作者保留了多个版本的驱动，适配不同环境：
| 数据库 | 可用版本 | 适用场景 |
|---|---|---|
| MySQL | 5.1.48 / 8.0.29 / 8.2.0 | 5.x 老库和 8.x 新库都覆盖 |
| PostgreSQL | 42.2.25 / 42.7.2 | 保守版和最新版并存 |
| Oracle | ojdbc8 / ojdbc11 | 对应 JDK 8 和 JDK 11+ |
| SQL Server | 9.2.0.jre8 / 12.4.2.jre11 | 还附带 Windows 认证 DLL |
这种"新旧并存"的设计，对经常要在不同环境间切换的人来说太实用了——生产环境锁老版本，本地开发用新版本，一个包全解决。
避坑指南：配置驱动时最容易翻车的 5 个点
把仓库 clone 下来只是第一步，实际配置中这几个坑我全踩过，写出来帮你省时间：
1. 默认驱动没删干净。 前面强调过，编辑驱动时一定要把 DBeaver 自带的默认 jar 移除。两个版本的驱动同时存在，轻则行为诡异，重则直接连不上。
2. 只加了主 jar，没加依赖。 特别是 ClickHouse、Redshift 这类"重依赖"驱动，少一个 httpclient 就报 NoClassDefFoundError。建议直接把整个对应目录的 jar 全选加进去，省心。
3. JDK 版本和驱动版本不匹配。 还在用 JDK 8 的机器，别硬上 ojdbc11 或 jre11 的 mssql 驱动。项目里 oracle 目录下既有 ojdbc8.jar 也有 ojdbc11-23.2.0.0.jar，按自己环境的 Java 版本挑。
4. 依赖下载受网络限制。 如果 DBeaver 还在尝试从远程 Maven 仓库拉依赖，而你的内网屏蔽了这些地址，连接会一直转圈。用本地驱动包之后，记得在驱动管理里把远程仓库源禁用或调低优先级。
5. 连接报错不等于驱动坏了。 驱动配置完成后如果"测试连接"失败，先检查主机、端口、用户名这些连接参数。项目 README 里也特别提了这一点：驱动配置完成后，剩下的报错大多是连接参数问题，别急着怀疑驱动。
进阶玩法：把它变成你自己的"离线 Maven 仓库"
如果你觉得复制 drivers 目录太"粗放"，项目还准备了一套更精细的方案。
仓库根目录下有个 maven/ 文件夹，里面是按标准 Maven 坐标组织好的目录结构：com.oracle.database.jdbc/、org.postgresql/、com.microsoft.sqlserver/ 等，每个坐标下都同时有 jar 和对应的 pom 文件。
玩法是：把 maven 目录复制到 DBeaver 的本地 Maven 仓库路径，然后在 DBeaver → 偏好设置 → 驱动 → Maven 里，把其他远程仓库全部停用，只保留本地仓库。这样 DBeaver 拉依赖时完全走本地，速度飞快，也彻底摆脱网络依赖。官方 README 还建议，如果你一定要用远程仓库，可以直接配阿里云 Maven 镜像，在国内网络环境下下载稳定性会好很多。
再补充一个小技巧：如果你想知道某个库在项目里有没有对应驱动，不用翻目录，一条命令搞定：
find drivers/ -name "*oracle*" -type f
把 oracle 换成任意数据库关键词即可，比如 *mysql*、*postgres*。
这个项目怎么活起来的：更新节奏与参与方式
一个驱动集合包最大的敌人是"过时"。我看了下仓库的更新日志，作者一直跟着 DBeaver 的主版本走——从 7.1.0 一路更新到 24.0.0，最近一次更新还同步了 maven 仓库的使用说明。版本号与 DBeaver 大版本对齐，意味着驱动集合始终和软件本身保持兼容。
更难得的是它的"开放姿态"：README 里明确写着，如果有缺漏的驱动，欢迎提 Issue 补充。也就是说，它不只是作者一个人的收藏夹，而是一个可以被社区持续喂养的公共资源。如果你在工作中遇到包里的驱动版本太旧、或者缺少某个小众数据库，完全可以提 Issue 或直接提交贡献，让下一个遇到同样问题的人少走弯路。
写在最后
数据库驱动这件事，本质上是个"低技术含量、高重复劳动"的苦差事——它不复杂，但每一次都要消耗你的时间、耐心和网络运气。dbeaver-driver-all 把 30+ 数据库的 JDBC 驱动连同依赖一起打包，让你把精力从"找 jar"中彻底解放出来，回到真正值得做的事上：连接数据库、写 SQL、解决问题。
现在就去执行那条 clone 命令吧。两分钟换未来无数次省心，这笔账怎么算都值。
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
