做鸿蒙应用开发本地数据存储是绕不开的一环尤其是关系型数据库。不管是记账App的账单流水、商城App的商品列表还是资讯App的历史记录只要涉及“从表里捞数据”就一定得构建查询条件。鸿蒙的数据库查询条件体系里greaterThan 是出镜率很高的一个方法字面意思就是“大于某个值”。我实际用下来发现这个方法本身确实简单几句话就能调用但它在类型匹配、组合条件、索引设计这些环节里藏了不少细节处理不好轻则查询结果不对重则在数据量上来之后直接把页面卡到没法用。这篇内容不打算只贴一个 API 的用法就完事。我会从鸿蒙关系型数据库RelationalStore的查询条件设计讲起把 greaterThan 的完整使用链路、真实业务场景里的组合查询、以及我在真机调试时踩过的几个坑一起梳理出来顺便把性能优化那部分也聊透。无论你是刚开始接触鸿蒙开发的新手还是已经写过一段时间 SQLite、Room 这类数据库的开发者这篇内容都可以直接照着用。1. 鸿蒙数据库查询条件设计逻辑梳理1.1 为什么是用 RdbPredicates 而不是直接拼 SQL先说一个我在刚开始接触鸿蒙时产生的疑问Android 那边查数据库可以手写 SQL 字符串鸿蒙为什么给了一套 RdbPredicates 这样的对象来构建查询条件直接拼接 SELECT * FROM bill WHERE amount 100 不是更直观吗鸿蒙这么设计核心考虑是安全和跨设备一致性。手拼 SQL 字符串最大的风险是注入其次是拼接过程中很容易漏空格、弄错引号尤其是在字段名和值都是动态传入的场景下。RdbPredicates 通过方法调用的方式传参字段名和取值被框架层规范封装拼装 SQL 的过程由底层完成相当于把所有“拼字符串容易出错”的地方替你挡住了。另一个原因是鸿蒙的分布式能力。同一个查询条件在本地设备上执行和在多设备协同场景下执行底层的查询引擎可能不一样但 RdbPredicates 提供的是统一抽象层。你在代码里写的这一组条件不需要关心最终落到的数据库文件在哪个设备上也不需要关心系统用什么方式去执行它天然适配了鸿蒙“一次开发多端部署”的理念。我自己做项目的时候也验证过使用 RdbPredicates 构建一堆复杂条件之后代码可读性明显比堆一长串 SQL 字符串要好。尤其是条件数量多、逻辑嵌套深的时候RdbPredicates 是链式调用每一步都在语义上是自解释的。团队其他人接手代码时理解成本会低很多。1.2 greaterThan 在查询条件体系里的角色鸿蒙的 RdbPredicates 提供了非常完整的一套条件方法包括 equalTo、notEqualTo、greaterThan、lessThan、greaterThanOrEqualTo、lessThanOrEqualTo、between、in、like、isNull、isNotNull 等等。这套方法的命名基本和 SQL 的关键字一一对应如果你之前接触过 SQL 或者任何一个 ORM 框架看到方法名就能猜到它的执行语义。greaterThan 对应的是 SQL 里的 比较运算符属于“范围条件”这一类。它的典型业务场景就是筛选数值或时间比如查金额大于 100 的订单、查评分高于 4.5 的商品、查发布时间晚于某个时间点的文章。和 between 这种“两端闭合区间”的条件相比greaterThan 表达的是开区间也就是说结果集不包含等于给定值的记录这一点在写业务代码时一定要记得。我在实际项目里通常会把 greaterThan 用在高频筛选场景中。比如记账类应用首页要展示“本月支出超过 500 元的分类”或者消息列表页要做“拉取今天之后的新消息”这种增量查询这些都是它的典型用武之地。方法本身的签名非常直白greaterThan(field: string, value: ValueType): RdbPredicatesfield 是表的字段名value 是你要比较的那个边界值。返回值还是 RdbPredicates 本身所以你可以连续调用多个条件形成一个“条件组”。2. greaterThan 的核心用法与代码落地2.1 基础调用字段名与值类型的匹配规则greaterThan 的第二个参数 value 的类型是 ValueType实际开发中我传过的类型包括 number、string、boolean偶尔也会传 Uint8Array 这类二进制数据。但大数据量实测下来最常见的还是 number 类型的数值和长整型时间戳。这里有个非常容易踩的坑字段类型和传入值类型不匹配。比如你在建表时把 amount 字段设计成了 REAL浮点数结果在构建查询条件时给 greaterThan 传了个字符串 100底层在比较时不会帮你做类型转换最终查询结果可能不符合预期甚至在某些极端数据下会直接查询失败。所以每次写 greaterThan 之前我建议你顺手做一次“字段类型自查”。建表后打开数据库确认字段类型再对照代码里的传参类型这是成本最低但最有效的防错手段。我自己通常会在实体类或者数据访问层里定义一个常量表把每个字段名和它的数据类型集中维护查询时直接从常量表取值从机制上避免这类问题。来看一段我在真机验证过的基础示例。假设有一张账单表import { relationalStore } from kit.ArkData; // 创建数据库配置并获取 RdbStore const config: relationalStore.StoreConfig { name: bill_demo.db, securityLevel: relationalStore.SecurityLevel.S1, }; const store await relationalStore.getRdbStore(getContext(this), config); // 建表金额字段使用 REAL 类型 await store.executeSql( CREATE TABLE IF NOT EXISTS bill ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL, amount REAL NOT NULL, create_time INTEGER NOT NULL) );要查询所有金额大于 100 的账单查询条件这样构建// 构建查询条件金额大于 100注意字段名对应建表语句值为 number 类型 let predicates new relationalStore.RdbPredicates(bill); predicates.greaterThan(amount, 100); // 指定返回列避免一次性把所有字段都捞出来 let resultSet await store.query(predicates, [id, name, amount, create_time]);这里我刻意把返回列限定为四个业务字段而不是直接传空数组代表“查询全部”。这样做有两个好处一是减少网络和内存开销尤其是表字段多的时候效果明显二是让查询语义更明确别人看代码的时候一眼就知道后面要用哪些字段。我的习惯是凡是正式项目中的查询都显式声明返回列不为了一时省事而放弃可维护性。2.2 完整查询链路从构建条件到安全读取结果构建完 predicates 只是第一步后面的结果集处理才是容易出错的地方。很多新手在查询完拿到 ResultSet 之后不知道该按什么顺序取数或者用完忘记关闭结果集导致应用出现连接泄漏。这里我把完整流程写出来你可以当模板用。// 查询并遍历结果 if (resultSet.goToFirstRow()) { do { // 根据列名获取列索引 let idIndex resultSet.getColumnIndex(id); let nameIndex resultSet.getColumnIndex(name); let amountIndex resultSet.getColumnIndex(amount); let timeIndex resultSet.getColumnIndex(create_time); // 按列类型读取数据 let id resultSet.getLong(idIndex); let name resultSet.getString(nameIndex); let amount resultSet.getDouble(amountIndex); let createTime resultSet.getLong(timeIndex); console.info(账单${name}金额${amount}时间${createTime}); } while (resultSet.goToNextRow()); } // 无论是否查询到数据都必须关闭结果集 resultSet.close();这里补充一个我在项目里总结的经验如果只是要快速判断“有没有符合条件的数据”不一定要遍历整个结果集可以先调用goToFirstRow()判断返回值。如果返回 true 说明至少有一条数据之后如果想读取具体内容再继续往后遍历也行。如果查询只是为了做计数统计鸿蒙还提供了专门的store.count(predicates)方法直接返回数量性能和语义都比自己遍历结果集要好。另外resultSet 的 close 我一般放在 finally 块里或者用一个统一的工具方法封装查询逻辑避免因为业务代码中途抛异常导致结果集不能被释放。真机长时间运行后出现“too many open files”这类问题很大概率就是结果集或数据库连接没有被正确关闭。3. 实战场景按金额和时间筛选的记账查询3.1 记账场景拆解建表、造数、构建 greaterThan 条件单独讲 API 很容易让人觉得“懂了但不会用”所以我说一个自己实际做过的记账 App 场景把 greaterThan 放到完整业务里看。假设页面需要展示“金额大于 100 元的餐饮类账单”并且按时间倒序排列二三十条一页分页加载。这个需求拆解下来其实涉及三个查询维度金额筛选、分类筛选、时间排序和分页。一个 RdbPredicates 对象就能把这些全部表达出来。先准备表和数据。上面已经建了 bill 表这里再补一个分类筛选的需求给表增加一个 category 字段await store.executeSql( CREATE TABLE IF NOT EXISTS bill ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL, amount REAL NOT NULL, category TEXT NOT NULL, create_time INTEGER NOT NULL) ); // 插入几条测试数据 const insertValues [ { name: 早餐, amount: 12.5, category: 餐饮, create_time: Date.now() - 86400000 }, { name: 午餐, amount: 98, category: 餐饮, create_time: Date.now() - 43200000 }, { name: 周末聚餐, amount: 356, category: 餐饮, create_time: Date.now() - 10800000 }, { name: 超市采购, amount: 230, category: 日用, create_time: Date.now() - 7200000 }, ]; for (let item of insertValues) { let values new relationalStore.ValuesBucket(); values[name] item.name; values[amount] item.amount; values[category] item.category; values[create_time] item.create_time; await store.insert(bill, values); }接下来是核心查询部分金额大于 100、分类等于“餐饮”、按照时间倒序、限制返回 20 条。代码写出来是这样let predicates new relationalStore.RdbPredicates(bill); // 金额大于 100刚好覆盖 greaterThan predicates.greaterThan(amount, 100); // 追加分类等于餐饮的条件多个条件默认是 AND 关系 predicates.equalTo(category, 餐饮); // 时间倒序新的在前面 predicates.orderByDesc(create_time); // 分页每页最多 20 条偏移 0 表示从第一条开始 predicates.limitAs(20, 0); let resultSet await store.query(predicates, [id, name, amount, category, create_time]);这段代码跑出来的结果语义上等同于下面的 SQLSELECT id, name, amount, category, create_time FROM bill WHERE amount 100 AND category 餐饮 ORDER BY create_time DESC LIMIT 20 OFFSET 0;我把这个等价 SQL 写在文档注释里交给过团队的新人他看完立刻就理解了 RdbPredicates 的语义模型。这个方法我一直沿用比反复口头解释效率高得多。3.2 组合条件、排序和分页的联动效果如果你之前接触过其它 ORM 框架可能会直觉认为链式调用多个条件时条件之间是 AND 连接。鸿蒙 RdbPredicates 确实如此。每次调用一个条件方法追加的都是 AND 关系。所以上面的代码里greaterThan 和 equalTo 组合成了“金额大于 100 且分类等于餐饮”。但有一个细节需要特别留意一旦你想表达 OR 关系就不能靠链式调用硬写。比如我要查“金额大于 500 或者分类等于餐饮”的账单如果代码如下let predicates new relationalStore.RdbPredicates(bill); predicates.greaterThan(amount, 500); predicates.equalTo(category, 餐饮);这表达的是 AND不是 OR。正确写法是显式调用 or()let predicates new relationalStore.RdbPredicates(bill); predicates.greaterThan(amount, 500) .or() .equalTo(category, 餐饮);等价 SQL 是SELECT * FROM bill WHERE amount 500 OR category 餐饮;这里再往前推一步如果条件组合里既有 AND 又有 OR比如“金额大于 500 或者分类等于餐饮且金额大于 100”那就得用 beginWrap 和 endWrap 来控制优先级let predicates new relationalStore.RdbPredicates(bill); predicates.greaterThan(amount, 500) .or() .beginWrap() .equalTo(category, 餐饮) .and() .greaterThan(amount, 100) .endWrap();这个组合条件对应的 SQL 就是SELECT * FROM bill WHERE amount 500 OR (category 餐饮 AND amount 100);不要小看 beginWrap 和 endWrap复杂报表页里这种逻辑非常常见。我在工单系统里头做过一个高级筛选十几个条件混合排列组合如果没有 beginWrap 和 endWrap 做优先级控制写出来的条件会在运行时被组合成完全无法理解的 WHERE 子句排查问题的时候会怀疑人生。分页方面limitAs 的第二个参数是偏移量offset分页公式可以记成limitAs(每页条数, 当前页码 * 每页条数)。我用这个公式处理过万级数据量的账单列表滚动加载没有出现重复或跳条的情况。需要注意分页查询和排序一定要配合使用。如果不排序数据库返回结果的顺序在底层是不保证稳定的分页翻到第二页时很容易和第一页的数据错位。所以在使用 limitAs 之前我总会先确认条件里至少有一个 orderBy 排序。4. 使用 greaterThan 时绕不开的实战坑点4.1 类型不匹配导致的条件失效这一节我想把最常见的坑单独拉出来说因为它的隐蔽性非常强。假设账单表里的 create_time 字段用的是 INTEGER 类型存的是毫秒时间戳。你构建查询条件时如果不小心把边界值传成了字符串let predicates new relationalStore.RdbPredicates(bill); // 错误的示例值传成了字符串 predicates.greaterThan(create_time, 2024-01-01 00:00:00);底层在比较 INTEGER 字段和字符串时不会像你想的那样把时间字符串转成时间戳再比查询结果大概率是空。正确做法是先把边界时间转成时间戳let startTime new Date(2024-01-01T00:00:00).getTime(); let predicates new relationalStore.RdbPredicates(bill); predicates.greaterThan(create_time, startTime);这种问题不会直接崩但会让你纠结“为什么查不出数据”排查半天都找不到原因。我的做法是在数据访问层写一个统一的时间参数转换方法所有和时间相关的查询都走同一个入口从源头上避免传错。4.2 空值条件与等于条件的误用还有一个我早期经常踩的坑想查某个字段“不为空”或者“为空”结果下意识用了 notEqualTo 或 equalTo把第二个参数传成 null。实际上鸿蒙的 equalTo 和 notEqualTo 在字段值为 NULL 的时候表现并不像你预期的那样。比如你想查备注不为空的账单写成predicates.notEqualTo(remark, null)这条语句不会筛选出“remark 有值”的记录而是会把所有 remark 为空的记录也排除掉最终结果可能比预期少很多。正确写法是使用 isNotNull 和 isNull// 查询备注不为空的账单 predicates.isNotNull(remark); // 查询备注为空的账单 predicates.isNull(remark);这个坑我在 SQL 里也有印象因为 SQL 中 NULL 比较的语义是特殊的任何和 NULL 做等值或不等值比较的结果都是 UNKNOWN。RdbPredicates 把 SQL 的这套行为也带了过来。我吃了一次亏之后每次做空值相关筛选都会先停下来确认一下到底该用哪个方法而不是让“差不多”的直觉替你决定。4.3 结果集处理与资源释放的规范动作ResultSet 不关闭的问题我在前面提了一句这里想展开说清楚它为什么值得你花心思。在一次误操作中我在一个循环里连续执行了大量查询但没有及时调用 resultSet.close()日志里开始报数据库连接相关的错误随后同一页面里的其它查询也陆续受影响。重启应用后问题消失但过一段时间又复发。这种偶发问题最影响开发效率。后来我把所有查询改成统一模板无论查询是否成功、是否遍历完结果集最终都执行 close。在 ArkTS 里我习惯这样处理try { // 遍历结果集 } finally { // 确保执行 if (resultSet) { resultSet.close(); } }这个习惯帮我避免了很多隐性问题。特别是页面销毁时如果你在异步查询中使用了页面上下文还要注意查询结束后及时断开数据回调的引用防止页面无法被系统回收。结果集、数据库连接、异步任务这三样资源在鸿蒙开发里同样遵循“谁打开谁关闭”的原则。5. 性能优化与索引设计5.1 为什么加了 greaterThan 之后查询突然变慢需求初期数据量小一切查询都快如闪电。但数据量增长到几万、几十万条之后如果某个带 greaterThan 的查询变慢了十有八九是没走索引。范围查询 greaterThan 的本质是让数据库在索引树上定位到边界值然后向后扫描。如果没有索引数据库只能把整张表从头到尾过滤一遍这种操作叫全表扫描。全表扫描在少量数据下没感觉但量级上来之后耗时和表行数成正比增长。举个例子账单表如果有 20 万行数据不带索引的greaterThan(create_time, startTime)可能要遍历全部 20 万行如果 create_time 上有索引数据库可以直接定位到 startTime 所在的位置只扫描之后的那部分数据。对于几十万体量的本地数据库来说这条优化能不能带来数量级的提升。5.2 给筛选字段加索引的实操鸿蒙的 RdbStore 执行 SQL 的能力和标准 SQLite 基本一致所以建索引可以直接用 executeSqlawait store.executeSql(CREATE INDEX IF NOT EXISTS idx_bill_amount ON bill(amount)); await store.executeSql(CREATE INDEX IF NOT EXISTS idx_bill_create_time ON bill(create_time));我给几个使用建议单列范围条件直接在对应字段上建索引。如果查询条件经常是“金额大于某个值且时间在某个范围”可以考虑建联合索引比如CREATE INDEX idx_bill_time_amount ON bill(create_time, amount)。索引不是越多越好。每次 insert 或 update数据库都要同步维护索引树索引太多会让写入变慢。我通常只给高频查询字段建索引低频业务字段不加。可以通过EXPLAIN QUERY PLAN查看查询计划确认条件是否真正用上了索引。关于索引方向的细节对于范围查询数据库会自动选择合适的扫描方向大多数场景不需要你单独指定但联合索引里字段顺序有说法。我的经验是把等值条件的字段放在前面范围条件的字段放在后面这样索引的利用率通常是最高的。比如查询“分类等于餐饮且金额大于 100”联合索引设计成(category, amount)比(amount, category)更合适。5.3 批量操作与查询的连带优化除了索引还有两个优化点和 greaterThan 有关。第一个是批量删除或更新。业务里做“删除一个月前的过期数据”时条件自然写成greaterThan或lessThan但不要在一个事务里逐条 delete。直接调用 store.delete(predicates)底层一条 SQL 就能完成性能远高于循环删除。同理批量更新时也是把条件传给 store.update让数据库统一处理。第二个是查询列的精简。我发现不少新人喜欢在 select 里返回所有列哪怕业务只需要 id。对数据库来说返回列越多IO 开销越大尤其在记录数多的场景里更明显。所以我的查询习惯是只返回本次业务真正用到的字段像上面例子中我始终在 query 方法里显式传入列名数组。6. 写在最后的经验说了这么多其实 greaterThan 就是一个“大于”条件但它背后连着的类型匹配、条件组合、索引设计才是真正决定项目质量的部分。我在真机上调过很多次查询问题回头看不外乎是这几种情况值类型传错、条件关系搞混、结果集没关闭、查询没走索引。把这几条规范刻在习惯里能省下大量排查时间。如果你正在做鸿蒙应用里的数据展示、筛选、统计功能我建议你从今天的最小项目里就开始规范地使用 RdbPredicates每次构建条件先想清楚字段类型组合条件时想清楚 AND 和 OR 的边界涉及大数据量时把索引提前设计进去。这套工作方式越早建立后面越轻松。最后再分享一个小技巧数据库版本升级时如果业务查询条件发生了变化除了要处理表结构的迁移也别忘了同步检查旧的字段索引是否还需要保留。我遇到过发布新版本后查询性能下降的情况最后发现是旧索引一直没有清理导致写入和更新被拖慢。数据库开发里好的性能从来不是只靠一条 SQL 写得好而是整套设计习惯相互作用的结果。 
长河君 · 2026/9/11 6:43:11 · 阅读 1.2k 鸿蒙关系型数据库查询：greaterThan实践与性能优化
做鸿蒙应用开发本地数据存储是绕不开的一环尤其是关系型数据库。不管是记账App的账单流水、商城App的商品列表还是资讯App的历史记录只要涉及“从表里捞数据”就一定得构建查询条件。鸿蒙的数据库查询条件体系里greaterThan 是出镜率很高的一个方法字面意思就是“大于某个值”。我实际用下来发现这个方法本身确实简单几句话就能调用但它在类型匹配、组合条件、索引设计这些环节里藏了不少细节处理不好轻则查询结果不对重则在数据量上来之后直接把页面卡到没法用。这篇内容不打算只贴一个 API 的用法就完事。我会从鸿蒙关系型数据库RelationalStore的查询条件设计讲起把 greaterThan 的完整使用链路、真实业务场景里的组合查询、以及我在真机调试时踩过的几个坑一起梳理出来顺便把性能优化那部分也聊透。无论你是刚开始接触鸿蒙开发的新手还是已经写过一段时间 SQLite、Room 这类数据库的开发者这篇内容都可以直接照着用。1. 鸿蒙数据库查询条件设计逻辑梳理1.1 为什么是用 RdbPredicates 而不是直接拼 SQL先说一个我在刚开始接触鸿蒙时产生的疑问Android 那边查数据库可以手写 SQL 字符串鸿蒙为什么给了一套 RdbPredicates 这样的对象来构建查询条件直接拼接 SELECT * FROM bill WHERE amount 100 不是更直观吗鸿蒙这么设计核心考虑是安全和跨设备一致性。手拼 SQL 字符串最大的风险是注入其次是拼接过程中很容易漏空格、弄错引号尤其是在字段名和值都是动态传入的场景下。RdbPredicates 通过方法调用的方式传参字段名和取值被框架层规范封装拼装 SQL 的过程由底层完成相当于把所有“拼字符串容易出错”的地方替你挡住了。另一个原因是鸿蒙的分布式能力。同一个查询条件在本地设备上执行和在多设备协同场景下执行底层的查询引擎可能不一样但 RdbPredicates 提供的是统一抽象层。你在代码里写的这一组条件不需要关心最终落到的数据库文件在哪个设备上也不需要关心系统用什么方式去执行它天然适配了鸿蒙“一次开发多端部署”的理念。我自己做项目的时候也验证过使用 RdbPredicates 构建一堆复杂条件之后代码可读性明显比堆一长串 SQL 字符串要好。尤其是条件数量多、逻辑嵌套深的时候RdbPredicates 是链式调用每一步都在语义上是自解释的。团队其他人接手代码时理解成本会低很多。1.2 greaterThan 在查询条件体系里的角色鸿蒙的 RdbPredicates 提供了非常完整的一套条件方法包括 equalTo、notEqualTo、greaterThan、lessThan、greaterThanOrEqualTo、lessThanOrEqualTo、between、in、like、isNull、isNotNull 等等。这套方法的命名基本和 SQL 的关键字一一对应如果你之前接触过 SQL 或者任何一个 ORM 框架看到方法名就能猜到它的执行语义。greaterThan 对应的是 SQL 里的 比较运算符属于“范围条件”这一类。它的典型业务场景就是筛选数值或时间比如查金额大于 100 的订单、查评分高于 4.5 的商品、查发布时间晚于某个时间点的文章。和 between 这种“两端闭合区间”的条件相比greaterThan 表达的是开区间也就是说结果集不包含等于给定值的记录这一点在写业务代码时一定要记得。我在实际项目里通常会把 greaterThan 用在高频筛选场景中。比如记账类应用首页要展示“本月支出超过 500 元的分类”或者消息列表页要做“拉取今天之后的新消息”这种增量查询这些都是它的典型用武之地。方法本身的签名非常直白greaterThan(field: string, value: ValueType): RdbPredicatesfield 是表的字段名value 是你要比较的那个边界值。返回值还是 RdbPredicates 本身所以你可以连续调用多个条件形成一个“条件组”。2. greaterThan 的核心用法与代码落地2.1 基础调用字段名与值类型的匹配规则greaterThan 的第二个参数 value 的类型是 ValueType实际开发中我传过的类型包括 number、string、boolean偶尔也会传 Uint8Array 这类二进制数据。但大数据量实测下来最常见的还是 number 类型的数值和长整型时间戳。这里有个非常容易踩的坑字段类型和传入值类型不匹配。比如你在建表时把 amount 字段设计成了 REAL浮点数结果在构建查询条件时给 greaterThan 传了个字符串 100底层在比较时不会帮你做类型转换最终查询结果可能不符合预期甚至在某些极端数据下会直接查询失败。所以每次写 greaterThan 之前我建议你顺手做一次“字段类型自查”。建表后打开数据库确认字段类型再对照代码里的传参类型这是成本最低但最有效的防错手段。我自己通常会在实体类或者数据访问层里定义一个常量表把每个字段名和它的数据类型集中维护查询时直接从常量表取值从机制上避免这类问题。来看一段我在真机验证过的基础示例。假设有一张账单表import { relationalStore } from kit.ArkData; // 创建数据库配置并获取 RdbStore const config: relationalStore.StoreConfig { name: bill_demo.db, securityLevel: relationalStore.SecurityLevel.S1, }; const store await relationalStore.getRdbStore(getContext(this), config); // 建表金额字段使用 REAL 类型 await store.executeSql( CREATE TABLE IF NOT EXISTS bill ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL, amount REAL NOT NULL, create_time INTEGER NOT NULL) );要查询所有金额大于 100 的账单查询条件这样构建// 构建查询条件金额大于 100注意字段名对应建表语句值为 number 类型 let predicates new relationalStore.RdbPredicates(bill); predicates.greaterThan(amount, 100); // 指定返回列避免一次性把所有字段都捞出来 let resultSet await store.query(predicates, [id, name, amount, create_time]);这里我刻意把返回列限定为四个业务字段而不是直接传空数组代表“查询全部”。这样做有两个好处一是减少网络和内存开销尤其是表字段多的时候效果明显二是让查询语义更明确别人看代码的时候一眼就知道后面要用哪些字段。我的习惯是凡是正式项目中的查询都显式声明返回列不为了一时省事而放弃可维护性。2.2 完整查询链路从构建条件到安全读取结果构建完 predicates 只是第一步后面的结果集处理才是容易出错的地方。很多新手在查询完拿到 ResultSet 之后不知道该按什么顺序取数或者用完忘记关闭结果集导致应用出现连接泄漏。这里我把完整流程写出来你可以当模板用。// 查询并遍历结果 if (resultSet.goToFirstRow()) { do { // 根据列名获取列索引 let idIndex resultSet.getColumnIndex(id); let nameIndex resultSet.getColumnIndex(name); let amountIndex resultSet.getColumnIndex(amount); let timeIndex resultSet.getColumnIndex(create_time); // 按列类型读取数据 let id resultSet.getLong(idIndex); let name resultSet.getString(nameIndex); let amount resultSet.getDouble(amountIndex); let createTime resultSet.getLong(timeIndex); console.info(账单${name}金额${amount}时间${createTime}); } while (resultSet.goToNextRow()); } // 无论是否查询到数据都必须关闭结果集 resultSet.close();这里补充一个我在项目里总结的经验如果只是要快速判断“有没有符合条件的数据”不一定要遍历整个结果集可以先调用goToFirstRow()判断返回值。如果返回 true 说明至少有一条数据之后如果想读取具体内容再继续往后遍历也行。如果查询只是为了做计数统计鸿蒙还提供了专门的store.count(predicates)方法直接返回数量性能和语义都比自己遍历结果集要好。另外resultSet 的 close 我一般放在 finally 块里或者用一个统一的工具方法封装查询逻辑避免因为业务代码中途抛异常导致结果集不能被释放。真机长时间运行后出现“too many open files”这类问题很大概率就是结果集或数据库连接没有被正确关闭。3. 实战场景按金额和时间筛选的记账查询3.1 记账场景拆解建表、造数、构建 greaterThan 条件单独讲 API 很容易让人觉得“懂了但不会用”所以我说一个自己实际做过的记账 App 场景把 greaterThan 放到完整业务里看。假设页面需要展示“金额大于 100 元的餐饮类账单”并且按时间倒序排列二三十条一页分页加载。这个需求拆解下来其实涉及三个查询维度金额筛选、分类筛选、时间排序和分页。一个 RdbPredicates 对象就能把这些全部表达出来。先准备表和数据。上面已经建了 bill 表这里再补一个分类筛选的需求给表增加一个 category 字段await store.executeSql( CREATE TABLE IF NOT EXISTS bill ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL, amount REAL NOT NULL, category TEXT NOT NULL, create_time INTEGER NOT NULL) ); // 插入几条测试数据 const insertValues [ { name: 早餐, amount: 12.5, category: 餐饮, create_time: Date.now() - 86400000 }, { name: 午餐, amount: 98, category: 餐饮, create_time: Date.now() - 43200000 }, { name: 周末聚餐, amount: 356, category: 餐饮, create_time: Date.now() - 10800000 }, { name: 超市采购, amount: 230, category: 日用, create_time: Date.now() - 7200000 }, ]; for (let item of insertValues) { let values new relationalStore.ValuesBucket(); values[name] item.name; values[amount] item.amount; values[category] item.category; values[create_time] item.create_time; await store.insert(bill, values); }接下来是核心查询部分金额大于 100、分类等于“餐饮”、按照时间倒序、限制返回 20 条。代码写出来是这样let predicates new relationalStore.RdbPredicates(bill); // 金额大于 100刚好覆盖 greaterThan predicates.greaterThan(amount, 100); // 追加分类等于餐饮的条件多个条件默认是 AND 关系 predicates.equalTo(category, 餐饮); // 时间倒序新的在前面 predicates.orderByDesc(create_time); // 分页每页最多 20 条偏移 0 表示从第一条开始 predicates.limitAs(20, 0); let resultSet await store.query(predicates, [id, name, amount, category, create_time]);这段代码跑出来的结果语义上等同于下面的 SQLSELECT id, name, amount, category, create_time FROM bill WHERE amount 100 AND category 餐饮 ORDER BY create_time DESC LIMIT 20 OFFSET 0;我把这个等价 SQL 写在文档注释里交给过团队的新人他看完立刻就理解了 RdbPredicates 的语义模型。这个方法我一直沿用比反复口头解释效率高得多。3.2 组合条件、排序和分页的联动效果如果你之前接触过其它 ORM 框架可能会直觉认为链式调用多个条件时条件之间是 AND 连接。鸿蒙 RdbPredicates 确实如此。每次调用一个条件方法追加的都是 AND 关系。所以上面的代码里greaterThan 和 equalTo 组合成了“金额大于 100 且分类等于餐饮”。但有一个细节需要特别留意一旦你想表达 OR 关系就不能靠链式调用硬写。比如我要查“金额大于 500 或者分类等于餐饮”的账单如果代码如下let predicates new relationalStore.RdbPredicates(bill); predicates.greaterThan(amount, 500); predicates.equalTo(category, 餐饮);这表达的是 AND不是 OR。正确写法是显式调用 or()let predicates new relationalStore.RdbPredicates(bill); predicates.greaterThan(amount, 500) .or() .equalTo(category, 餐饮);等价 SQL 是SELECT * FROM bill WHERE amount 500 OR category 餐饮;这里再往前推一步如果条件组合里既有 AND 又有 OR比如“金额大于 500 或者分类等于餐饮且金额大于 100”那就得用 beginWrap 和 endWrap 来控制优先级let predicates new relationalStore.RdbPredicates(bill); predicates.greaterThan(amount, 500) .or() .beginWrap() .equalTo(category, 餐饮) .and() .greaterThan(amount, 100) .endWrap();这个组合条件对应的 SQL 就是SELECT * FROM bill WHERE amount 500 OR (category 餐饮 AND amount 100);不要小看 beginWrap 和 endWrap复杂报表页里这种逻辑非常常见。我在工单系统里头做过一个高级筛选十几个条件混合排列组合如果没有 beginWrap 和 endWrap 做优先级控制写出来的条件会在运行时被组合成完全无法理解的 WHERE 子句排查问题的时候会怀疑人生。分页方面limitAs 的第二个参数是偏移量offset分页公式可以记成limitAs(每页条数, 当前页码 * 每页条数)。我用这个公式处理过万级数据量的账单列表滚动加载没有出现重复或跳条的情况。需要注意分页查询和排序一定要配合使用。如果不排序数据库返回结果的顺序在底层是不保证稳定的分页翻到第二页时很容易和第一页的数据错位。所以在使用 limitAs 之前我总会先确认条件里至少有一个 orderBy 排序。4. 使用 greaterThan 时绕不开的实战坑点4.1 类型不匹配导致的条件失效这一节我想把最常见的坑单独拉出来说因为它的隐蔽性非常强。假设账单表里的 create_time 字段用的是 INTEGER 类型存的是毫秒时间戳。你构建查询条件时如果不小心把边界值传成了字符串let predicates new relationalStore.RdbPredicates(bill); // 错误的示例值传成了字符串 predicates.greaterThan(create_time, 2024-01-01 00:00:00);底层在比较 INTEGER 字段和字符串时不会像你想的那样把时间字符串转成时间戳再比查询结果大概率是空。正确做法是先把边界时间转成时间戳let startTime new Date(2024-01-01T00:00:00).getTime(); let predicates new relationalStore.RdbPredicates(bill); predicates.greaterThan(create_time, startTime);这种问题不会直接崩但会让你纠结“为什么查不出数据”排查半天都找不到原因。我的做法是在数据访问层写一个统一的时间参数转换方法所有和时间相关的查询都走同一个入口从源头上避免传错。4.2 空值条件与等于条件的误用还有一个我早期经常踩的坑想查某个字段“不为空”或者“为空”结果下意识用了 notEqualTo 或 equalTo把第二个参数传成 null。实际上鸿蒙的 equalTo 和 notEqualTo 在字段值为 NULL 的时候表现并不像你预期的那样。比如你想查备注不为空的账单写成predicates.notEqualTo(remark, null)这条语句不会筛选出“remark 有值”的记录而是会把所有 remark 为空的记录也排除掉最终结果可能比预期少很多。正确写法是使用 isNotNull 和 isNull// 查询备注不为空的账单 predicates.isNotNull(remark); // 查询备注为空的账单 predicates.isNull(remark);这个坑我在 SQL 里也有印象因为 SQL 中 NULL 比较的语义是特殊的任何和 NULL 做等值或不等值比较的结果都是 UNKNOWN。RdbPredicates 把 SQL 的这套行为也带了过来。我吃了一次亏之后每次做空值相关筛选都会先停下来确认一下到底该用哪个方法而不是让“差不多”的直觉替你决定。4.3 结果集处理与资源释放的规范动作ResultSet 不关闭的问题我在前面提了一句这里想展开说清楚它为什么值得你花心思。在一次误操作中我在一个循环里连续执行了大量查询但没有及时调用 resultSet.close()日志里开始报数据库连接相关的错误随后同一页面里的其它查询也陆续受影响。重启应用后问题消失但过一段时间又复发。这种偶发问题最影响开发效率。后来我把所有查询改成统一模板无论查询是否成功、是否遍历完结果集最终都执行 close。在 ArkTS 里我习惯这样处理try { // 遍历结果集 } finally { // 确保执行 if (resultSet) { resultSet.close(); } }这个习惯帮我避免了很多隐性问题。特别是页面销毁时如果你在异步查询中使用了页面上下文还要注意查询结束后及时断开数据回调的引用防止页面无法被系统回收。结果集、数据库连接、异步任务这三样资源在鸿蒙开发里同样遵循“谁打开谁关闭”的原则。5. 性能优化与索引设计5.1 为什么加了 greaterThan 之后查询突然变慢需求初期数据量小一切查询都快如闪电。但数据量增长到几万、几十万条之后如果某个带 greaterThan 的查询变慢了十有八九是没走索引。范围查询 greaterThan 的本质是让数据库在索引树上定位到边界值然后向后扫描。如果没有索引数据库只能把整张表从头到尾过滤一遍这种操作叫全表扫描。全表扫描在少量数据下没感觉但量级上来之后耗时和表行数成正比增长。举个例子账单表如果有 20 万行数据不带索引的greaterThan(create_time, startTime)可能要遍历全部 20 万行如果 create_time 上有索引数据库可以直接定位到 startTime 所在的位置只扫描之后的那部分数据。对于几十万体量的本地数据库来说这条优化能不能带来数量级的提升。5.2 给筛选字段加索引的实操鸿蒙的 RdbStore 执行 SQL 的能力和标准 SQLite 基本一致所以建索引可以直接用 executeSqlawait store.executeSql(CREATE INDEX IF NOT EXISTS idx_bill_amount ON bill(amount)); await store.executeSql(CREATE INDEX IF NOT EXISTS idx_bill_create_time ON bill(create_time));我给几个使用建议单列范围条件直接在对应字段上建索引。如果查询条件经常是“金额大于某个值且时间在某个范围”可以考虑建联合索引比如CREATE INDEX idx_bill_time_amount ON bill(create_time, amount)。索引不是越多越好。每次 insert 或 update数据库都要同步维护索引树索引太多会让写入变慢。我通常只给高频查询字段建索引低频业务字段不加。可以通过EXPLAIN QUERY PLAN查看查询计划确认条件是否真正用上了索引。关于索引方向的细节对于范围查询数据库会自动选择合适的扫描方向大多数场景不需要你单独指定但联合索引里字段顺序有说法。我的经验是把等值条件的字段放在前面范围条件的字段放在后面这样索引的利用率通常是最高的。比如查询“分类等于餐饮且金额大于 100”联合索引设计成(category, amount)比(amount, category)更合适。5.3 批量操作与查询的连带优化除了索引还有两个优化点和 greaterThan 有关。第一个是批量删除或更新。业务里做“删除一个月前的过期数据”时条件自然写成greaterThan或lessThan但不要在一个事务里逐条 delete。直接调用 store.delete(predicates)底层一条 SQL 就能完成性能远高于循环删除。同理批量更新时也是把条件传给 store.update让数据库统一处理。第二个是查询列的精简。我发现不少新人喜欢在 select 里返回所有列哪怕业务只需要 id。对数据库来说返回列越多IO 开销越大尤其在记录数多的场景里更明显。所以我的查询习惯是只返回本次业务真正用到的字段像上面例子中我始终在 query 方法里显式传入列名数组。6. 写在最后的经验说了这么多其实 greaterThan 就是一个“大于”条件但它背后连着的类型匹配、条件组合、索引设计才是真正决定项目质量的部分。我在真机上调过很多次查询问题回头看不外乎是这几种情况值类型传错、条件关系搞混、结果集没关闭、查询没走索引。把这几条规范刻在习惯里能省下大量排查时间。如果你正在做鸿蒙应用里的数据展示、筛选、统计功能我建议你从今天的最小项目里就开始规范地使用 RdbPredicates每次构建条件先想清楚字段类型组合条件时想清楚 AND 和 OR 的边界涉及大数据量时把索引提前设计进去。这套工作方式越早建立后面越轻松。最后再分享一个小技巧数据库版本升级时如果业务查询条件发生了变化除了要处理表结构的迁移也别忘了同步检查旧的字段索引是否还需要保留。我遇到过发布新版本后查询性能下降的情况最后发现是旧索引一直没有清理导致写入和更新被拖慢。数据库开发里好的性能从来不是只靠一条 SQL 写得好而是整套设计习惯相互作用的结果。