开发HarmonyOS应用时凡是涉及结构化数据的本地存储关系型数据库RelationalStore都是绕不开的核心组件。无论是聊天记录、订单列表还是需要支持复杂查询的业务数据用数据表来管理远比如用首选项Preferences堆字符串靠谱得多。这篇文章我从实际项目出发把关系型数据库的选型逻辑、配置步骤、增删改查写法、版本升级以及几个容易踩的坑一次说清楚内容偏实战适合正在做应用数据层的开发者参考。1. 为什么关系型数据库在HarmonyOS里不可替代很多人一开始容易混淆一个点HarmonyOS明明提供了用户首选项Preferences和键值型数据库KVStore为什么还要引入一套关系型数据库RelationalStore我刚开始做应用数据层时也犹豫过但实际跑过几个业务场景后结论非常明确——数据之间有明确关联、需要条件查询、需要事务保证时关系型数据库是唯一合理的选择。Preferences的定位是轻量级键值存储适合存用户偏好设置、应用配置项这类单键单值的数据。键值型数据库如分布式键值库在跨设备同步上有优势但它的查询模型依然偏按key取value遇到查今年三月份金额大于五百的订单并关联用户表这类需求要么在内存里暴力过滤要么自己维护索引代码复杂度会迅速失控。关系型数据库的核心价值是把它当成一个运行在应用沙箱内的迷你数据库服务提供了完整的SQL能力、事务机制和索引管理。HarmonyOS的RelationalStore底层实现已经做过封装开发者不需要关心数据文件如何落盘、WAL日志怎么维护只需要专注于表结构设计和业务SQL。我通常用下面这个标准来判断项目中该用哪种存储存储方式适合场景不适合场景Preferences开关配置、用户偏好、轻量缓存列表数据、条件查询、关联查询键值型数据库分布式同步场景、简单状态同步复杂过滤、多表关联、事务操作关系型数据库订单、消息、账本、一切结构化数据超大字段存储、高频纯key查询实践下来日常应用大约七成以上的持久化需求最终都会落到关系型数据库上。它没有那么轻但能支撑的业务复杂度上限高得多。对于需要长期迭代的应用前期用一个关系型存储方案打底后续扩展起来会舒服很多。2. 连接数据库前的必修课配置与初始化细节关系型数据库的入口是对应应用沙箱内的一个关系型数据库实例创建和配置时需要先理解它的几个核心概念数据库配置文件StoreConfig、数据库路径、以及安全等级SecurityLevel。这几个参数直接决定了数据库的行为方式配置不对后面全白搭。2.1 StoreConfig的关键参数与选择理由配置关系型数据库时需要定义一个StoreConfig对象。它的关键属性包括数据库名、安全等级以及是否开启加密等。最基础的创建逻辑如下import { relationalStore } from kit.ArkData; const config: relationalStore.StoreConfig { name: demo_store.db, securityLevel: relationalStore.SecurityLevel.S1, encrypt: false };这里面的name是数据库文件名会关联到应用沙箱内的数据库目录。securityLevel有S1到S4几个档位简单理解就是数据允许访问的范围S1只允许应用自身访问适合纯本地私有数据S2允许同账号的其它设备/应用访问适合多设备协同场景S3允许同账号和跨账号的特定可信设备访问S4允许所有设备访问通常配合严格的数据管控策略我个人的经验是没有明确跨设备诉求时一律用S1。因为在开发调试阶段如果安全等级设得过高后续做分布式迁移或数据备份时会引入额外的访问控制约束排查起来比较麻烦。encrypt参数容易被人忽略它决定数据库是否启用加密存储。如果应用涉及敏感信息比如用户账单、健康数据建议直接开启。加密会带来些许性能开销但相比数据泄露的风险这一点性能损失完全值得。2.2 连接、初始化与单例模式的必要性创建数据库的入口是getRdbStore。它会根据配置文件去沙箱目录里找数据库如果不存在则新建如果存在则直接打开import { relationalStore } from kit.ArkData; import { UIAbility } from kit.AbilityKit; import { window } from kit.ArkUI; import { BusinessError } from kit.BasicServicesKit; export default class EntryAbility extends UIAbility { private rdbStore: relationalStore.RdbStore | null null; onWindowStageCreate(windowStage: window.WindowStage): void { const config: relationalStore.StoreConfig { name: demo_store.db, securityLevel: relationalStore.SecurityLevel.S1, encrypt: false }; relationalStore.getRdbStore(this.context, config, (err, store) { if (err) { console.error(Failed to get RdbStore. Code:${err.code}, message:${err.message}); return; } this.rdbStore store; console.info(Succeeded in getting RdbStore.); // 后续业务逻辑 }); } }这里有一个非常容易踩的坑getRdbStore是异步操作数据库连接不是立刻可用的。如果业务代码在回调返回前就尝试执行SQL会因为store为空而直接崩溃。所以我在项目里通常把它封装成单例在应用启动阶段完成初始化后面的业务模块直接获取实例使用class RdbManager { private static instance: RdbManager | null null; private store: relationalStore.RdbStore | null null; static getInstance(): RdbManager { if (!RdbManager.instance) { RdbManager.instance new RdbManager(); } return RdbManager.instance; } async init(context: Context): Promisevoid { if (this.store) { return; } const config: relationalStore.StoreConfig { name: demo_store.db, securityLevel: relationalStore.SecurityLevel.S1, encrypt: false }; this.store await relationalStore.getRdbStore(context, config); // 建表等初始化逻辑 } getStore(): relationalStore.RdbStore { if (!this.store) { throw new Error(RdbStore is not initialized yet.); } return this.store; } }用一个getter统一暴露store实例可以在所有数据访问代码里杜绝Store还没准备好就操作数据库这类竞态问题。这也是我修复过的最常见的崩溃原因之一。3. 建表与SQL执行从零构建数据层的基础操作连接上数据库之后第一件事一般是建表。HarmonyOS的关系型数据库提供的是执行SQL的底层能力同时也封装了一些面向对象的辅助方法。两种方式我都在用但建议优先掌握原始SQL因为很多高级表结构联合索引、约束、触发器用辅助方法表达起来很别扭。3.1 执行建表SQL的正确姿势建表在初始化阶段做一次即可不需要每次启动都执行。但因为数据库版本升级时后面会专门讲也要用到类似逻辑所以我把表结构维护统一放在初始化方法里const SQL_CREATE_USER_TABLE CREATE TABLE IF NOT EXISTS user ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL, age INTEGER, email TEXT UNIQUE, created_at TEXT DEFAULT CURRENT_TIMESTAMP ) ; async init(context: Context): Promisevoid { if (this.store) { return; } const config: relationalStore.StoreConfig { name: demo_store.db, securityLevel: relationalStore.SecurityLevel.S1, encrypt: false }; this.store await relationalStore.getRdbStore(context, config); await this.store.executeSql(SQL_CREATE_USER_TABLE); }executeSql接口接收完整的CREATE语句和标准SQL基本一致。这里有两个细节值得注意IF NOT EXISTS是必须的。虽然数据库只在首次创建时执行建表但应用启动多次后如果建表逻辑被重复执行没有这个保护就会直接报表已存在错误。主键用AUTOINCREMENT虽然会带来极小的性能开销但可以避免删除记录后主键复用导致的幽灵数据问题。对大多数业务表来说这个保险值得买。3.2 实体表设计一次到位还是后面迭代很多开发者一开始建表时只追求能用字段越少越好等业务复杂了再慢慢加列。这种思路在开发期省事上线后就会变成升级地狱。因为关系型数据库的ALTER TABLE能力是受限的有些修改比如改字段类型根本做不到只能重建表。我在初始设计时会遵循几个原则所有业务表必须带id主键和created_at时间戳字段。前者用于唯一标识后者用于排序、清理、断点续传等场景。凡是以后可能要查的字段一律加索引或设为UNIQUE约束。例如用户的邮箱、订单号这些字段就是天然的查询入口。考虑数据清理策略。聊天记录、历史日志这类无限增长的数据如果没有created_at字段以后想按时间批量删除都没有依据。到了这一步数据层的基础结构基本成型下面进入核心的增删改查环节。4. 增删改查实战ValuesBucket与Predicates组合的完整用法关系型数据库的业务操作主要围绕两个核心类展开ValuesBucket用于承载要写入的数据和Predicates用于描述查询/更新/删除的条件。理解这两者的配合方式就掌握了这个数据库八成的用法。4.1 数据插入ValuesBucket的隐式字段映射ValuesBucket本质是一个键值对容器key对应表字段名value对应要写入的值import { relationalStore } from kit.ArkData; const store RdbManager.getInstance().getStore(); const valuesBucket: relationalStore.ValuesBucket { name: 张三, age: 28, email: zhangsanexample.com }; const ret await store.insert(user, valuesBucket); console.info(Inserted user id: ${ret});insert方法返回的是新记录的行号。你不需要手动指定id只要标明了AUTOINCREMENT数据库会自动分配。这里有个容易忽略的点ValuesBucket的字段名必须和表字段名完全一致大小写也要匹配。如果你建表时用了User_Name插入时写成user_name就会静默失败或者报字段不存在的错误。我建议建表字段统一用蛇形命名snake_case这样在JS/TS侧写对象key时天然一致。4.2 查询Predicates是所有条件的起点查询是关系型数据库最常用的操作也是最能体现关系型价值的地方。核心逻辑是先构造一个RdbPredicates指定表名和条件再传给query方法const predicates new relationalStore.RdbPredicates(user); predicates.equalTo(age, 28) .orderByAsc(id); const resultSet await store.query(predicates, [id, name, email]);query方法第二组参数是查询的字段列表只返回需要的列能显著降低序列化和内存开销。这个方法返回的是ResultSet需要通过游标遍历来读取数据while (resultSet.goToNextRow()) { const id resultSet.getLong(resultSet.getColumnIndex(id)); const name resultSet.getString(resultSet.getColumnIndex(name)); const email resultSet.getString(resultSet.getColumnIndex(email)); // 组装业务对象 } resultSet.close();ResultSet用完必须close。这是我反复强调的一点。它本质上是一个数据库游标打开期间会持有底层资源。项目初期我经常忘记关闭结果连续操作几十次后数据库访问开始变慢内存占用明显上涨。后来我统一在封装的查询方法里用try/finally确保close必然执行问题就再没出现过。Predicates支持很多常见SQL条件我把常用的整理成了一张对照表Predicates方法对应SQL语义示例equalTo / notEqualTo / !predicates.equalTo(status, 1)greaterThan / lessThan / predicates.greaterThan(age, 18)containsLIKE %value%predicates.contains(name, 张)beginsWithLIKE value%predicates.beginsWith(name, 张)isNull / isNotNullIS NULL / IS NOT NULLpredicates.isNull(email)orderByAsc / orderByDescORDER BY ASC/DESCpredicates.orderByDesc(created_at)limitAsLIMITpredicates.limitAs(20)and / orAND / ORpredicates.and().equalTo(age, 20)组合条件的写法是链式调用但要注意and()和or()的显式使用。默认情况下多个条件之间是AND关系但一旦你手动用了or()后续条件就按OR并入。想要表达(age 20 AND name 张三) OR (age 30)这类复杂逻辑必须用括号分组语义来构造好在Predicates的链式顺序基本对应SQL从左到右的解析顺序。4.3 更新与删除条件务必写全更新和删除在API形态上和查询类似只是执行语义不同// 更新 const updateValues: relationalStore.ValuesBucket { age: 29 }; const updatePredicates new relationalStore.RdbPredicates(user); updatePredicates.equalTo(id, 1); const rows await store.update(updateValues, updatePredicates); console.info(Updated rows: ${rows}); // 删除 const deletePredicates new relationalStore.RdbPredicates(user); deletePredicates.lessThan(id, 100); const deletedRows await store.delete(deletePredicates); console.info(Deleted rows: ${deletedRows});更新和删除都返回受影响的行数。我在这个环节踩过最惨的坑是忘了加条件导致整个表的数据被清空。当时是一个测试账号不小心执行了delete方法但没有追加任何条件结果等于全表删除。所以在封装数据访问层时凡是执行更新和删除我都会在方法里做一层条件非空校验function assertPredicatesNotEmpty(predicates: relationalStore.RdbPredicates): void { const sql predicates.getWhereClause(); if (!sql || sql.length 0) { throw new Error(Dangerous operation: predicates is empty, refuse to execute.); } }这个守卫函数虽然简单但在一定程度上避免了手滑清库的灾难。4.4 事务多步写入的原子性保障关系型数据库的事务能力在处理一组操作必须同时成功或同时失败时非常关键。比如转账要扣A余额和加B余额两步都是必须成功的再比如批量插入时我希望要么全部插入要么一条都不留try { await store.beginTransaction(); // 批量插入 for (const item of orderList) { await store.insert(orders, { order_no: item.orderNo, amount: item.amount, user_id: item.userId }); } await store.commit(); } catch (err) { await store.rollback(); throw err; }beginTransaction开启事务commit提交事务rollback回滚事务。事务的粒度从小到大都有讲究小事务批量合并循环内逐条插容易慢、大事务注意耗时别在前台线程执行需要写入大量数据的操作。事务期间数据库会持有写锁其他写操作会被阻塞。所以事务里的逻辑要尽量精简不在事务里做网络请求或复杂计算避免长时间占用数据库。5. 数据库升级与版本管理从加张表到改字段的完整链路应用迭代必然伴随着数据库结构变化新增表、新增字段、修改默认值甚至数据迁移。关系型数据库对此提供了版本管理机制理解它的原理就能优雅处理所有结构变更场景。5.1 版本号机制与onUpgrade回调StoreConfig里有一个version字段标识当前数据库的版本。应用每次升级时把期望的版本号写在配置里数据库打开时如果发现本地版本号低于配置版本号就会触发升级回调const config: relationalStore.StoreConfig { name: demo_store.db, securityLevel: relationalStore.SecurityLevel.S1, encrypt: false, version: 2 };数据库结构变更的逻辑统一放在升级回调里relationalStore.getRdbStore(context, config, (err, store) { if (err) { console.error(Failed to get RdbStore. Code:${err.code}, message:${err.message}); return; } const db: relationalStore.RdbStore store; if (db.version 2) { // 从 v1 - v2 的迁移逻辑 db.executeSql(ALTER TABLE user ADD COLUMN phone TEXT); } });RdbStore上有一个version属性读取它就可以判断当前本地库的版本再配合StoreConfig里声明的目标版本每次启动时做增量迁移。这里的关键是迁移逻辑必须是增量的、可重复判定版本的。我第一次写升级脚本时把加字段和建新表的逻辑混在一起一旦用户从很老的版本直接跳到最新版中间某些表字段就不存在SQL直接报错。后来我改成按版本号分段执行if (db.version 2) { // v1 - v2: 新增phone字段 } if (db.version 3) { // v2 - v3: 新增订单表 } if (db.version 4) { // v3 - v4: 订单表增加索引 } // 最后统一赋值为当前版本这样每个升级包都是独立的用户无论从哪个旧版本升上来都会逐年迈过每个版本门槛不会漏掉任何一步。5.2 ALTER TABLE的边界与重建表策略SQLite的ALTER TABLE能力非常有限只能加列、改表名不能改列的类型不能直接删除列也不能直接修改约束。我在做一次数据模型重构时就遇到过这种情况——需要把user表里的age字段改成birthday字段同时要保留历史数据。直接ALTER TABLE做不到只能按下面这套流程处理await db.executeSql(BEGIN TRANSACTION); // 1. 创建新表 await db.executeSql( CREATE TABLE user_new ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL, birthday TEXT, email TEXT UNIQUE, created_at TEXT DEFAULT CURRENT_TIMESTAMP ) ); // 2. 数据迁移 await db.executeSql( INSERT INTO user_new (id, name, birthday, email, created_at) SELECT id, name, age, email, created_at FROM user ); // 3. 删除旧表 await db.executeSql(DROP TABLE user); // 4. 重命名新表 await db.executeSql(ALTER TABLE user_new RENAME TO user); await db.executeSql(COMMIT);这套建新表-搬数据-删旧表-改名的流程是标准的表结构重构方案。事务包裹让整个过程具备原子性中途任何一步失败都无法影响原表数据。要注意的是数据量大时这个操作会比较耗时建议放在应用启动后的后台任务里执行避免阻塞主流程。5.3 从数据库到业务层游标结果的映射实践数据库查询返回的是ResultSet但业务层不希望直接操作这种游标对象。我在项目里习惯封装一个通用映射函数把ResultSet转成业务对象数组function resultSetToArrayT(resultSet: relationalStore.ResultSet, mapper: (rs: relationalStore.ResultSet) T): T[] { const list: T[] []; try { while (resultSet.goToNextRow()) { list.push(mapper(resultSet)); } } finally { resultSet.close(); } return list; } // 使用示例 const users resultSetToArray(resultSet, (rs) ({ id: rs.getLong(rs.getColumnIndex(id)), name: rs.getString(rs.getColumnIndex(name)), email: rs.getString(rs.getColumnIndex(email)) }));这样每次查询的ResultSet都在结束时被可靠关闭业务层拿到的只是干净的数据数组。6. 跨进程与并发场景多端多线程操作数据库的避坑指南关系型数据库在HarmonyOS上不仅是单进程内使用在跨进程比如ArkTS接口服务扩展配合或者多线程并发场景下容易遇到数据库被锁写入竞争性能下降之类的问题。这一节把我在实际联调中的经验和排查思路做一个完整梳理。6.1 多页面、多线程同时读写时的冲突处理HarmonyOS应用内部可能同时有多个任务在访问同一个RdbStore主页面在查询列表后台线程在同步数据服务扩展在写入日志。关系型数据库内部虽然有锁机制但多个写操作并发时部分时机可能抛出database is locked的错误。我在项目中采用了一个简单有效的策略所有数据库操作统一走数据访问层Repository数据访问层内部维护一个串行队列。不管是查询还是写入都丢到同一个队列中执行从源头避免并发访问冲突import { BusinessError } from kit.BasicServicesKit; class UserRepository { private store: relationalStore.RdbStore; private taskQueue: Promisevoid Promise.resolve(); constructor(store: relationalStore.RdbStore) { this.store store; } private enqueueT(task: () PromiseT): PromiseT { const result this.taskQueue.then(task); this.taskQueue result.then(() undefined, () undefined); return result; } async insertUser(name: string, age: number): Promisenumber { return this.enqueue(async () { const values: relationalStore.ValuesBucket { name: name, age: age }; return await this.store.insert(user, values); }); } async queryUsers(): PromiseArray{ id: number; name: string } { return this.enqueue(async () { const predicates new relationalStore.RdbPredicates(user); const resultSet await this.store.query(predicates, [id, name]); return resultSetToArray(resultSet, (rs) ({ id: rs.getLong(rs.getColumnIndex(id)), name: rs.getString(rs.getColumnIndex(name)) })); }); } }串行队列牺牲了一点并发度但换来了极强的稳定性。查询本身是并发安全的但入口统一后就可以在队列里做多写合并、缓存复用等优化收益远大于损失。6.2 连接池与单线程访问模型HarmonyOS的RdbStore对象在单进程内是单例复用的官方不建议为每个页面都创建一个新连接那样既浪费资源又容易导致锁竞争。数据库文件的连接数有限多次getRdbStore会拿到不同实例反而增加了出问题的概率。我统一采用全局唯一RdbManager的模式应用启动时获取一次RdbStore存为全局单例所有数据访问都从这个实例走。这样做还有另一个好处——后续要接分布式能力或做数据加密时只需要在初始化配置里调整业务层完全无感。6.3 大批量数据写入的性能对比与优化手段如果一次性要插入几百上千条数据最直接的做法是循环insert但实测来看逐条insert几千条数据可能需要数秒到十几秒不等。关系型数据库事务的提交开销非常高合并在一个事务里能显著加速写入方式1000条耗时实测参考说明逐条insert不开事务3-10秒以上每条都触发一次完整的写事务单事务内批量insert1秒以内只提交一次事务日志落盘次数大幅减少批量ValuesBucket数组insert和单事务接近框架内部优化代码最简洁RdbStore提供了一个batchInsert方法支持一次性传入ValuesBucket数组const valuesBuckets: relationalStore.ValuesBucket[] []; for (const item of syncData) { valuesBuckets.push({ name: item.name, age: item.age }); } const insertedRows await store.batchInsert(user, valuesBuckets);批量插入虽然在事务内部执行但单条失败不会自动回滚整个批次所以批量数据在插入前要做必要的合法性校验。对于真正的关键数据我还是会选择手动beginTransaction 逐条insertcommit的组合这样能在出错时精确控制回滚粒度。7. 数据的后顾之忧备份、恢复与安全存储本地数据都存在应用沙箱里用户一旦卸载应用数据就全部没了。虽然HarmonyOS备份机制会为应用提供云端备份能力但对于关键业务数据开发者还是要主动设计备份和恢复方案。7.1 数据文件级备份方案最朴素但可靠的备份方式是直接拷贝数据库文件。RdbStore对应的数据库文件位于应用沙箱的数据库目录下文件名为创建时的name字段值。可以通过文件IO把数据库文件复制到应用自己的备份目录或通过分布式文件系统同步到其他设备。import { fileIo } from kit.CoreFileKit; import { common } from kit.AbilityKit; async function backupDatabase(context: common.Context): Promisevoid { const srcPath context.databaseDir /demo_store.db; const backupPath context.filesDir /backup_demo_store.db; const file fileIo.openSync(srcPath, fileIo.OpenMode.READ_ONLY); const out fileIo.openSync(backupPath, fileIo.OpenMode.READ_WRITE | fileIo.OpenMode.CREATE | fileIo.OpenMode.TRUNC); try { await fileIo.copyFile(file.fd, out.fd); } finally { fileIo.closeSync(file); fileIo.closeSync(out); } }注意备份时最好确认当前没有正在执行写事务。虽然文件拷贝在大多数情况下不会损坏数据但严格的备份应该在数据库空闲时进行或者先通过数据库自身的导出机制生成一致性的快照。7.2 数据库加密与隐私合规前面提到过StoreConfig里的encrypt参数。如果应用采集了用户隐私数据身份证号、位置信息、通讯录等强烈建议开启。加密库的密钥由系统管理开发者不需要在自己的业务代码里维护密钥这比自己在SQL外面套一层AES要安全得多。开发调试阶段如果开启了加密通过命令行工具直接查看数据库文件内容会看到密文不方便调试。可以在debug包中关闭加密release包中开启但要确保这两种模式的数据迁移逻辑一致。7.3 数据生命周期与清理策略本地数据库如果只增不删最终会撑爆用户存储空间。我在数据访问层里预留了清理接口按照业务类型设定保留周期历史日志保留30天操作记录保留90天核心业务数据永久保留但定期归档冷数据清理动作一般在应用冷启动或进入后台时执行使用Predicates按时间字段批量删除配合事务提交避免删除操作阻塞正常读写。8. 实测阶段最容易翻车的四个场景与排除思路最后分享几个我在真实项目里频繁遇到的翻车场景这些问题光看文档不一定能意识到但99%的开发者迟早会撞上。8.1 No such table建表SQL没执行成功新手第一个坑往往是这个报错。原因是建表SQL是异步执行的getRdbStore返回后立刻去查表但CREATE TABLE还没跑完。解决办法是把建表逻辑放在getRdbStore回调里或者用async/await确保初始化完成后再开放业务入口。8.2 Database corrupted进程被杀导致的数据库损坏异常断电或杀进程可能让数据库文件处于不一致状态。RdbStore内置了WAL日志机制正常情况下能自动恢复。但如果观察到启动时频繁报corrupted错误建议在初始化前先尝试打开备份库或执行完整性校验const checkResult await store.executeSql(PRAGMA integrity_check);如果integrity_check返回的不是ok说明数据库文件已经损坏此时应走备份恢复流程。8.3 ResultSet closed游标提前释放在遍历ResultSet时如果中途不小心调用了close后续goToNextRow就会抛错。这种问题通常出现在提前return或回调中异步操作的场景。把所有游标读取逻辑收敛到一个函数内集中处理close能最大程度避免这类错误。8.4 时间字段的时区陷阱数据库存时间戳时如果直接用DATE(now)或CURRENT_TIMESTAMP取到的是UTC时间和本地时间可能差8个小时。用户看到下单时间不对往往就是这个原因。我的处理方案是应用层组装时间字符串时统一用本地时区格式化存入数据库的字段一律用TEXT类型存ISO8601格式查询时再用日期函数解析。避免在SQL里做时区计算逻辑会清晰很多。最后再分享一点个人经验关系型数据库在HarmonyOS应用里承担的是数据地基的角色地基打得稳上层业务怎么盖都不怕。很多性能和稳定性的问题追根溯源都不是SQL写错了而是初始化时序、连接复用、事务粒度这些数据库周边的问题。我的建议是先把初始化单例化、操作串行化、游标集中关闭这三件事做扎实再去抠SQL性能优化方向一定不会错。数据层的代码值得花时间打磨它直接影响用户每一次启动应用时的体验。
开发HarmonyOS应用时凡是涉及结构化数据的本地存储关系型数据库RelationalStore都是绕不开的核心组件。无论是聊天记录、订单列表还是需要支持复杂查询的业务数据用数据表来管理远比如用首选项Preferences堆字符串靠谱得多。这篇文章我从实际项目出发把关系型数据库的选型逻辑、配置步骤、增删改查写法、版本升级以及几个容易踩的坑一次说清楚内容偏实战适合正在做应用数据层的开发者参考。1. 为什么关系型数据库在HarmonyOS里不可替代很多人一开始容易混淆一个点HarmonyOS明明提供了用户首选项Preferences和键值型数据库KVStore为什么还要引入一套关系型数据库RelationalStore我刚开始做应用数据层时也犹豫过但实际跑过几个业务场景后结论非常明确——数据之间有明确关联、需要条件查询、需要事务保证时关系型数据库是唯一合理的选择。Preferences的定位是轻量级键值存储适合存用户偏好设置、应用配置项这类单键单值的数据。键值型数据库如分布式键值库在跨设备同步上有优势但它的查询模型依然偏按key取value遇到查今年三月份金额大于五百的订单并关联用户表这类需求要么在内存里暴力过滤要么自己维护索引代码复杂度会迅速失控。关系型数据库的核心价值是把它当成一个运行在应用沙箱内的迷你数据库服务提供了完整的SQL能力、事务机制和索引管理。HarmonyOS的RelationalStore底层实现已经做过封装开发者不需要关心数据文件如何落盘、WAL日志怎么维护只需要专注于表结构设计和业务SQL。我通常用下面这个标准来判断项目中该用哪种存储存储方式适合场景不适合场景Preferences开关配置、用户偏好、轻量缓存列表数据、条件查询、关联查询键值型数据库分布式同步场景、简单状态同步复杂过滤、多表关联、事务操作关系型数据库订单、消息、账本、一切结构化数据超大字段存储、高频纯key查询实践下来日常应用大约七成以上的持久化需求最终都会落到关系型数据库上。它没有那么轻但能支撑的业务复杂度上限高得多。对于需要长期迭代的应用前期用一个关系型存储方案打底后续扩展起来会舒服很多。2. 连接数据库前的必修课配置与初始化细节关系型数据库的入口是对应应用沙箱内的一个关系型数据库实例创建和配置时需要先理解它的几个核心概念数据库配置文件StoreConfig、数据库路径、以及安全等级SecurityLevel。这几个参数直接决定了数据库的行为方式配置不对后面全白搭。2.1 StoreConfig的关键参数与选择理由配置关系型数据库时需要定义一个StoreConfig对象。它的关键属性包括数据库名、安全等级以及是否开启加密等。最基础的创建逻辑如下import { relationalStore } from kit.ArkData; const config: relationalStore.StoreConfig { name: demo_store.db, securityLevel: relationalStore.SecurityLevel.S1, encrypt: false };这里面的name是数据库文件名会关联到应用沙箱内的数据库目录。securityLevel有S1到S4几个档位简单理解就是数据允许访问的范围S1只允许应用自身访问适合纯本地私有数据S2允许同账号的其它设备/应用访问适合多设备协同场景S3允许同账号和跨账号的特定可信设备访问S4允许所有设备访问通常配合严格的数据管控策略我个人的经验是没有明确跨设备诉求时一律用S1。因为在开发调试阶段如果安全等级设得过高后续做分布式迁移或数据备份时会引入额外的访问控制约束排查起来比较麻烦。encrypt参数容易被人忽略它决定数据库是否启用加密存储。如果应用涉及敏感信息比如用户账单、健康数据建议直接开启。加密会带来些许性能开销但相比数据泄露的风险这一点性能损失完全值得。2.2 连接、初始化与单例模式的必要性创建数据库的入口是getRdbStore。它会根据配置文件去沙箱目录里找数据库如果不存在则新建如果存在则直接打开import { relationalStore } from kit.ArkData; import { UIAbility } from kit.AbilityKit; import { window } from kit.ArkUI; import { BusinessError } from kit.BasicServicesKit; export default class EntryAbility extends UIAbility { private rdbStore: relationalStore.RdbStore | null null; onWindowStageCreate(windowStage: window.WindowStage): void { const config: relationalStore.StoreConfig { name: demo_store.db, securityLevel: relationalStore.SecurityLevel.S1, encrypt: false }; relationalStore.getRdbStore(this.context, config, (err, store) { if (err) { console.error(Failed to get RdbStore. Code:${err.code}, message:${err.message}); return; } this.rdbStore store; console.info(Succeeded in getting RdbStore.); // 后续业务逻辑 }); } }这里有一个非常容易踩的坑getRdbStore是异步操作数据库连接不是立刻可用的。如果业务代码在回调返回前就尝试执行SQL会因为store为空而直接崩溃。所以我在项目里通常把它封装成单例在应用启动阶段完成初始化后面的业务模块直接获取实例使用class RdbManager { private static instance: RdbManager | null null; private store: relationalStore.RdbStore | null null; static getInstance(): RdbManager { if (!RdbManager.instance) { RdbManager.instance new RdbManager(); } return RdbManager.instance; } async init(context: Context): Promisevoid { if (this.store) { return; } const config: relationalStore.StoreConfig { name: demo_store.db, securityLevel: relationalStore.SecurityLevel.S1, encrypt: false }; this.store await relationalStore.getRdbStore(context, config); // 建表等初始化逻辑 } getStore(): relationalStore.RdbStore { if (!this.store) { throw new Error(RdbStore is not initialized yet.); } return this.store; } }用一个getter统一暴露store实例可以在所有数据访问代码里杜绝Store还没准备好就操作数据库这类竞态问题。这也是我修复过的最常见的崩溃原因之一。3. 建表与SQL执行从零构建数据层的基础操作连接上数据库之后第一件事一般是建表。HarmonyOS的关系型数据库提供的是执行SQL的底层能力同时也封装了一些面向对象的辅助方法。两种方式我都在用但建议优先掌握原始SQL因为很多高级表结构联合索引、约束、触发器用辅助方法表达起来很别扭。3.1 执行建表SQL的正确姿势建表在初始化阶段做一次即可不需要每次启动都执行。但因为数据库版本升级时后面会专门讲也要用到类似逻辑所以我把表结构维护统一放在初始化方法里const SQL_CREATE_USER_TABLE CREATE TABLE IF NOT EXISTS user ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL, age INTEGER, email TEXT UNIQUE, created_at TEXT DEFAULT CURRENT_TIMESTAMP ) ; async init(context: Context): Promisevoid { if (this.store) { return; } const config: relationalStore.StoreConfig { name: demo_store.db, securityLevel: relationalStore.SecurityLevel.S1, encrypt: false }; this.store await relationalStore.getRdbStore(context, config); await this.store.executeSql(SQL_CREATE_USER_TABLE); }executeSql接口接收完整的CREATE语句和标准SQL基本一致。这里有两个细节值得注意IF NOT EXISTS是必须的。虽然数据库只在首次创建时执行建表但应用启动多次后如果建表逻辑被重复执行没有这个保护就会直接报表已存在错误。主键用AUTOINCREMENT虽然会带来极小的性能开销但可以避免删除记录后主键复用导致的幽灵数据问题。对大多数业务表来说这个保险值得买。3.2 实体表设计一次到位还是后面迭代很多开发者一开始建表时只追求能用字段越少越好等业务复杂了再慢慢加列。这种思路在开发期省事上线后就会变成升级地狱。因为关系型数据库的ALTER TABLE能力是受限的有些修改比如改字段类型根本做不到只能重建表。我在初始设计时会遵循几个原则所有业务表必须带id主键和created_at时间戳字段。前者用于唯一标识后者用于排序、清理、断点续传等场景。凡是以后可能要查的字段一律加索引或设为UNIQUE约束。例如用户的邮箱、订单号这些字段就是天然的查询入口。考虑数据清理策略。聊天记录、历史日志这类无限增长的数据如果没有created_at字段以后想按时间批量删除都没有依据。到了这一步数据层的基础结构基本成型下面进入核心的增删改查环节。4. 增删改查实战ValuesBucket与Predicates组合的完整用法关系型数据库的业务操作主要围绕两个核心类展开ValuesBucket用于承载要写入的数据和Predicates用于描述查询/更新/删除的条件。理解这两者的配合方式就掌握了这个数据库八成的用法。4.1 数据插入ValuesBucket的隐式字段映射ValuesBucket本质是一个键值对容器key对应表字段名value对应要写入的值import { relationalStore } from kit.ArkData; const store RdbManager.getInstance().getStore(); const valuesBucket: relationalStore.ValuesBucket { name: 张三, age: 28, email: zhangsanexample.com }; const ret await store.insert(user, valuesBucket); console.info(Inserted user id: ${ret});insert方法返回的是新记录的行号。你不需要手动指定id只要标明了AUTOINCREMENT数据库会自动分配。这里有个容易忽略的点ValuesBucket的字段名必须和表字段名完全一致大小写也要匹配。如果你建表时用了User_Name插入时写成user_name就会静默失败或者报字段不存在的错误。我建议建表字段统一用蛇形命名snake_case这样在JS/TS侧写对象key时天然一致。4.2 查询Predicates是所有条件的起点查询是关系型数据库最常用的操作也是最能体现关系型价值的地方。核心逻辑是先构造一个RdbPredicates指定表名和条件再传给query方法const predicates new relationalStore.RdbPredicates(user); predicates.equalTo(age, 28) .orderByAsc(id); const resultSet await store.query(predicates, [id, name, email]);query方法第二组参数是查询的字段列表只返回需要的列能显著降低序列化和内存开销。这个方法返回的是ResultSet需要通过游标遍历来读取数据while (resultSet.goToNextRow()) { const id resultSet.getLong(resultSet.getColumnIndex(id)); const name resultSet.getString(resultSet.getColumnIndex(name)); const email resultSet.getString(resultSet.getColumnIndex(email)); // 组装业务对象 } resultSet.close();ResultSet用完必须close。这是我反复强调的一点。它本质上是一个数据库游标打开期间会持有底层资源。项目初期我经常忘记关闭结果连续操作几十次后数据库访问开始变慢内存占用明显上涨。后来我统一在封装的查询方法里用try/finally确保close必然执行问题就再没出现过。Predicates支持很多常见SQL条件我把常用的整理成了一张对照表Predicates方法对应SQL语义示例equalTo / notEqualTo / !predicates.equalTo(status, 1)greaterThan / lessThan / predicates.greaterThan(age, 18)containsLIKE %value%predicates.contains(name, 张)beginsWithLIKE value%predicates.beginsWith(name, 张)isNull / isNotNullIS NULL / IS NOT NULLpredicates.isNull(email)orderByAsc / orderByDescORDER BY ASC/DESCpredicates.orderByDesc(created_at)limitAsLIMITpredicates.limitAs(20)and / orAND / ORpredicates.and().equalTo(age, 20)组合条件的写法是链式调用但要注意and()和or()的显式使用。默认情况下多个条件之间是AND关系但一旦你手动用了or()后续条件就按OR并入。想要表达(age 20 AND name 张三) OR (age 30)这类复杂逻辑必须用括号分组语义来构造好在Predicates的链式顺序基本对应SQL从左到右的解析顺序。4.3 更新与删除条件务必写全更新和删除在API形态上和查询类似只是执行语义不同// 更新 const updateValues: relationalStore.ValuesBucket { age: 29 }; const updatePredicates new relationalStore.RdbPredicates(user); updatePredicates.equalTo(id, 1); const rows await store.update(updateValues, updatePredicates); console.info(Updated rows: ${rows}); // 删除 const deletePredicates new relationalStore.RdbPredicates(user); deletePredicates.lessThan(id, 100); const deletedRows await store.delete(deletePredicates); console.info(Deleted rows: ${deletedRows});更新和删除都返回受影响的行数。我在这个环节踩过最惨的坑是忘了加条件导致整个表的数据被清空。当时是一个测试账号不小心执行了delete方法但没有追加任何条件结果等于全表删除。所以在封装数据访问层时凡是执行更新和删除我都会在方法里做一层条件非空校验function assertPredicatesNotEmpty(predicates: relationalStore.RdbPredicates): void { const sql predicates.getWhereClause(); if (!sql || sql.length 0) { throw new Error(Dangerous operation: predicates is empty, refuse to execute.); } }这个守卫函数虽然简单但在一定程度上避免了手滑清库的灾难。4.4 事务多步写入的原子性保障关系型数据库的事务能力在处理一组操作必须同时成功或同时失败时非常关键。比如转账要扣A余额和加B余额两步都是必须成功的再比如批量插入时我希望要么全部插入要么一条都不留try { await store.beginTransaction(); // 批量插入 for (const item of orderList) { await store.insert(orders, { order_no: item.orderNo, amount: item.amount, user_id: item.userId }); } await store.commit(); } catch (err) { await store.rollback(); throw err; }beginTransaction开启事务commit提交事务rollback回滚事务。事务的粒度从小到大都有讲究小事务批量合并循环内逐条插容易慢、大事务注意耗时别在前台线程执行需要写入大量数据的操作。事务期间数据库会持有写锁其他写操作会被阻塞。所以事务里的逻辑要尽量精简不在事务里做网络请求或复杂计算避免长时间占用数据库。5. 数据库升级与版本管理从加张表到改字段的完整链路应用迭代必然伴随着数据库结构变化新增表、新增字段、修改默认值甚至数据迁移。关系型数据库对此提供了版本管理机制理解它的原理就能优雅处理所有结构变更场景。5.1 版本号机制与onUpgrade回调StoreConfig里有一个version字段标识当前数据库的版本。应用每次升级时把期望的版本号写在配置里数据库打开时如果发现本地版本号低于配置版本号就会触发升级回调const config: relationalStore.StoreConfig { name: demo_store.db, securityLevel: relationalStore.SecurityLevel.S1, encrypt: false, version: 2 };数据库结构变更的逻辑统一放在升级回调里relationalStore.getRdbStore(context, config, (err, store) { if (err) { console.error(Failed to get RdbStore. Code:${err.code}, message:${err.message}); return; } const db: relationalStore.RdbStore store; if (db.version 2) { // 从 v1 - v2 的迁移逻辑 db.executeSql(ALTER TABLE user ADD COLUMN phone TEXT); } });RdbStore上有一个version属性读取它就可以判断当前本地库的版本再配合StoreConfig里声明的目标版本每次启动时做增量迁移。这里的关键是迁移逻辑必须是增量的、可重复判定版本的。我第一次写升级脚本时把加字段和建新表的逻辑混在一起一旦用户从很老的版本直接跳到最新版中间某些表字段就不存在SQL直接报错。后来我改成按版本号分段执行if (db.version 2) { // v1 - v2: 新增phone字段 } if (db.version 3) { // v2 - v3: 新增订单表 } if (db.version 4) { // v3 - v4: 订单表增加索引 } // 最后统一赋值为当前版本这样每个升级包都是独立的用户无论从哪个旧版本升上来都会逐年迈过每个版本门槛不会漏掉任何一步。5.2 ALTER TABLE的边界与重建表策略SQLite的ALTER TABLE能力非常有限只能加列、改表名不能改列的类型不能直接删除列也不能直接修改约束。我在做一次数据模型重构时就遇到过这种情况——需要把user表里的age字段改成birthday字段同时要保留历史数据。直接ALTER TABLE做不到只能按下面这套流程处理await db.executeSql(BEGIN TRANSACTION); // 1. 创建新表 await db.executeSql( CREATE TABLE user_new ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL, birthday TEXT, email TEXT UNIQUE, created_at TEXT DEFAULT CURRENT_TIMESTAMP ) ); // 2. 数据迁移 await db.executeSql( INSERT INTO user_new (id, name, birthday, email, created_at) SELECT id, name, age, email, created_at FROM user ); // 3. 删除旧表 await db.executeSql(DROP TABLE user); // 4. 重命名新表 await db.executeSql(ALTER TABLE user_new RENAME TO user); await db.executeSql(COMMIT);这套建新表-搬数据-删旧表-改名的流程是标准的表结构重构方案。事务包裹让整个过程具备原子性中途任何一步失败都无法影响原表数据。要注意的是数据量大时这个操作会比较耗时建议放在应用启动后的后台任务里执行避免阻塞主流程。5.3 从数据库到业务层游标结果的映射实践数据库查询返回的是ResultSet但业务层不希望直接操作这种游标对象。我在项目里习惯封装一个通用映射函数把ResultSet转成业务对象数组function resultSetToArrayT(resultSet: relationalStore.ResultSet, mapper: (rs: relationalStore.ResultSet) T): T[] { const list: T[] []; try { while (resultSet.goToNextRow()) { list.push(mapper(resultSet)); } } finally { resultSet.close(); } return list; } // 使用示例 const users resultSetToArray(resultSet, (rs) ({ id: rs.getLong(rs.getColumnIndex(id)), name: rs.getString(rs.getColumnIndex(name)), email: rs.getString(rs.getColumnIndex(email)) }));这样每次查询的ResultSet都在结束时被可靠关闭业务层拿到的只是干净的数据数组。6. 跨进程与并发场景多端多线程操作数据库的避坑指南关系型数据库在HarmonyOS上不仅是单进程内使用在跨进程比如ArkTS接口服务扩展配合或者多线程并发场景下容易遇到数据库被锁写入竞争性能下降之类的问题。这一节把我在实际联调中的经验和排查思路做一个完整梳理。6.1 多页面、多线程同时读写时的冲突处理HarmonyOS应用内部可能同时有多个任务在访问同一个RdbStore主页面在查询列表后台线程在同步数据服务扩展在写入日志。关系型数据库内部虽然有锁机制但多个写操作并发时部分时机可能抛出database is locked的错误。我在项目中采用了一个简单有效的策略所有数据库操作统一走数据访问层Repository数据访问层内部维护一个串行队列。不管是查询还是写入都丢到同一个队列中执行从源头避免并发访问冲突import { BusinessError } from kit.BasicServicesKit; class UserRepository { private store: relationalStore.RdbStore; private taskQueue: Promisevoid Promise.resolve(); constructor(store: relationalStore.RdbStore) { this.store store; } private enqueueT(task: () PromiseT): PromiseT { const result this.taskQueue.then(task); this.taskQueue result.then(() undefined, () undefined); return result; } async insertUser(name: string, age: number): Promisenumber { return this.enqueue(async () { const values: relationalStore.ValuesBucket { name: name, age: age }; return await this.store.insert(user, values); }); } async queryUsers(): PromiseArray{ id: number; name: string } { return this.enqueue(async () { const predicates new relationalStore.RdbPredicates(user); const resultSet await this.store.query(predicates, [id, name]); return resultSetToArray(resultSet, (rs) ({ id: rs.getLong(rs.getColumnIndex(id)), name: rs.getString(rs.getColumnIndex(name)) })); }); } }串行队列牺牲了一点并发度但换来了极强的稳定性。查询本身是并发安全的但入口统一后就可以在队列里做多写合并、缓存复用等优化收益远大于损失。6.2 连接池与单线程访问模型HarmonyOS的RdbStore对象在单进程内是单例复用的官方不建议为每个页面都创建一个新连接那样既浪费资源又容易导致锁竞争。数据库文件的连接数有限多次getRdbStore会拿到不同实例反而增加了出问题的概率。我统一采用全局唯一RdbManager的模式应用启动时获取一次RdbStore存为全局单例所有数据访问都从这个实例走。这样做还有另一个好处——后续要接分布式能力或做数据加密时只需要在初始化配置里调整业务层完全无感。6.3 大批量数据写入的性能对比与优化手段如果一次性要插入几百上千条数据最直接的做法是循环insert但实测来看逐条insert几千条数据可能需要数秒到十几秒不等。关系型数据库事务的提交开销非常高合并在一个事务里能显著加速写入方式1000条耗时实测参考说明逐条insert不开事务3-10秒以上每条都触发一次完整的写事务单事务内批量insert1秒以内只提交一次事务日志落盘次数大幅减少批量ValuesBucket数组insert和单事务接近框架内部优化代码最简洁RdbStore提供了一个batchInsert方法支持一次性传入ValuesBucket数组const valuesBuckets: relationalStore.ValuesBucket[] []; for (const item of syncData) { valuesBuckets.push({ name: item.name, age: item.age }); } const insertedRows await store.batchInsert(user, valuesBuckets);批量插入虽然在事务内部执行但单条失败不会自动回滚整个批次所以批量数据在插入前要做必要的合法性校验。对于真正的关键数据我还是会选择手动beginTransaction 逐条insertcommit的组合这样能在出错时精确控制回滚粒度。7. 数据的后顾之忧备份、恢复与安全存储本地数据都存在应用沙箱里用户一旦卸载应用数据就全部没了。虽然HarmonyOS备份机制会为应用提供云端备份能力但对于关键业务数据开发者还是要主动设计备份和恢复方案。7.1 数据文件级备份方案最朴素但可靠的备份方式是直接拷贝数据库文件。RdbStore对应的数据库文件位于应用沙箱的数据库目录下文件名为创建时的name字段值。可以通过文件IO把数据库文件复制到应用自己的备份目录或通过分布式文件系统同步到其他设备。import { fileIo } from kit.CoreFileKit; import { common } from kit.AbilityKit; async function backupDatabase(context: common.Context): Promisevoid { const srcPath context.databaseDir /demo_store.db; const backupPath context.filesDir /backup_demo_store.db; const file fileIo.openSync(srcPath, fileIo.OpenMode.READ_ONLY); const out fileIo.openSync(backupPath, fileIo.OpenMode.READ_WRITE | fileIo.OpenMode.CREATE | fileIo.OpenMode.TRUNC); try { await fileIo.copyFile(file.fd, out.fd); } finally { fileIo.closeSync(file); fileIo.closeSync(out); } }注意备份时最好确认当前没有正在执行写事务。虽然文件拷贝在大多数情况下不会损坏数据但严格的备份应该在数据库空闲时进行或者先通过数据库自身的导出机制生成一致性的快照。7.2 数据库加密与隐私合规前面提到过StoreConfig里的encrypt参数。如果应用采集了用户隐私数据身份证号、位置信息、通讯录等强烈建议开启。加密库的密钥由系统管理开发者不需要在自己的业务代码里维护密钥这比自己在SQL外面套一层AES要安全得多。开发调试阶段如果开启了加密通过命令行工具直接查看数据库文件内容会看到密文不方便调试。可以在debug包中关闭加密release包中开启但要确保这两种模式的数据迁移逻辑一致。7.3 数据生命周期与清理策略本地数据库如果只增不删最终会撑爆用户存储空间。我在数据访问层里预留了清理接口按照业务类型设定保留周期历史日志保留30天操作记录保留90天核心业务数据永久保留但定期归档冷数据清理动作一般在应用冷启动或进入后台时执行使用Predicates按时间字段批量删除配合事务提交避免删除操作阻塞正常读写。8. 实测阶段最容易翻车的四个场景与排除思路最后分享几个我在真实项目里频繁遇到的翻车场景这些问题光看文档不一定能意识到但99%的开发者迟早会撞上。8.1 No such table建表SQL没执行成功新手第一个坑往往是这个报错。原因是建表SQL是异步执行的getRdbStore返回后立刻去查表但CREATE TABLE还没跑完。解决办法是把建表逻辑放在getRdbStore回调里或者用async/await确保初始化完成后再开放业务入口。8.2 Database corrupted进程被杀导致的数据库损坏异常断电或杀进程可能让数据库文件处于不一致状态。RdbStore内置了WAL日志机制正常情况下能自动恢复。但如果观察到启动时频繁报corrupted错误建议在初始化前先尝试打开备份库或执行完整性校验const checkResult await store.executeSql(PRAGMA integrity_check);如果integrity_check返回的不是ok说明数据库文件已经损坏此时应走备份恢复流程。8.3 ResultSet closed游标提前释放在遍历ResultSet时如果中途不小心调用了close后续goToNextRow就会抛错。这种问题通常出现在提前return或回调中异步操作的场景。把所有游标读取逻辑收敛到一个函数内集中处理close能最大程度避免这类错误。8.4 时间字段的时区陷阱数据库存时间戳时如果直接用DATE(now)或CURRENT_TIMESTAMP取到的是UTC时间和本地时间可能差8个小时。用户看到下单时间不对往往就是这个原因。我的处理方案是应用层组装时间字符串时统一用本地时区格式化存入数据库的字段一律用TEXT类型存ISO8601格式查询时再用日期函数解析。避免在SQL里做时区计算逻辑会清晰很多。最后再分享一点个人经验关系型数据库在HarmonyOS应用里承担的是数据地基的角色地基打得稳上层业务怎么盖都不怕。很多性能和稳定性的问题追根溯源都不是SQL写错了而是初始化时序、连接复用、事务粒度这些数据库周边的问题。我的建议是先把初始化单例化、操作串行化、游标集中关闭这三件事做扎实再去抠SQL性能优化方向一定不会错。数据层的代码值得花时间打磨它直接影响用户每一次启动应用时的体验。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
