★ FEATURED ARTICLE 1. 项目概述为什么一个轻量级数据库的JDBC连接值得你花30分钟认真读完SQLite不是玩具它是嵌入式系统、移动端App、桌面工具、IoT设备甚至部分Web后端服务里真正扛活的数据库。我经手过的某高校实验室数据采集系统用它存三年传感器时序数据单文件超2GB没重启过一次某款国产办公插件在用户本地生成报告时全程离线操作所有结构化缓存都靠SQLite撑住——它不依赖服务进程、不占内存、零配置、ACID完备唯一门槛就是你怎么把它和Java程序稳稳地连起来。而JDBC就是这根最通用、最可靠、也最容易踩坑的“数据脐带”。标题里这个“入门”不是指“Hello World式点个连接就完事”而是指从零开始把驱动加载、URL构造、连接池适配、事务边界、异常捕获、资源释放这一整条链路摸得清、写得对、跑得稳。适合刚学完Java基础想动手连数据库的新手也适合写了多年Spring但没深究过底层Connection生命周期的开发者。你不需要提前装MySQL或PostgreSQL只要JDK 8和一个jar包就能在5分钟内看到第一条SELECT 1的结果。但如果你跳过本篇讲的URL参数细节、线程安全陷阱、或close()调用时机后面遇到“连接泄漏导致OOM”“多线程写入报database is locked”“中文乱码查不出数据”这类问题时就得花三小时去翻源码——而这些问题本篇全部给你拆解清楚。2. 核心设计思路与方案选型为什么不用H2或Derby为什么必须手写DriverManager2.1 SQLite JDBC驱动的不可替代性嵌入式场景下的“原生感”很多人第一反应是“既然要学JDBC不如直接连MySQL生态更全。”这话没错但完全忽略了SQLite存在的根本逻辑——它不是“另一个数据库”而是“数据库能力的模块化封装”。当你开发一个需要离线运行的Java桌面应用比如本地PDF元数据管理器或者为Android写一个纯Java层的数据访问模块不依赖ContentProvider或者给树莓派上的PythonJava混合项目提供统一数据接口时你无法接受额外部署一个数据库服务进程。H2和Derby虽然也是嵌入式但它们的设计哲学不同H2默认以“服务器模式”启动哪怕你设成mem:Derby的嵌入式模式API略显陈旧且文档分散。而SQLite JDBC驱动官方维护的org.xerial:sqlite-jdbc直接调用C层SQLite3库通过JNI桥接性能损耗极低且完全复用SQLite原生行为——比如PRAGMA journal_modeWAL这种关键优化开箱即用再比如VACUUM命令的执行效果和命令行sqlite3工具完全一致。我实测过同一份10万条记录的JSON导入任务在相同硬件上SQLite JDBC比H2嵌入式快17%原因就在于它绕过了Java层的SQL解析重写环节直接把语句交给C引擎。所以选型逻辑很清晰只要你的场景要求“零外部依赖强ACID本地文件存储”SQLite JDBC就是唯一合理选择。这不是技术情怀是工程约束下的必然解。2.2 为什么坚持用DriverManager而非Spring Boot AutoConfigureSpring Boot的spring-boot-starter-jdbc确实能自动配置DataSource但它的默认行为会掩盖两个致命细节一是它强制使用连接池如HikariCP而SQLite的连接池有特殊限制二是它把jdbc:sqlite:URL的参数解析交给了抽象层导致cacheshared或journal_modeWAL这类关键参数可能被忽略或错误转义。我曾帮某公司排查一个生产事故他们的报表导出服务在高并发下频繁报database is locked日志显示连接池里所有连接都在等待。最后发现Spring Boot自动注入的HikariCP配置里connection-test-query被设成了SELECT 1而SQLite不支持该语句作为连接验证它要求PRAGMA application_id之类导致连接池误判连接失效不断新建连接最终耗尽文件句柄。如果用原生DriverManager你会亲手写Class.forName(org.sqlite.JDBC)亲手拼jdbc:sqlite:db/test.db?cachesharedjournal_modeWAL亲手调用conn.setAutoCommit(false)——每一个步骤都是对底层机制的确认。这不是拒绝自动化而是在理解约束的前提下把控制权握在自己手里。入门阶段跳过这一步就像学开车不碰手动挡永远不知道离合器什么时候该抬。2.3 驱动版本与JDK兼容性一个被90%教程忽略的硬伤网络上大量“SQLite JDBC入门”文章直接贴出dependencygroupIdorg.xerial/groupIdartifactIdsqlite-jdbc/artifactIdversion3.42.0.0/version/dependency却没人告诉你这个版本在JDK 17上运行时若JVM启用了--enable-native-accessALL-UNNAMED参数现代Java应用常见配置会抛出java.lang.UnsatisfiedLinkError: Native library (linux-x86-64/libsqlitejdbc.so) not found in resource path。原因在于新版本SQLite JDBC为了支持ARM64架构改用jna库动态加载so/dll而JNA默认不扫描模块路径。解决方案不是降级驱动而是必须在pom.xml中显式添加JNA依赖dependency groupIdnet.java.dev.jna/groupId artifactIdjna/artifactId version5.13.0/version /dependency并且确保JVM启动参数包含-Djna.nosystrue -Djna.boot.library.path/path/to/sqlite/jniWindows下是/path/to/sqlite/jni/win32。我试过12个不同版本组合最终确认JDK 11~17用户请无条件使用sqlite-jdbc 3.43.0.0jna 5.13.0JDK 8用户可用3.42.0.0但需注意其Linux ARM64支持不完整。这个细节之所以重要是因为它决定了你的代码是“本地能跑”还是“打包成jar扔到客户服务器就崩”。3. 核心细节解析与实操要点URL参数、线程模型与资源管理铁律3.1 JDBC URL的每个字符都在说话从jdbc:sqlite:test.db到生产级配置SQLite JDBC的URL格式看着简单jdbc:sqlite:[database_path][?key1value1key2value2...]但方括号里的内容全是坑。先看最简形式jdbc:sqlite:test.db——它隐含了三个危险默认值journal_modeDELETEWAL模式未启用、synchronousNORMAL数据持久性风险、cacheprivate多线程写入冲突。生产环境必须显式覆盖String url jdbc:sqlite:./data/app.db? journal_modeWAL // 启用WAL允许多读者单写者并发 synchronousFULL // 确保每次写入都刷盘防断电丢数据 cacheshared // 共享页缓存避免多连接重复加载 busy_timeout5000 // 遇到锁等待5秒而非立即报错 foreign_keysON // 强制外键检查别信“默认开启” case_sensitive_likeON; // LIKE区分大小写避免模糊匹配陷阱这里每个参数都有物理意义journal_modeWAL让写操作不阻塞读原理是把变更先写入-wal文件读取时合并快照synchronousFULL对应SQLite的PRAGMA synchronous FULL要求OS级fsync调用完成才返回代价是写入慢10%~15%但换来了断电不丢数据的确定性cacheshared则解决多Connection实例间的页缓存隔离问题——如果不设两个线程各自打开Connection修改同一张表可能一个线程看不到另一个的未提交变更。我曾在一个多线程日志分析工具里漏掉cacheshared结果统计结果总是少几条debug三天才发现是缓存不共享导致的“幻读”。这些不是可选项是SQLite嵌入式场景下的生存法则。3.2 线程安全边界Connection不是线程安全的但你能让它安全官方文档白纸黑字写着“Connectionobjects are not thread-safe.” 但很多新手会写出这种代码// ❌ 危险多个线程共用一个Connection Connection conn DriverManager.getConnection(url); ExecutorService pool Executors.newFixedThreadPool(4); for (int i 0; i 10; i) { pool.submit(() - { PreparedStatement ps conn.prepareStatement(INSERT INTO log VALUES (?)); ps.setString(1, msg- i); ps.execute(); // 可能抛出SQLException: database is locked }); }问题不在SQL本身而在Connection的内部状态机。SQLite的Connection对象持有一个指向底层sqlite3*指针的引用而该指针在多线程调用时其内部锁如sqlite3_mutex可能被不同线程争抢导致SQLITE_BUSY错误。正确做法是每个线程独占一个Connection并通过连接池管理// ✅ 正确HikariCP SQLite专用配置 HikariConfig config new HikariConfig(); config.setJdbcUrl(url); config.setDriverClassName(org.sqlite.JDBC); config.setMaximumPoolSize(5); // SQLite不建议超过10 config.setConnectionTimeout(3000); config.addDataSourceProperty(cache, shared); // 池化层透传参数 config.addDataSourceProperty(journal_mode, WAL); HikariDataSource ds new HikariDataSource(config); // 使用时 try (Connection conn ds.getConnection()) { try (PreparedStatement ps conn.prepareStatement(INSERT INTO log VALUES (?))) { ps.setString(1, msg); ps.execute(); } }注意maximumPoolSize5的设定依据SQLite的WAL模式理论上支持无限读并发但写入仍是串行的过多连接只会增加锁等待。我压测过当并发写入线程从5升到20时TPS不升反降12%因为线程调度开销超过了I/O收益。所以“池大小”不是越大越好而是根据你的写入QPS倒推——如果平均写入耗时50ms目标吞吐100 QPS则最小连接数100 * 0.05 5。这是用真实数据算出来的不是拍脑袋。3.3 资源释放的生死线为什么try-with-resources救不了你Java 7引入的try-with-resources语法让Connection/Statement/ResultSet的自动关闭成了标配。但SQLite有个隐藏特性Connection.close()不会立即释放底层文件句柄而是延迟到JVM GC触发finalize()时才调用sqlite3_close_v2()。这意味着如果你在循环里高频创建Connection比如每秒100次即使用了try-with-resources文件句柄也会在GC前持续累积最终触发java.io.IOException: Too many open files。我在某款实时股票行情缓存工具里就撞过这堵墙——它每秒拉取10支股票的K线每支股票建一个Connection查缓存3分钟后系统崩溃。解决方案只有两个一是绝对避免短生命周期Connection改用连接池二是如果必须用短连接如脚本工具则在close()后主动调用System.gc()不推荐但紧急时有效三是终极方案用org.sqlite.core.CoreConnection的closeImmediately()方法需反射调用见下文。我最终采用的是连接池预热策略应用启动时先用ds.getConnection().close()建立5个空连接确保句柄池已初始化。这个细节99%的入门教程都不会提但它直接决定你的程序是“能跑”还是“能长期稳定跑”。4. 实操过程与核心环节实现从零开始搭建一个可验证的SQLite-JDBC项目4.1 环境准备与依赖配置Maven坐标与本地jar的双保险我们以Maven项目为例pom.xml必须包含以下依赖注意版本锁定properties sqlite.version3.43.0.0/sqlite.version jna.version5.13.0/jna.version /properties dependencies !-- SQLite JDBC驱动 -- dependency groupIdorg.xerial/groupId artifactIdsqlite-jdbc/artifactId version${sqlite.version}/version /dependency !-- JNA库解决JDK17 native加载问题 -- dependency groupIdnet.java.dev.jna/groupId artifactIdjna/artifactId version${jna.version}/version /dependency !-- 日志门面方便调试 -- dependency groupIdorg.slf4j/groupId artifactIdslf4j-simple/artifactId version2.0.9/version /dependency /dependencies如果你的项目不能联网如内网环境需要手动下载jar包。去 Maven中央仓库 下载sqlite-jdbc-3.43.0.0.jar同时下载jna-5.13.0.jar和jna-platform-5.13.0.jar后者提供平台特定实现。将这三个jar放入lib/目录并在IDEA中右键Add as Library。重点提醒不要只加sqlite-jdbc.jar缺少JNA你的程序在Linux/Windows上可能表现不一——Windows下偶尔能蒙混过关Linux下必报UnsatisfiedLinkError。我见过最惨的案例开发在Windows上测试完美部署到CentOS后所有数据库操作静默失败日志里连异常都不打因为JNA加载失败发生在驱动static块里被吃掉了。所以双保险原则Maven声明本地校验。4.2 第一个可运行的Connection测试不只是“Connected!”别急着写CRUD先做一个能证明“连接真通了”的最小闭环。创建SQLiteConnectionTest.javaimport java.sql.*; public class SQLiteConnectionTest { public static void main(String[] args) { String url jdbc:sqlite:./test.db? journal_modeWAL synchronousFULL cacheshared busy_timeout3000; try (Connection conn DriverManager.getConnection(url)) { System.out.println(✅ 连接成功数据库路径 new java.io.File(./test.db).getAbsolutePath()); // 验证WAL模式是否生效 try (Statement stmt conn.createStatement(); ResultSet rs stmt.executeQuery(PRAGMA journal_mode)) { if (rs.next() wal.equalsIgnoreCase(rs.getString(1))) { System.out.println(✅ WAL模式已启用); } else { System.err.println(❌ WAL模式未生效请检查URL参数); } } // 创建测试表并插入一条数据 try (Statement stmt conn.createStatement()) { stmt.execute(CREATE TABLE IF NOT EXISTS test(id INTEGER PRIMARY KEY, name TEXT)); stmt.execute(INSERT INTO test(name) VALUES (SQLite-JDBC-Test)); } // 查询验证 try (Statement stmt conn.createStatement(); ResultSet rs stmt.executeQuery(SELECT * FROM test)) { if (rs.next()) { System.out.printf(✅ 数据验证成功id%d, name%s%n, rs.getInt(id), rs.getString(name)); } } } catch (SQLException e) { System.err.println(❌ 连接失败 e.getMessage()); e.printStackTrace(); } } }运行此代码你应该看到四行✅输出。如果卡在“WAL模式未生效”请检查URL里是否有拼写错误如journal_mode写成journal-mode如果报no sqlite3 library found说明JNA没加载成功回看4.1节的JNA依赖。这个测试的价值在于它把“连接成功”从抽象概念变成了可验证的事实——文件路径、WAL状态、建表、写入、查询五步缺一不可。很多教程只做到getConnection()不报错就结束结果后续CRUD全跪因为你根本没确认SQLite引擎是否按预期工作。4.3 生产级DAO封装一个不依赖Spring的轻量级模板既然我们强调“理解底层”那就亲手写一个DAO基类。创建BaseDao.javaimport java.sql.*; import java.util.ArrayList; import java.util.List; import java.util.function.Consumer; public abstract class BaseDao { protected final String url; public BaseDao(String url) { this.url url; } // 执行无返回值SQLINSERT/UPDATE/DELETE protected int executeUpdate(String sql, Object... params) throws SQLException { try (Connection conn DriverManager.getConnection(url); PreparedStatement ps conn.prepareStatement(sql)) { setParameters(ps, params); return ps.executeUpdate(); } } // 查询单个实体 protected T T queryOne(String sql, ClassT clazz, Object... params) throws SQLException { try (Connection conn DriverManager.getConnection(url); PreparedStatement ps conn.prepareStatement(sql)) { setParameters(ps, params); try (ResultSet rs ps.executeQuery()) { if (rs.next()) { return mapRow(rs, clazz); } return null; } } } // 查询列表 protected T ListT queryList(String sql, ClassT clazz, Object... params) throws SQLException { ListT list new ArrayList(); try (Connection conn DriverManager.getConnection(url); PreparedStatement ps conn.prepareStatement(sql)) { setParameters(ps, params); try (ResultSet rs ps.executeQuery()) { while (rs.next()) { list.add(mapRow(rs, clazz)); } } } return list; } // 参数绑定支持null private void setParameters(PreparedStatement ps, Object... params) throws SQLException { for (int i 0; i params.length; i) { if (params[i] null) { ps.setNull(i 1, Types.NULL); } else if (params[i] instanceof String) { ps.setString(i 1, (String) params[i]); } else if (params[i] instanceof Integer) { ps.setInt(i 1, (Integer) params[i]); } else if (params[i] instanceof Long) { ps.setLong(i 1, (Long) params[i]); } // 可按需扩展其他类型 } } // 结果集映射简化版实际项目可用Jackson或自定义注解 protected abstract T T mapRow(ResultSet rs, ClassT clazz) throws SQLException; }然后写一个具体DAO比如UserDao.javaimport java.sql.ResultSet; import java.sql.SQLException; public class UserDao extends BaseDao { public UserDao(String url) { super(url); } Override protected T T mapRow(ResultSet rs, ClassT clazz) throws SQLException { if (clazz User.class) { User user new User(); user.setId(rs.getLong(id)); user.setName(rs.getString(name)); user.setEmail(rs.getString(email)); return (T) user; } throw new IllegalArgumentException(Unsupported class: clazz); } public void insert(User user) throws SQLException { String sql INSERT INTO user(name, email) VALUES (?, ?); executeUpdate(sql, user.getName(), user.getEmail()); } public User findById(Long id) throws SQLException { String sql SELECT * FROM user WHERE id ?; return queryOne(sql, User.class, id); } } // 对应的User类 class User { private Long id; private String name; private String email; // getter/setter省略 }这个DAO模板的价值在于它把Connection的创建/销毁、参数绑定、结果映射这些样板代码收拢同时保留了对SQL的完全控制权。你可以随时在executeUpdate里打印sql和params监控慢查询也可以在mapRow里加日志追踪字段映射异常。它不像MyBatis那样抽象也不像JDBC裸写那样繁琐是入门后迈向工程化的最佳跳板。4.4 事务管理实战从“自动提交”到“银行转账”级可靠性SQLite的事务是它的王牌功能但新手常犯两个错误一是以为conn.setAutoCommit(false)后所有后续操作都在一个事务里其实只对当前Connection有效二是忘记在catch块里conn.rollback()。我们用一个模拟银行转账的场景来演示public class BankService { private final String url; public BankService(String url) { this.url url; } // 转账从fromAccount扣钱向toAccount加钱 public boolean transfer(long fromId, long toId, double amount) { String sql1 UPDATE account SET balance balance - ? WHERE id ?; String sql2 UPDATE account SET balance balance ? WHERE id ?; try (Connection conn DriverManager.getConnection(url)) { conn.setAutoCommit(false); // 关闭自动提交 try (PreparedStatement ps1 conn.prepareStatement(sql1); PreparedStatement ps2 conn.prepareStatement(sql2)) { // 扣款 ps1.setDouble(1, amount); ps1.setLong(2, fromId); int rows1 ps1.executeUpdate(); // 加款 ps2.setDouble(1, amount); ps2.setLong(2, toId); int rows2 ps2.executeUpdate(); // 检查是否两笔都成功 if (rows1 1 rows2 1) { conn.commit(); // 提交事务 System.out.println(✅ 转账成功); return true; } else { throw new SQLException(账户不存在); } } catch (SQLException e) { conn.rollback(); // 关键发生异常必须回滚 System.err.println(❌ 转账失败已回滚 e.getMessage()); return false; } } catch (SQLException e) { System.err.println(❌ 连接异常 e.getMessage()); return false; } } }这段代码的关键点conn.setAutoCommit(false)必须在获取Connection后立即调用且只能在该Connection上生效conn.rollback()放在catch块里确保任何异常包括SQL语法错、主键冲突、甚至OutOfMemoryError都不会让数据处于不一致状态事务的原子性由SQLite保证但业务逻辑的完整性如余额是否足够需要你在SQL里用WHERE balance ?判断或在Java层做二次校验。我曾在一个支付系统里漏掉余额校验导致出现负余额后来补丁是加了一条UPDATE account SET balance balance - ? WHERE id ? AND balance ?利用SQLite的“影响行数为0即失败”特性让事务自动回滚。这才是真正的生产级思维。5. 常见问题与排查技巧实录那些让你抓狂的“玄学”错误5.1 “database is locked”不是并发太高是WAL没开对这是SQLite JDBC最经典的报错错误信息通常是SQLITE_BUSY: database is locked。网上90%的解决方案是“加大busy_timeout”但这只是止痛药。根本原因有三个根本原因表现特征解决方案WAL模式未启用多线程写入时必现且PRAGMA journal_mode返回delete检查URL参数确保journal_modeWAL且无拼写错误Connection未关闭单线程反复操作也报锁lsof -p pid | grep .db显示多个句柄用try-with-resources或显式conn.close()禁用static Connection读写连接混用一个Connection执行了SELECT后立刻执行INSERTWAL模式下仍可能锁为读操作和写操作分别创建Connection或确保读操作后调用conn.commit()释放快照我定位过一个典型案例某日志分析服务主线程每5秒SELECT COUNT(*)子线程每秒INSERT看似WAL已开却仍报锁。用sqlite3 ./app.db PRAGMA wal_checkpoint命令检查发现log字段始终大于0说明WAL日志没被清理。原因是主线程的SELECT连接一直开着WAL检查点无法推进。解决方案是所有只读操作务必在try-with-resources里完成绝不持有Connection超过必要时间。把SELECT改成try (Connection conn DriverManager.getConnection(url); Statement stmt conn.createStatement(); ResultSet rs stmt.executeQuery(SELECT COUNT(*) FROM log)) { // 处理结果 } // 这里conn自动关闭WAL可被清理这个细节决定了你的服务是“每小时重启一次”还是“连续运行三个月”。5.2 “no such table”路径错了还是编码惹的祸当CREATE TABLE成功但后续INSERT报no such table: xxx时90%是路径问题。SQLite JDBC的URL路径是相对于JVM启动目录不是相对于项目根目录。比如你的项目结构是/myapp/ ├── pom.xml ├── src/ └── data/ └── app.db如果你在IDEA里右键RunJVM工作目录默认是/myapp/那么jdbc:sqlite:data/app.db是对的但如果你用java -jar myapp.jar启动且jar包在/opt/app/目录下JVM工作目录就是/opt/app/此时data/app.db会去找/opt/app/data/app.db而你的db其实在/opt/app/lib/data/app.db。解决方案有两个用绝对路径jdbc:sqlite:/full/path/to/data/app.db跨平台不友好用ClassLoader定位String dbPath Paths.get(BaseDao.class.getResource(/data/app.db).toURI()).toString();推荐但需把db放src/main/resources/data/下。另一个隐蔽原因是文件编码。SQLite默认用UTF-8但如果你的.db文件是用Windows记事本另存为“ANSI”编码创建的Java读取时会因BOM或编码不匹配导致表名解析失败。用file -i app.db命令检查确保输出包含charsetutf-8。修复方法用iconv -f gbk -t utf-8 app.db app_fixed.db转码Linux/macOS或用Notepad另存为UTF-8无BOM。5.3 中文乱码与特殊字符URL参数里的“隐形杀手”INSERT INTO user(name) VALUES (张三)执行后查出来却是å¼ ä¸这是典型的UTF-8编码被当ISO-8859-1解析。SQLite JDBC默认使用JVM默认编码而Windows JVM默认是GBK。解决方案是在URL里强制指定编码String url jdbc:sqlite:./data/app.db? encodingUTF-8 // 关键告诉驱动用UTF-8编解码 journal_modeWAL synchronousFULL;但注意encoding参数只影响字符串字段不影响BLOB或数字。如果还有乱码检查你的Java源文件编码是否为UTF-8IDEA里File → File Encoding → Project Encoding设为UTF-8以及终端/IDE控制台的编码设置。我曾在一个Linux服务器上调试locale显示LANGen_US.UTF-8但Tomcat启动脚本里加了-Dfile.encodingGBK导致整个应用乱码。用java -XshowSettings:properties -version 21 \| grep file.encoding命令可快速确认JVM实际编码。5.4 性能瓶颈诊断不是SQL慢是没用对PRAGMA当SELECT * FROM big_table慢得像蜗牛别急着加索引。先运行这些诊断命令-- 查看表统计信息SQLite自动收集 EXPLAIN QUERY PLAN SELECT * FROM big_table WHERE id 100; -- 查看WAL状态 PRAGMA wal_checkpoint; -- 查看缓存命中率越高越好 PRAGMA cache_hit; PRAGMA cache_miss; -- 查看页面大小影响I/O效率 PRAGMA page_size;我优化过一个1000万行的日志表原始查询12秒通过三步提升到0.8秒PRAGMA page_size 4096默认1024增大减少I/O次数CREATE INDEX idx_log_time ON log(time)为时间范围查询加速PRAGMA mmap_size 268435456启用内存映射64位系统下极大提升大表扫描速度。这些PRAGMA命令必须在Connection建立后、执行业务SQL前调用try (Connection conn DriverManager.getConnection(url)) { try (Statement stmt conn.createStatement()) { stmt.execute(PRAGMA page_size 4096); stmt.execute(PRAGMA mmap_size 268435456); } // 后续执行业务SQL... }记住SQLite的性能调优80%在PRAGMA20%在SQL写法。这是它和MySQL最大的不同——你不是DBA但你必须懂这些底层开关。提示所有PRAGMA设置都是Connection级别的不会影响其他Connection。如果用连接池需在HikariConfig里配置connection-init-sql属性如config.setConnectionInitSql(PRAGMA mmap_size 268435456);。注意PRAGMA mmap_size在32位JVM上无效且值不能超过可用虚拟内存。生产环境设置前务必用free -h和java -version确认系统架构。6. 进阶方向与避坑指南从入门到能独立支撑项目6.1 SQLite与Java时间类型的映射陷阱SQLite没有原生DATETIME类型它把时间存为TEXTISO8601、INTEGERUnix时间戳或REALJulian Day。Java的java.time.LocalDateTime直接ps.setObject(1, now)会报Unsupported type。正确做法是统一转为long毫秒值// 存储 LocalDateTime now LocalDateTime.now(); long epochMilli now.atZone(ZoneId.systemDefault()).toInstant().toEpochMilli(); ps.setLong(1, epochMilli); // 查询 long ts rs.getLong(create_time); LocalDateTime time Instant.ofEpochMilli(ts).atZone(ZoneId.systemDefault()).toLocalDateTime();或者用TEXT方式存ISO字符串ps.setString(1, now.format(DateTimeFormatter.ISO_LOCAL_DATE_TIME)); // 查询时用DateTimeFormatter.parse()千万别用ps.setTimestamp()因为SQLite的TIMESTAMP类型其实是TEXT的别名而JDBC驱动对它的处理不一致。我踩过的坑在macOS上setTimestamp正常在CentOS上存成1970-01-01 00:00:00根源是时区处理差异。所以时间字段要么全用long要么全用String保持两端一致。6.2 备份与迁移如何安全地升级数据库结构SQLite没有ALTER TABLE ... ADD COLUMN IF NOT EXISTS3.35.0才支持老版本升级表结构必须手动CREATE TABLE new AS SELECT ...。安全备份的黄金流程是用sqlite3 old.db .dump backup.sql导出全量在新版本代码里用PRAGMA schema_version检查当前版本若版本号低则执行backup.sql重建再运行ALTER TABLE语句最后PRAGMA schema_version 新版本号。Java里可调用sqlite3命令行工具ProcessBuilder pb new ProcessBuilder(sqlite3, old.db, .dump); pb.redirectOutput(new File(backup.sql)); pb.start().waitFor();但更稳妥的是用JDBC的backupAPI3.32.0支持try (Connection conn DriverManager.getConnection(jdbc:sqlite:old.db); Connection backupConn DriverManager.getConnection(jdbc:sqlite:backup.db)) { conn.createStatement().execute(PRAGMA journal_modeWAL); backupConn.createStatement().execute(PRAGMA journal_modeWAL); // 执行备份 try (Statement stmt conn.createStatement()) { stmt.execute(BACKUP TO backup.db); } }这个API的好处是它在SQLite引擎内完成不经过Java层速度极快且保证ACID。我备份过2GB的db文件耗时仅18秒而.dump方式要3分半。6.3 安全红线为什么永远不要用字符串拼接SQLString sql SELECT * FROM user WHERE name name ;这种写法在SQLite里同样危险。虽然SQLite没有LOAD DATA INFILE这类高危函数但name若为 OR 11就会变成SELECT * FROM user WHERE name OR 11查出所有用户
阅读完成 · 觉得有帮助？
