其实很多人一听“安装数据库”，脑子里就蹦出 Oracle、MySQL 那些“大块头”，光是配置就得折腾半天。Derby 恰恰相反，它是 Java 生态里出了名的轻量级选手。你甚至不需要专门装服务，只要把它当成普通的 jar 包扔进项目里，就能直接跑起来。这玩意儿是 Apache 家的开源产品，完整名称叫 Java DB，实际上 Sun 以前还把它打包进 JDK 里当内置数据库用过。所以它的安装，基本就是“复制粘贴”的活儿。
但问题也出在这儿——正因为太简单，反而容易让人掉坑。我见过不少新手，下载完 Derby 后，对着一个 zip 包发愣：“然后呢？没有安装向导？没有下一步？”对，Derby 的安装就是解压，然后设置环境变量。把 bin 目录加到 PATH，把 lib 目录下的 derby.jar 加到 CLASSPATH，就算装好了。验证方式也很直接：打开命令行，敲 ，能启动就说明成功。
不过有个细节很多人会忽略：Derby 有两种运行模式——嵌入式和网络服务器模式。嵌入式模式最省事，Java 程序直接通过 JDBC 驱动连进来，Derby 就运行在同一个 JVM 里，连端口都不用开。但如果想让多个应用同时访问同一个数据库，就得使用网络服务器模式。这时需要单独启动一个叫 的进程，默认监听 1527 端口。很多人装完后发现连不上，多半是因为没分清这两种模式。
安装过程中最容易翻车的地方，其实是 Java 环境。Derby 是用 Java 写的，它依赖 JDK 或 JRE。如果机器上没装 Java，或者版本太老（比如 Java 8 以下），Derby 很可能直接罢工。建议装之前先用 确认一下，至少是 Java 8 以上。另外，环境变量 最好也配置一下，虽然不配也能用，但配了后启动网络服务器、执行工具命令会方便很多。
说到工具，Derby 自带几个命令行工具，比如 （交互式 SQL 工具）、（数据库结构导出）和 （查看运行时信息），都在 bin 目录下。我最常用的是 ，启动后可以直接写 SQL 建表、插入、查询，跟 MySQL 的 shell 差不多。但有个坑： 默认连的是嵌入式模式，如果已经启动了网络服务器，需要用 这种 URL 才能连上。很多人一上来就敲 ，结果报错“数据库不存在”，其实是模式搞混了。
数据库文件放哪儿也是个问题。Derby 默认在当前工作目录下创建数据库目录。比如在 里启动 ，执行 ，它就在该目录下生成一个叫 的文件夹，里面全是数据文件。这会导致一个尴尬局面：如果在项目里用了相对路径，换个目录启动，Derby 会认为要创建新库，而不是连接已有的库。建议统一使用绝对路径或网络服务器模式，避免出现“幽灵数据库”。
还有个容易被忽视的权限问题。Derby 在嵌入式模式下，数据库文件的所有权归启动它的 JVM 进程。如果先用 root 用户跑了一次，再用普通用户跑，可能会因为文件权限不足而无法读取。更麻烦的是，进程崩溃后可能留下锁文件 ，Derby 会拒绝连接。这时需要手动删除 ，或者通过 参数把日志输出到别的位置，以便排查原因。
说个实用技巧：Derby 支持内存数据库模式。只要在连接 URL 里加上 ，并指定内存路径，例如 ，数据库就完全运行在内存里，程序一停数据就会丢失。这对单元测试或临时数据处理特别友好，不用每次跑完后去清理磁盘上的脏数据。如果只是想在本地测试功能，内存模式比创建物理库快得多。
安装 Derby 本质上就是在“极简”和“灵活”之间找平衡。它不像 MySQL 那样提供完整的安装向导，也不像 SQLite 那样只需一个文件。Derby 给你的是几个 jar 包和命令行工具，剩下的全凭自己组合。但正因为这种设计，Derby 特别适合嵌入到 Java 应用里当内置数据库，或作为开发测试的轻量级方案。只要 Java 环境没问题，解压即用。
所以别把它想得太复杂，也别因为太简单而轻视。Derby 的安装就是一个“解压+配路径”的动作，但背后的运行模式、文件管理、连接方式才是真正需要花心思的地方。弄清楚这些，你就能把它玩出花来。
