刚把某模拟经营Demo的存档系统重构成SQLite我来说说这次踩过的坑和值得留的东西。游戏开发日记写到第11篇终于轮到数据库这块硬骨头了。之前存档一直用JSON文件硬怼玩家数量、道具列表、任务进度全塞进一个嵌套结构读取靠JsonConvert.DeserializeObject把整个文件拉进内存写回时又把整个对象树序列化覆盖写入。前期原型阶段还能忍等系统铺开之后问题就冒出来了图鉴数据一多每次存档即便只改一个金币数也得把几万行文本重新写一遍再加上中途崩溃导致文件写一半变损坏的情况实在让人头疼。换成SQLite之后存读档逻辑清爽了不止一个档次。但说实话接入过程并没有想象中那么“开箱即用”尤其是C#这边要把原生库调度清楚、处理好线程和事务边界有不少细节非得自己写一遍才明白。这篇文章不打算讲官网文档里的重复内容主要想说说游戏项目里引入SQLite的取舍、设计思路以及我在某跨平台系统里实际落地时的经验教训。1. 为什么游戏存档需要SQLite而不是继续用JSON1.1 存档系统的本质数据读写的分布模式先说结论JSON文件能扛住的关键前提是数据量小、读写频率低。但当系统加入了随机事件、每日奖励、多存档位、以及按章节记录的任务进度之后数据特征就完全变了——频繁的小字段更新、跨表查询、多条件筛选这些恰好是文件读写最吃力的操作。举个例子玩家背包里有500条道具记录每条包含道具ID、数量、强化等级、到期时间。存档时如果整体序列化哪怕只是某个道具过期时间变了也要把500条全量写一遍。这还不算玩家图鉴、成就、邮件这些扩展表。等到某个RoguelikeDemo的数据量接近10MB文本的时候每次存档的耗时已经能感受到明显卡顿而且存档失败导致玩家数据回滚的问题也开始频繁出现。换成数据库语义就不一样了。SQLite的最小写入粒度是行UPDATE player_bag SET expire_time ? WHERE item_uid ?这样的操作只影响一条记录。再加上WAL模式加持每次事务提交的IO量跟改动范围成正比而不是跟整个存档大小成正比。这种“按需更新”的能力是文件型存档方案天然没有的。1.2 选型对比SQLite不是唯一答案但适合独立游戏很多做web出身的人会直接想到MySQL但游戏存档这种单机场景里SQLite能胜出靠的是三个特性零配置、单文件、事务可靠。零配置意味着不需要安装服务端不需要账号权限单文件意味着存档可以直接走云备份、断点续传甚至玩家手动拷贝事务可靠意味着同一时刻写一半崩了文件不会变成半截垃圾数据。举个反例判断标准如果你的游戏有强联网大厅、跨服排行榜、全球同服的玩家数据这些场景需要真正的数据库服务端SQLite只适合做本地缓存。但对绝大多数单机或轻联网游戏来说把存档放在本地SQLite里再用云服务同步整包文件架构上比直接在服务端建表简单得多。我在某跨平台系统里的做法就是本地库为主、云文件备份为辅两边用存档版本号对账效果很稳。1.3 比“要不要用”更难的问题表结构怎么设计存档从JSON迁移到SQLite编程习惯上最大的变化是从前你只需要考虑一个对象图现在你得考虑多个表之间的关联和边界。我的建议是先画一个实体关系草图不要急着建表。对游戏存档来说典型的分表维度包括这几类玩家基础信息金币、等级、剧情进度、背包物品独立行每行一个实例、任务日志按任务实例记录状态、全局图鉴类似配置型数据、邮件或公告数量不定。这么做的好处是不同模块可以各自高频更新互不锁库后续加新系统只要新增表或字段即可不必重排整个存档对象。表结构设计时踩过一个大坑不要用“通用字段”塞所有类型的扩展信息。早期希望省事设计了一张kv_store表key-value硬存各种数据后来查询条件一多代码里写满了类型转换和条件过滤纯粹给自己添堵。正确做法是让每张表承载明确的业务语义扩展字段用JSON列折叠成一条配置记录而不是抛弃类型约束。2. SQLite核心机制与游戏开发相关的几个关键点2.1 事务不是“慢”的理由而是“稳”的前提从文件存档转过来的开发者看到BEGIN IMMEDIATE / COMMIT大概率会问每次存档都要开事务会不会反而更慢这里得把两个概念分开单条更新和批量存档。如果每次道具变动都立刻提交一个事务确实会产生大量同步写盘操作反而比JSON全量写文件更慢。但游戏存档的正确姿势是“攒批提交”——把一帧或一个玩法周期内的所有数据变更收集起来开一个事务批量写入提交一次。我自己就是这样做的写操作统一丢进一个队列每满20条或间隔500ms批量执行一次事务。实测下来5000条背包更新的总耗时比逐条提交快了接近20倍而且崩溃恢复时最多丢最近500ms的数据。对需要严格不丢数据的场景比如充值到账单独走即时提交对普通玩法数据批量提交完全能接受。SQLite还有一个容易被忽略的属性PRAGMA synchronous NORMAL这种层面的取舍。游戏项目里我更重视“加载快”“不阻塞主线程”因此核心玩家数据用synchronous FULL确保不会因断电丢失而普通系统数据日志、互动记录可以接受NORMAL甚至OFF。这种分级策略是在“可靠性”和“性能”之间找平衡而不是一刀切。2.2 WAL模式解决了“读时不能写写时不能读”的老大难如果直接把SQLite接入游戏默认的delete journal模式会在每次写操作时创建回滚日志写的时候读操作会被阻塞两个连接并发读写时还会报database is locked。这个问题在游戏场景特别容易触发主线程读取玩家信息渲染UI后台线程收到战斗结算写经验值两边同时碰库轻则卡顿重则异常。解决手段就是启用WALWrite-Ahead Logging预写日志。WAL模式下写操作追加到独立的-wal文件读操作照常读原始主库文件互不阻塞检查点机制再把WAL内容合并回主库。这个机制对游戏来说就是存档时玩家还能接着操作不打断手感。启用方式极其简单string sql PRAGMA journal_modeWAL;;注意这个PRAGMA是持久化设置在数据库文件层面的不是连接级别的临时配置。第一次设置后后续打开库仍然保持WAL模式除非显式切换回delete模式。实测下来WAL模式的写入吞吐比默认模式高出一截显著的提升在于频繁小事务的场景。2.3 降级写入与原子提交崩溃之后存档依然完整有人担心SQLite在移动端或游戏机上运行时文件太大、并发不够但实际上只要理解“原子提交”机制就明白崩溃恢复是它的一大优势。SQLite的日志机制保证一组写操作要么全成功要么全不生效。不会出现“玩家金币扣了但经验没涨”这种半截状态。具体到游戏存档我强烈建议把一个完整的存档周期包在一个事务里。比如存档按钮按下时一次性更新玩家基础数据、背包、任务进度等多个表COMMIT一下全部落盘。如果写完一半崩溃SQLite自动回滚到上一个完整事务的状态绝不留半截数据。这一点对“玩家点存档后直接把App杀了”的极端情况尤其重要。3. 在游戏项目里实操接入SQLite的完整步骤3.1 引入依赖与平台兼容处理以C#生态为例Unity游戏接入SQLite常见的是把sqlite3.dll放进Plugins目录并引入C#层封装库比如Mono.Data.Sqlite或System.Data.SQLite。这里有个特别容易踩的坑不同平台的dll不能混用。64位Windows需要的dll、macOS产物的文件后缀、Android下用的libsqlite3.so以及iOS只能用系统自带的sqlite3必须分别打包。我的操作路径是这样的Windows编辑器下直接调用sqlite3.dll路径放入Assets/Plugins/x86_64/Android构建目标使用官方推荐的libsqlite3.so或通过动态库加载方案避免直接引用Windows版dlliOS因为系统自带了sqlite3就不用再额外放dll通过C#层的DllImport声明就能直接调用。还有一点做真机测试时要确认库文件最终是否被打进包里。很多时候编辑器跑得很欢一到真机就报DllNotFoundException就是平台dll放错了目录或没被识别。3.2 连接生命周期管理不要每次存档都Open/Close新手最容易出现的写法是每次操作都新建连接用完之后释放。这在文件型玩法里没问题但在SQLite里就会导致一个反复出现的性能问题——每次连接都要做文件锁协商、日志初始化、schema读取。频繁开关连接几千次操作下来会浪费大量时间。推荐做法应用启动时创建一个全局连接游戏生命周期内一直保持打开状态只在退出或切换存档位时关闭。千万注意线程安全SQLite连接默认不是线程安全的我加了一把互斥锁保证同一时间只有一个线程真正执行命令。我在某跨平台系统里是这样封装的public sealed class DatabaseService : IDisposable { private readonly object _syncRoot new object(); private SqliteConnection _connection; public void Open(string dbPath) { lock (_syncRoot) { _connection new SqliteConnection($Data Source{dbPath}); _connection.Open(); using (var cmd _connection.CreateCommand()) { cmd.CommandText PRAGMA journal_modeWAL;; cmd.ExecuteNonQuery(); } } } public T ExecuteT(FuncSqliteConnection, T action) { lock (_syncRoot) { using (var cmd _connection.CreateCommand()) { // 具体命令参数设置省略 } return action(_connection); } } public void Dispose() { lock (_syncRoot) { _connection?.Close(); _connection?.Dispose(); } } }这种单连接加锁方案虽然牺牲了一点并发度但对于单机游戏存档场景完全够用而且避免了一大堆连接池的复杂度。3.3 数据库初始化与版本迁移存档数据库不是一次建好就永远不变的游戏迭代过程中加表、加字段、改索引都很正常。为了不给玩家留下“更新后存档损坏”的提示必须做版本迁移。我的方案是通过PRAGMA user_version记录数据库版本号。在启动时读取版本号如果低于期望版本就按版本号顺序执行迁移脚本。比如v1创建玩家表v2追加背包表v3给任务表加一个字段。每段迁移脚本包在事务里失败则回滚保持库内一致性。public void Migrate(SqliteConnection connection) { int version GetUserVersion(connection); if (version 1) { ExecuteScript(connection, GetV1Script()); SetUserVersion(connection, 1); } if (version 2) { ExecuteScript(connection, GetV2Script()); SetUserVersion(connection, 2); } }关键坑来了迁移脚本务必保持“只增不改”的原则不要回头改动已经发布过的历史脚本。因为已经安装过旧版的玩家执行顺序是从旧版本往新版本逐段跑改历史脚本会导致已升级玩家和新玩家的库结构出现差异极难排查。3.4 事务包裹与批量写入的体验优化把写入集中在事务里是提升体验最有效的手段。我做了一个简单的事务调度器外部模块只调用ScheduleWrite(ActionSqliteConnection)内部累积若干条操作后统一执行BEGIN到COMMIT。这样写的好处有三个第一避免频繁小事务浪费磁盘IO第二缩短每次数据变更的加锁时间降低和其他线程读操作的冲突第三为未来接入云存档打基础——只把事务提交后的变更摘要上传节省流量。private void FlushPendingWrites() { lock (_syncRoot) { using (var transaction _connection.BeginTransaction()) { foreach (var action in _pendingWrites) { action(_connection, transaction); } transaction.Commit(); } _pendingWrites.Clear(); } }这里有一个真实的体验提升数据没有批量写时某个模拟经营Demo的存档按钮点击后平均耗时80msUI有明显的卡顿感改成批量事务后耗时降到了10ms以内手感完全不是一个级别。4. 常见问题与排查技巧实录4.1 database is locked看起来是随机报错实则都是锁竞争SQLite的database is locked是我最初遇到最多的报错也是最容易误判的问题。它不是随机抽风而是“另一个连接正在写库而你这边也尝试写库”导致的锁等待超时。排查步骤一般是检查是否有多个SqliteConnection同时打开。全局不要处处new连接收敛到单一服务类。检查写操作是否在事务外频繁执行。事务提交之间会有锁窗口非事务的散写最容易撞上自家人。检查是否有人在持有读连接时执行了写操作。WAL模式下读不阻塞写但写会被其他未释放的读快照影响。解决起来除了单连接单写线程方案外还可以设置PRAGMA busy_timeout 3000;让SQLite在锁冲突时自动等待而不是立刻报错。游戏场景里主线程读、写队列后台写只要等待时间够长基本不会出现锁错误。4.2 主线程卡顿不是数据库慢是同步调用慢不少朋友告诉我“SQLite刷新好慢”但实际测下来慢的不是查询本身而是所有数据库操作都放在主线程执行数据量一大就会卡渲染。尤其UI需要加载几百条物品列表时同步查询会直接拖慢帧率。解决思路是数据库操作与主线程分离。把查询和写入都放到后台任务里先拿到数据后在下一帧主线程刷新UI。说的轻巧做起来其实有一个隐藏问题默认的SqliteConnection创建在哪个线程后续操作最好也跟那个线程绑定。否则切换线程后可能因为连接线程亲和性问题出现奇怪异常。我现在用的方案数据库服务在后台线程里常驻主线程通过异步方法交任务进去任务完成后回调到主线程更新界面。这样既保持了连接上下文又不阻塞游戏渲染。4.3 打包后找不到数据库文件路径问题开发时在编辑器里跑得好好的一打包就提示找不到数据库文件。这通常是路径写错了。Unity里比较稳的做法是持久化路径而不是用相对路径或Application.dataPath。Application.persistentDataPath在不同平台指向可写目录是存档文件的正确归宿。另外初始数据库带不带种子数据需要区分处理。对于配置型数据装备表、技能表我会把只读数据做成JSON或ScriptableObject资源运行时导入SQLite缓存表对于玩家存档首启时才创建空库。千万不要把带玩家数据的库文件放在只读目录下去“另存”这既浪费时间也会在真机上失败。4.4 存档写一半崩了为什么启动后数据还是旧的这个问题反而说明SQLite的可靠性在设计上确实有效因为事务没有提交崩溃后所有改动都回滚了。玩家看到的是上一次完整提交的状态并不是数据“丢”了。但如果你希望“不丢”任何进度就得把事务提交频率调高。比如每完成一场战斗、每升一级、每获得一件关键道具都提交一次换来的是更小粒度的进度保存。量产型玩法数据则可以放宽到批量提交甚至周期提交。这套分频保存策略是我从实际项目中总结出来的核心经验没有“绝对不丢”配置只有“根据数据价值决定保存频率”。5. 更进一步的优化方向当游戏系统逐渐膨胀之后还能从几个方向进一步扩展SQLite的用法。查询缓存高频访问的配置数据不需要每次请求数据库可以在启动时加载到内存字典运行中直接读内存只在数据变更时更新缓存。读取路径从“查库”变成了“查字典”性能还有数倍提升空间。数据库拆库如果游戏有大量只读配置和少量频繁修改的玩家数据可以考虑把配置库文件和数据库文件拆开。配置库以只读方式打开放在资源目录或可寻址资源中减少主库体积也降低每次云备份的上传量。加密能力如果不希望玩家直接改存档SQLite生态有加密扩展。但要注意加密会引入额外的复杂度和性能损耗需要在作弊防护和调试便利之间取舍。我目前项目中还没启用加密但对联机排名类数据后期会考虑在同步层做签名校验而不是给整个库加密。再往前扩展SQLite还能承担本地事件日志、埋点统计、资源热更版本记录等功能。它不单单是“存档数据库”更像是游戏本地的迷你数据中心。这个思维转变才是从JSON迁移到SQLite最大的收获。6. 写在最后的实在话数据库接入本身不是高深技术难的是一开始就确定边界哪些数据该进库、哪些不该进库、什么时候提交、什么时候批量写。我试过把所有状态都往库里塞最后小到一个开关按钮都要查一次数据库完全没有必要。内存、静态配置、玩家本地偏好这类数据留在内存里反而更快、更简单。我个人体会最深的还是SQLite给游戏带来的本质上是把存档从“整文件覆盖”升级成“按记录变更”的能力。这个转变会让存档体的设计思路发生连锁变化也让后期扩展系统时不必反复打回重来。下一篇日记大概会写战斗系统的数值框架怎么与存档表结构配合如果对这块感兴趣可以继续关注这个系列。 
长河君 · 2026/10/13 8:02:38 · 阅读 1.2k 游戏存档重构：从JSON到SQLite的实战经验与性能优化指南
刚把某模拟经营Demo的存档系统重构成SQLite我来说说这次踩过的坑和值得留的东西。游戏开发日记写到第11篇终于轮到数据库这块硬骨头了。之前存档一直用JSON文件硬怼玩家数量、道具列表、任务进度全塞进一个嵌套结构读取靠JsonConvert.DeserializeObject把整个文件拉进内存写回时又把整个对象树序列化覆盖写入。前期原型阶段还能忍等系统铺开之后问题就冒出来了图鉴数据一多每次存档即便只改一个金币数也得把几万行文本重新写一遍再加上中途崩溃导致文件写一半变损坏的情况实在让人头疼。换成SQLite之后存读档逻辑清爽了不止一个档次。但说实话接入过程并没有想象中那么“开箱即用”尤其是C#这边要把原生库调度清楚、处理好线程和事务边界有不少细节非得自己写一遍才明白。这篇文章不打算讲官网文档里的重复内容主要想说说游戏项目里引入SQLite的取舍、设计思路以及我在某跨平台系统里实际落地时的经验教训。1. 为什么游戏存档需要SQLite而不是继续用JSON1.1 存档系统的本质数据读写的分布模式先说结论JSON文件能扛住的关键前提是数据量小、读写频率低。但当系统加入了随机事件、每日奖励、多存档位、以及按章节记录的任务进度之后数据特征就完全变了——频繁的小字段更新、跨表查询、多条件筛选这些恰好是文件读写最吃力的操作。举个例子玩家背包里有500条道具记录每条包含道具ID、数量、强化等级、到期时间。存档时如果整体序列化哪怕只是某个道具过期时间变了也要把500条全量写一遍。这还不算玩家图鉴、成就、邮件这些扩展表。等到某个RoguelikeDemo的数据量接近10MB文本的时候每次存档的耗时已经能感受到明显卡顿而且存档失败导致玩家数据回滚的问题也开始频繁出现。换成数据库语义就不一样了。SQLite的最小写入粒度是行UPDATE player_bag SET expire_time ? WHERE item_uid ?这样的操作只影响一条记录。再加上WAL模式加持每次事务提交的IO量跟改动范围成正比而不是跟整个存档大小成正比。这种“按需更新”的能力是文件型存档方案天然没有的。1.2 选型对比SQLite不是唯一答案但适合独立游戏很多做web出身的人会直接想到MySQL但游戏存档这种单机场景里SQLite能胜出靠的是三个特性零配置、单文件、事务可靠。零配置意味着不需要安装服务端不需要账号权限单文件意味着存档可以直接走云备份、断点续传甚至玩家手动拷贝事务可靠意味着同一时刻写一半崩了文件不会变成半截垃圾数据。举个反例判断标准如果你的游戏有强联网大厅、跨服排行榜、全球同服的玩家数据这些场景需要真正的数据库服务端SQLite只适合做本地缓存。但对绝大多数单机或轻联网游戏来说把存档放在本地SQLite里再用云服务同步整包文件架构上比直接在服务端建表简单得多。我在某跨平台系统里的做法就是本地库为主、云文件备份为辅两边用存档版本号对账效果很稳。1.3 比“要不要用”更难的问题表结构怎么设计存档从JSON迁移到SQLite编程习惯上最大的变化是从前你只需要考虑一个对象图现在你得考虑多个表之间的关联和边界。我的建议是先画一个实体关系草图不要急着建表。对游戏存档来说典型的分表维度包括这几类玩家基础信息金币、等级、剧情进度、背包物品独立行每行一个实例、任务日志按任务实例记录状态、全局图鉴类似配置型数据、邮件或公告数量不定。这么做的好处是不同模块可以各自高频更新互不锁库后续加新系统只要新增表或字段即可不必重排整个存档对象。表结构设计时踩过一个大坑不要用“通用字段”塞所有类型的扩展信息。早期希望省事设计了一张kv_store表key-value硬存各种数据后来查询条件一多代码里写满了类型转换和条件过滤纯粹给自己添堵。正确做法是让每张表承载明确的业务语义扩展字段用JSON列折叠成一条配置记录而不是抛弃类型约束。2. SQLite核心机制与游戏开发相关的几个关键点2.1 事务不是“慢”的理由而是“稳”的前提从文件存档转过来的开发者看到BEGIN IMMEDIATE / COMMIT大概率会问每次存档都要开事务会不会反而更慢这里得把两个概念分开单条更新和批量存档。如果每次道具变动都立刻提交一个事务确实会产生大量同步写盘操作反而比JSON全量写文件更慢。但游戏存档的正确姿势是“攒批提交”——把一帧或一个玩法周期内的所有数据变更收集起来开一个事务批量写入提交一次。我自己就是这样做的写操作统一丢进一个队列每满20条或间隔500ms批量执行一次事务。实测下来5000条背包更新的总耗时比逐条提交快了接近20倍而且崩溃恢复时最多丢最近500ms的数据。对需要严格不丢数据的场景比如充值到账单独走即时提交对普通玩法数据批量提交完全能接受。SQLite还有一个容易被忽略的属性PRAGMA synchronous NORMAL这种层面的取舍。游戏项目里我更重视“加载快”“不阻塞主线程”因此核心玩家数据用synchronous FULL确保不会因断电丢失而普通系统数据日志、互动记录可以接受NORMAL甚至OFF。这种分级策略是在“可靠性”和“性能”之间找平衡而不是一刀切。2.2 WAL模式解决了“读时不能写写时不能读”的老大难如果直接把SQLite接入游戏默认的delete journal模式会在每次写操作时创建回滚日志写的时候读操作会被阻塞两个连接并发读写时还会报database is locked。这个问题在游戏场景特别容易触发主线程读取玩家信息渲染UI后台线程收到战斗结算写经验值两边同时碰库轻则卡顿重则异常。解决手段就是启用WALWrite-Ahead Logging预写日志。WAL模式下写操作追加到独立的-wal文件读操作照常读原始主库文件互不阻塞检查点机制再把WAL内容合并回主库。这个机制对游戏来说就是存档时玩家还能接着操作不打断手感。启用方式极其简单string sql PRAGMA journal_modeWAL;;注意这个PRAGMA是持久化设置在数据库文件层面的不是连接级别的临时配置。第一次设置后后续打开库仍然保持WAL模式除非显式切换回delete模式。实测下来WAL模式的写入吞吐比默认模式高出一截显著的提升在于频繁小事务的场景。2.3 降级写入与原子提交崩溃之后存档依然完整有人担心SQLite在移动端或游戏机上运行时文件太大、并发不够但实际上只要理解“原子提交”机制就明白崩溃恢复是它的一大优势。SQLite的日志机制保证一组写操作要么全成功要么全不生效。不会出现“玩家金币扣了但经验没涨”这种半截状态。具体到游戏存档我强烈建议把一个完整的存档周期包在一个事务里。比如存档按钮按下时一次性更新玩家基础数据、背包、任务进度等多个表COMMIT一下全部落盘。如果写完一半崩溃SQLite自动回滚到上一个完整事务的状态绝不留半截数据。这一点对“玩家点存档后直接把App杀了”的极端情况尤其重要。3. 在游戏项目里实操接入SQLite的完整步骤3.1 引入依赖与平台兼容处理以C#生态为例Unity游戏接入SQLite常见的是把sqlite3.dll放进Plugins目录并引入C#层封装库比如Mono.Data.Sqlite或System.Data.SQLite。这里有个特别容易踩的坑不同平台的dll不能混用。64位Windows需要的dll、macOS产物的文件后缀、Android下用的libsqlite3.so以及iOS只能用系统自带的sqlite3必须分别打包。我的操作路径是这样的Windows编辑器下直接调用sqlite3.dll路径放入Assets/Plugins/x86_64/Android构建目标使用官方推荐的libsqlite3.so或通过动态库加载方案避免直接引用Windows版dlliOS因为系统自带了sqlite3就不用再额外放dll通过C#层的DllImport声明就能直接调用。还有一点做真机测试时要确认库文件最终是否被打进包里。很多时候编辑器跑得很欢一到真机就报DllNotFoundException就是平台dll放错了目录或没被识别。3.2 连接生命周期管理不要每次存档都Open/Close新手最容易出现的写法是每次操作都新建连接用完之后释放。这在文件型玩法里没问题但在SQLite里就会导致一个反复出现的性能问题——每次连接都要做文件锁协商、日志初始化、schema读取。频繁开关连接几千次操作下来会浪费大量时间。推荐做法应用启动时创建一个全局连接游戏生命周期内一直保持打开状态只在退出或切换存档位时关闭。千万注意线程安全SQLite连接默认不是线程安全的我加了一把互斥锁保证同一时间只有一个线程真正执行命令。我在某跨平台系统里是这样封装的public sealed class DatabaseService : IDisposable { private readonly object _syncRoot new object(); private SqliteConnection _connection; public void Open(string dbPath) { lock (_syncRoot) { _connection new SqliteConnection($Data Source{dbPath}); _connection.Open(); using (var cmd _connection.CreateCommand()) { cmd.CommandText PRAGMA journal_modeWAL;; cmd.ExecuteNonQuery(); } } } public T ExecuteT(FuncSqliteConnection, T action) { lock (_syncRoot) { using (var cmd _connection.CreateCommand()) { // 具体命令参数设置省略 } return action(_connection); } } public void Dispose() { lock (_syncRoot) { _connection?.Close(); _connection?.Dispose(); } } }这种单连接加锁方案虽然牺牲了一点并发度但对于单机游戏存档场景完全够用而且避免了一大堆连接池的复杂度。3.3 数据库初始化与版本迁移存档数据库不是一次建好就永远不变的游戏迭代过程中加表、加字段、改索引都很正常。为了不给玩家留下“更新后存档损坏”的提示必须做版本迁移。我的方案是通过PRAGMA user_version记录数据库版本号。在启动时读取版本号如果低于期望版本就按版本号顺序执行迁移脚本。比如v1创建玩家表v2追加背包表v3给任务表加一个字段。每段迁移脚本包在事务里失败则回滚保持库内一致性。public void Migrate(SqliteConnection connection) { int version GetUserVersion(connection); if (version 1) { ExecuteScript(connection, GetV1Script()); SetUserVersion(connection, 1); } if (version 2) { ExecuteScript(connection, GetV2Script()); SetUserVersion(connection, 2); } }关键坑来了迁移脚本务必保持“只增不改”的原则不要回头改动已经发布过的历史脚本。因为已经安装过旧版的玩家执行顺序是从旧版本往新版本逐段跑改历史脚本会导致已升级玩家和新玩家的库结构出现差异极难排查。3.4 事务包裹与批量写入的体验优化把写入集中在事务里是提升体验最有效的手段。我做了一个简单的事务调度器外部模块只调用ScheduleWrite(ActionSqliteConnection)内部累积若干条操作后统一执行BEGIN到COMMIT。这样写的好处有三个第一避免频繁小事务浪费磁盘IO第二缩短每次数据变更的加锁时间降低和其他线程读操作的冲突第三为未来接入云存档打基础——只把事务提交后的变更摘要上传节省流量。private void FlushPendingWrites() { lock (_syncRoot) { using (var transaction _connection.BeginTransaction()) { foreach (var action in _pendingWrites) { action(_connection, transaction); } transaction.Commit(); } _pendingWrites.Clear(); } }这里有一个真实的体验提升数据没有批量写时某个模拟经营Demo的存档按钮点击后平均耗时80msUI有明显的卡顿感改成批量事务后耗时降到了10ms以内手感完全不是一个级别。4. 常见问题与排查技巧实录4.1 database is locked看起来是随机报错实则都是锁竞争SQLite的database is locked是我最初遇到最多的报错也是最容易误判的问题。它不是随机抽风而是“另一个连接正在写库而你这边也尝试写库”导致的锁等待超时。排查步骤一般是检查是否有多个SqliteConnection同时打开。全局不要处处new连接收敛到单一服务类。检查写操作是否在事务外频繁执行。事务提交之间会有锁窗口非事务的散写最容易撞上自家人。检查是否有人在持有读连接时执行了写操作。WAL模式下读不阻塞写但写会被其他未释放的读快照影响。解决起来除了单连接单写线程方案外还可以设置PRAGMA busy_timeout 3000;让SQLite在锁冲突时自动等待而不是立刻报错。游戏场景里主线程读、写队列后台写只要等待时间够长基本不会出现锁错误。4.2 主线程卡顿不是数据库慢是同步调用慢不少朋友告诉我“SQLite刷新好慢”但实际测下来慢的不是查询本身而是所有数据库操作都放在主线程执行数据量一大就会卡渲染。尤其UI需要加载几百条物品列表时同步查询会直接拖慢帧率。解决思路是数据库操作与主线程分离。把查询和写入都放到后台任务里先拿到数据后在下一帧主线程刷新UI。说的轻巧做起来其实有一个隐藏问题默认的SqliteConnection创建在哪个线程后续操作最好也跟那个线程绑定。否则切换线程后可能因为连接线程亲和性问题出现奇怪异常。我现在用的方案数据库服务在后台线程里常驻主线程通过异步方法交任务进去任务完成后回调到主线程更新界面。这样既保持了连接上下文又不阻塞游戏渲染。4.3 打包后找不到数据库文件路径问题开发时在编辑器里跑得好好的一打包就提示找不到数据库文件。这通常是路径写错了。Unity里比较稳的做法是持久化路径而不是用相对路径或Application.dataPath。Application.persistentDataPath在不同平台指向可写目录是存档文件的正确归宿。另外初始数据库带不带种子数据需要区分处理。对于配置型数据装备表、技能表我会把只读数据做成JSON或ScriptableObject资源运行时导入SQLite缓存表对于玩家存档首启时才创建空库。千万不要把带玩家数据的库文件放在只读目录下去“另存”这既浪费时间也会在真机上失败。4.4 存档写一半崩了为什么启动后数据还是旧的这个问题反而说明SQLite的可靠性在设计上确实有效因为事务没有提交崩溃后所有改动都回滚了。玩家看到的是上一次完整提交的状态并不是数据“丢”了。但如果你希望“不丢”任何进度就得把事务提交频率调高。比如每完成一场战斗、每升一级、每获得一件关键道具都提交一次换来的是更小粒度的进度保存。量产型玩法数据则可以放宽到批量提交甚至周期提交。这套分频保存策略是我从实际项目中总结出来的核心经验没有“绝对不丢”配置只有“根据数据价值决定保存频率”。5. 更进一步的优化方向当游戏系统逐渐膨胀之后还能从几个方向进一步扩展SQLite的用法。查询缓存高频访问的配置数据不需要每次请求数据库可以在启动时加载到内存字典运行中直接读内存只在数据变更时更新缓存。读取路径从“查库”变成了“查字典”性能还有数倍提升空间。数据库拆库如果游戏有大量只读配置和少量频繁修改的玩家数据可以考虑把配置库文件和数据库文件拆开。配置库以只读方式打开放在资源目录或可寻址资源中减少主库体积也降低每次云备份的上传量。加密能力如果不希望玩家直接改存档SQLite生态有加密扩展。但要注意加密会引入额外的复杂度和性能损耗需要在作弊防护和调试便利之间取舍。我目前项目中还没启用加密但对联机排名类数据后期会考虑在同步层做签名校验而不是给整个库加密。再往前扩展SQLite还能承担本地事件日志、埋点统计、资源热更版本记录等功能。它不单单是“存档数据库”更像是游戏本地的迷你数据中心。这个思维转变才是从JSON迁移到SQLite最大的收获。6. 写在最后的实在话数据库接入本身不是高深技术难的是一开始就确定边界哪些数据该进库、哪些不该进库、什么时候提交、什么时候批量写。我试过把所有状态都往库里塞最后小到一个开关按钮都要查一次数据库完全没有必要。内存、静态配置、玩家本地偏好这类数据留在内存里反而更快、更简单。我个人体会最深的还是SQLite给游戏带来的本质上是把存档从“整文件覆盖”升级成“按记录变更”的能力。这个转变会让存档体的设计思路发生连锁变化也让后期扩展系统时不必反复打回重来。下一篇日记大概会写战斗系统的数值框架怎么与存档表结构配合如果对这块感兴趣可以继续关注这个系列。