1. 为什么我们需要一个“嵌入式”数据库在开发一个桌面应用、一个移动App或者一个需要独立运行的小型服务时你大概率会遇到数据存储的需求。这时候你可能会想到几个选项用文件系统比如JSON、XML或者直接连接一个独立的数据库服务器比如MySQL、PostgreSQL。前者简单但查询和管理能力弱后者功能强大却带来了部署和运维的复杂性——你得先安装数据库软件配置用户权限保证服务进程常驻还得操心网络连接和版本兼容。有没有一种方案能像操作文件一样简单又具备关系型数据库的强大查询和管理能力呢这就是嵌入式数据库的用武之地。而Apache Derby正是这个领域里一个历史悠久、功能完备的“瑞士军刀”。它不是一个需要独立安装和管理的服务而是一个纯粹的Java库JAR文件。你把它引入到你的Java项目中它就能在你的应用进程内部直接读写本地的数据库文件。应用启动数据库就“活”了应用关闭数据库就“睡”了。对用户和运维人员来说它完全透明就像不存在一样但你的应用却实实在在地享用了完整的SQL支持、事务ACID特性、以及JDBC标准接口。我第一次在项目中选用Derby是为了一个给内部团队使用的数据分析工具。这个工具需要离线处理大量日志文件并将中间结果和配置信息持久化。如果让每个使用者在自己的电脑上安装配置MySQL光是培训和支持成本就让人头疼。而Derby完美地解决了这个问题我只需要在发布的应用包里包含几个JAR文件用户双击就能运行所有数据都安静地躺在用户目录下的一个文件夹里安全又私密。这种“开箱即用零运维”的体验对于需要快速部署和分发的工具类软件来说是极具吸引力的。2. Apache Derby的核心架构与两种运行模式Derby的设计非常精巧它并非只有“嵌入式”这一副面孔。理解它的两种核心运行模式是灵活运用它的关键。这两种模式共享同一套代码库只是启动和连接的方式不同。2.1 嵌入式模式与应用共生共灭这是Derby最经典、也是最常用的模式。在这种模式下Derby数据库引擎完全运行在你的Java应用程序的同一个Java虚拟机JVM进程中。工作方式你的应用通过JDBC驱动org.apache.derby.jdbc.EmbeddedDriver来连接数据库。连接URL类似于jdbc:derby:/path/to/myDataBase;createtrue。注意这里没有主机名和端口只有一个指向本地目录的文件路径。createtrue参数表示如果数据库不存在则创建它。当第一个连接建立时Derby引擎被启动当最后一个连接关闭时引擎随之关闭。所有的数据库文件数据表、索引、日志等都存储在myDataBase目录下。这个目录你可以放在任何地方甚至打包进应用内部只读模式。优点零部署无需安装数据库软件无需管理数据库服务进程。高性能由于没有网络开销和进程间通信数据访问速度极快。单用户访问数据库文件被当前JVM进程独占保证了数据一致性简化了并发控制。缺点与注意事项独占性一个数据库目录在同一时间只能被一个JVM进程以嵌入式模式打开。如果你想从另一个独立的应用访问同一组数据文件会得到“数据库已被锁定”的错误。这是设计使然并非缺陷。应用耦合数据库的生命周期完全由应用控制。如果应用崩溃Derby有完善的恢复机制通过日志但突然的进程终止总归是有风险的。内存占用Derby引擎运行在你的应用进程内会占用额外的JVM内存。实操心得在嵌入式模式下务必确保你的应用有优雅的关闭流程。在应用退出前显式地关闭所有数据库连接并执行DriverManager.getConnection(jdbc:derby:;shutdowntrue)来安全关闭Derby引擎。虽然不这么做Derby也能在下次启动时通过日志恢复但显式关闭是更规范的做法可以避免看到控制台那些“未正常关闭”的警告信息。2.2 网络服务器模式变身微型数据库服务器如果你希望多个应用甚至是不同机器上的应用能够共享同一个Derby数据库嵌入式模式就无能为力了。这时你可以启动Derby的网络服务器。工作方式你需要运行一个独立的进程NetworkServerControl。这可以通过Derby提供的startNetworkServer脚本来完成或者在代码中启动。这个服务器进程会监听一个网络端口默认1527并管理一个或多个Derby数据库。你的客户端应用可以是Java也可以是任何支持JDBC或ODBC的客户端使用org.apache.derby.jdbc.ClientDriver驱动通过类似jdbc:derby://localhost:1527//path/to/myDataBase的URL来连接服务器。此时对于客户端来说Derby就像一个传统的数据库服务器如MySQL而服务器进程内部依然是用嵌入式模式在访问本地的数据库文件。优点多客户端共享突破了嵌入式模式的单进程限制允许多个应用并发访问。跨网络访问数据库可以部署在一台服务器上供网络内的其他机器使用。独立运维数据库服务器的生命周期可以与客户端应用解耦。缺点部署复杂度增加你需要管理一个额外的服务器进程包括它的启动、停止和监控。性能损耗相比嵌入式模式增加了网络序列化和通信的开销。模式选择的核心逻辑 选择哪种模式根本上是看你的数据访问模式。如果你的数据只服务于单个应用实例且该应用是自包含的如桌面工具、移动应用、单机服务嵌入式模式是首选它极致简单。如果你需要从多个进程或机器访问同一份数据或者你想集中管理数据库那么就需要启动网络服务器模式。一个常见的混合场景是开发阶段使用嵌入式模式方便调试生产环境部署时根据实际情况决定是否启用网络服务器。3. 从零开始在你的Java项目中集成并使用Derby理论说再多不如动手试一下。让我们以一个简单的Java项目为例看看如何将Derby用起来。假设我们要开发一个个人书签管理工具。3.1 环境准备与依赖引入首先你需要获取Derby的库文件。最方便的方式是通过Maven或Gradle这样的构建工具来管理依赖。Maven依赖dependency groupIdorg.apache.derby/groupId artifactIdderby/artifactId version10.15.2.0/version !-- 请使用最新稳定版本 -- scoperuntime/scope /dependency如果你计划使用嵌入式模式只需要derby这个JAR它包含了引擎和嵌入式驱动。如果还需要客户端连接网络服务器则需要额外添加derbyclientJAR。手动配置 你也可以从Apache Derby官网下载发行包db-derby-xxx-bin.zip解压后将其lib目录下的derby.jar以及可能需要的derbytools.jar,derbynet.jar等添加到项目的Classpath中。3.2 创建并连接你的第一个嵌入式数据库下面是一段非常基础的代码演示了如何创建数据库、建立表、插入和查询数据。import java.sql.*; public class DerbyDemo { // 数据库连接URL。‘bookmarkDB’是数据库目录名‘createtrue’表示不存在则创建 private static final String DB_URL jdbc:derby:bookmarkDB;createtrue; public static void main(String[] args) { Connection conn null; Statement stmt null; try { // 1. 注册驱动 (对于较新的JDBC版本这步有时可省略但显式注册是好习惯) Class.forName(org.apache.derby.jdbc.EmbeddedDriver); // 2. 建立连接。这会自动启动Derby引擎并创建数据库目录 System.out.println(正在连接/创建数据库...); conn DriverManager.getConnection(DB_URL); // 3. 创建Statement对象用于执行SQL stmt conn.createStatement(); // 4. 创建表 String createTableSQL CREATE TABLE bookmarks ( id INT PRIMARY KEY GENERATED ALWAYS AS IDENTITY (START WITH 1, INCREMENT BY 1), title VARCHAR(100), url VARCHAR(500) NOT NULL, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP); // 注意如果表已存在executeUpdate会抛出SQLException。在实际应用中需要处理。 try { stmt.executeUpdate(createTableSQL); System.out.println(表 ‘bookmarks‘ 创建成功。); } catch (SQLException e) { if (e.getSQLState().equals(X0Y32)) { // 状态码X0Y32表示表已存在这里可以忽略或记录日志 System.out.println(表 ‘bookmarks‘ 已存在跳过创建。); } else { throw e; // 重新抛出其他异常 } } // 5. 插入数据 String insertSQL INSERT INTO bookmarks (title, url) VALUES (?, ?); PreparedStatement pstmt conn.prepareStatement(insertSQL); pstmt.setString(1, Apache Derby官网); pstmt.setString(2, https://db.apache.org/derby/); pstmt.executeUpdate(); System.out.println(插入一条书签记录。); // 6. 查询数据 String selectSQL SELECT * FROM bookmarks; ResultSet rs stmt.executeQuery(selectSQL); while (rs.next()) { int id rs.getInt(id); String title rs.getString(title); String url rs.getString(url); Timestamp createdAt rs.getTimestamp(created_at); System.out.printf(ID: %d, 标题: %s, 链接: %s, 创建于: %s%n, id, title, url, createdAt); } rs.close(); } catch (ClassNotFoundException e) { e.printStackTrace(); } catch (SQLException e) { e.printStackTrace(); } finally { // 7. 清理资源 try { if (stmt ! null) stmt.close(); if (conn ! null) conn.close(); // 可选关闭Derby引擎。生产环境中通常由应用统一管理。 // DriverManager.getConnection(jdbc:derby:;shutdowntrue); } catch (SQLException e) { // 关闭连接时的异常通常可以忽略或者记录日志 } } } }运行这段代码后你会在你的项目根目录或者你指定的路径下看到一个名为bookmarkDB的文件夹里面就是Derby生成的数据库文件。这就是整个“数据库”你可以把它复制、备份到任何地方。3.3 数据库文件结构与备份策略理解Derby生成的文件有助于你进行维护和备份。在bookmarkDB目录下你会看到类似这样的结构bookmarkDB/ ├── log/ # 存放事务日志文件用于崩溃恢复和回滚 ├── seg0/ # 存放实际的数据文件 ├── service.properties # 数据库服务属性文件 └── tmp/ # 临时文件备份的正确姿势 由于Derby在运行时会对文件加锁你绝对不能在应用运行期间直接复制整个数据库文件夹这很可能导致备份损坏。正确的备份方式有两种离线备份安全关闭应用确保所有连接关闭Derby引擎已停止然后直接复制整个数据库目录。这是最安全、最简单的方法。在线备份使用Derby提供的BACKUP命令。你可以在一个活动的连接中执行CALL SYSCS_UTIL.SYSCS_BACKUP_DATABASE(‘/path/to/backup‘)。这个命令会创建一个一致性的时间点备份是生产环境推荐的备份方式。踩坑实录我曾经在开发一个定时任务应用时写了一个脚本在半夜直接cp -r数据库文件夹。结果某次任务执行时间较长备份脚本运行时数据库仍在写入导致备份集无法被新的应用实例读取报了各种奇怪的I/O错误。从此牢记对于嵌入式Derby要么停服务备份要么用SYSCS_BACKUP_DATABASE。4. Derby的高级特性与实战中的“甜点”除了基本的CRUDDerby还提供了许多让开发者惊喜的特性这些特性让它不仅仅是一个“轻量级”数据库更是一个“功能完备”的数据库。4.1 内存数据库极速测试的利器有时候你只是想跑一些单元测试或者临时计算不希望产生磁盘I/O。Derby可以完全在内存中运行。 连接URL使用jdbc:derby:memory:myMemDB;createtrue以memory:开头的数据库所有数据都保存在JVM堆内存中。应用关闭后数据随之消失。这对于需要完全隔离、高速且无需清理的测试场景来说是完美的选择。你可以为每个测试用例创建一个独立的内存数据库测试结束后自动销毁互不干扰。4.2 强大的SQL兼容性与存储过程Derby对SQL-92标准有很高的支持度并实现了部分SQL:1999和SQL:2003的特性。这意味着你常用的JOIN、子查询、窗口函数部分支持、触发器、约束主键、外键、唯一性、检查约束它都支持。更值得一提的是它支持用Java编写存储过程和函数。你可以在数据库中创建Jar文件然后定义存储过程来调用其中的Java静态方法。这为在数据库层实现复杂业务逻辑提供了可能虽然对于嵌入式场景这种需求相对较少但它体现了Derby的“大数据库”基因。-- 示例创建一个调用Java方法的函数 CREATE FUNCTION TO_UPPERCASE (DATA VARCHAR(255)) RETURNS VARCHAR(255) PARAMETER STYLE JAVA NO SQL LANGUAGE JAVA EXTERNAL NAME ‘com.example.StringUtils.toUpperCase‘;4.3 事务与并发控制Derby提供了完整的事务支持ACID。默认情况下连接处于自动提交模式auto-committrue。你可以通过conn.setAutoCommit(false)来开启手动事务然后执行一系列操作最后用conn.commit()提交或conn.rollback()回滚。在嵌入式模式下由于是单进程访问并发控制相对简单。在网络服务器模式下Derby使用锁机制来处理多连接并发。它支持行级锁和表级锁能有效处理常见的读写冲突。对于大多数中小型应用其并发性能是足够的。4.4 管理与监控工具ij和dblookDerby自带两个非常实用的命令行工具它们包含在derbytools.jar中。ij一个交互式的SQL脚本工具类似于其他数据库的mysql或psql客户端。你可以用它来连接嵌入式或网络数据库执行SQL查询、更新甚至运行脚本文件。在开发调试阶段它是查看数据、验证表结构的必备利器。java -cp “derby.jar;derbytools.jar” org.apache.derby.tools.ij ij connect ‘jdbc:derby:/path/to/myDataBase‘; ij select * from bookmarks;dblook数据库结构导出工具。它可以读取一个Derby数据库并生成创建该数据库所有对象表、视图、索引、约束等的DDL脚本。这在版本控制和数据库结构迁移时非常有用。java -cp “derby.jar;derbytools.jar” org.apache.derby.tools.dblook -d ‘jdbc:derby:/path/to/myDataBase‘5. 性能调优与生产环境注意事项当你的应用数据量增长或者并发请求增多时一些默认配置可能就需要调整了。Derby通过一系列配置参数来控制系统行为。5.1 关键配置参数你可以在连接URL中指定或者在Derby的系统属性中设置。derby.storage.pageSize数据页大小默认为4KB。如果你的表中有大量的大字段如TEXT增大此值如8KB, 16KB可以提高I/O效率。但修改此参数需要在创建数据库之前设置对已存在的数据库无效。derby.system.durability持久化级别。默认是full即每次事务提交都强制写日志到磁盘保证数据不丢失。在可以接受一定数据丢失风险的测试或缓存场景可以设置为test这能显著提升写入性能。derby.locks.waitTimeout锁等待超时时间秒。默认是60秒。在高并发场景下如果发生锁等待可以适当调低此值让超时的操作快速失败而不是长时间挂起。derby.language.logQueryPlan设置为true可以在derby.log中输出查询执行计划对于慢查询优化至关重要。设置方式示例在连接URL中jdbc:derby:myDB;createtrue;derby.storage.pageSize81925.2 索引策略让查询飞起来和所有关系型数据库一样合理的索引是性能的基石。Derby支持B-tree索引。你需要分析你的常用查询条件WHERE子句和连接条件JOIN ... ON。-- 为bookmarks表的url字段创建索引 CREATE INDEX idx_url ON bookmarks(url); -- 为经常同时查询的字段创建复合索引 CREATE INDEX idx_title_created ON bookmarks(title, created_at);使用ij工具结合SYSCS_UTIL.SYSCS_SET_STATISTICS_TIMING和SYSCS_UTIL.SYSCS_SET_STATISTICS_SCAN启用统计信息然后执行你的查询可以在日志中看到详细的执行计划和扫描行数这是判断索引是否生效的最直接方法。5.3 常见问题排查链路问题应用启动时报 “数据库已被锁定” (XJ040)。排查思路确认是否有其他进程正在使用这是最常见的原因。检查是否打开了另一个使用该数据库的应用实例或者IDE中某个旧的进程没有完全退出。在Linux/Mac上可以用lsof | grep /path/to/yourDB查看是否有进程持有该目录下的文件。检查上次是否正常关闭如果上次应用或服务器是强制终止的如kill -9数据库可能处于“需要恢复”的状态。Derby会在下次启动时自动尝试恢复。如果恢复失败会留下一个db.lck文件。切勿手动删除此文件正确的做法是等待Derby自动恢复或者如果确认无其他进程可以尝试用jdbc:derby:/path/to/yourDB;startupForcedtrue参数强制启动但这有风险。检查文件权限确保运行应用的Java进程对数据库目录有读写权限。问题查询速度随着数据量增加而明显变慢。排查思路检查是否有索引使用dblook导出DDL或查询SYS.SYSINDEXES系统表确认关键查询字段上是否有索引。分析执行计划启用查询计划日志查看是否进行了全表扫描Table Scan。检查连接和语句是否关闭确保在finally块中关闭了ResultSet, Statement, Connection。未关闭的语句可能会导致资源如锁、游标未释放影响后续操作。考虑数据归档对于嵌入式数据库单表数据量通常不建议超过百万级。如果历史数据仍需查询但频率低可以考虑将其导出到文件归档从主表中清除。6. 横向对比Derby vs. H2 vs. SQLite在选择嵌入式数据库时Derby常被拿来与H2 Database和SQLite比较。它们各有侧重特性Apache DerbyH2 DatabaseSQLite核心语言JavaJavaC集成方式Java应用内纯JVMJava应用内纯JVM本地库需对应平台.so/.dll运行模式嵌入式、网络服务器嵌入式、内存、网络服务器嵌入式文件SQL兼容性SQL-92 部分高级特性高度兼容模式兼容多种数据库SQL-92 有自己的扩展性能特点稳健功能全面Java生态集成深极快特别是内存模式功能丰富极简高效C语言实现资源占用极低典型场景需要标准JDBC和完整事务的Java桌面/服务Java单元测试、快速原型、需要兼容其他DB语法的场景移动应用Android/iOS、桌面应用、小型设备管理工具ij,dblook内置Web控制台非常方便sqlite3命令行工具如何选择如果你的项目是纯Java/Java EE且需要最标准、最稳定的JDBC体验对性能要求不是极端苛刻Derby是安全、可靠的选择。它的“企业级”血统保证了功能的完备性和稳定性。如果你追求极致的执行速度特别是测试场景或者需要模拟Oracle/MySQL等数据库的语法进行测试H2是更好的选择。它的内存模式速度无与伦比Web控制台对于开发调试极其友好。如果你的应用是跨平台的C/C/Python等或者运行在资源受限的移动/嵌入式设备上SQLite是事实上的标准。它几乎无处不在但需要通过JDBC驱动如xerial/sqlite-jdbc才能在Java中使用。从我个人的经验来看在Java生态中对于需要持久化且结构复杂的数据我倾向于使用Derby对于需要快速搭建、测试或缓存H2是我的首选。它们不是替代关系而是工具箱里不同的工具。Apache Derby就像一位沉稳的“老将”它可能不是最快、最炫酷的那个但它提供的是一份经过时间检验的可靠与完整。当你需要一个能安静地融入你的Java应用不惹麻烦却又能在你需要时提供全套数据库服务的伙伴时Derby绝对值得你深入了解一下。它的简洁与强大往往能在那些看似不起眼的小型项目中发挥出决定性的作用。