企业官网建设流程全解析

做鸿蒙应用开发，本地数据存储是绕不开的一环，尤其是关系型数据库。不管是记账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): RdbPredicates

field 是表的字段名，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']);

这段代码跑出来的结果，语义上等同于下面的 SQL：

SELECT 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 基本一致，所以建索引可以直接用 executeSql：

await 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 写得好，而是整套设计习惯相互作用的结果。