IndexedDB查询性能优化核心是索引设计、范围查询、事务控制与数据建模。需为非主键字段建单/复合索引；用游标+IDBKeyRange按需加载；只读用readonly事务，批量写入合并至单readwrite事务；高频字段扁平化，大字段分离存储。

IndexedDB 查询性能不取决于“写得多快”，而取决于“查得准不准”。核心优化逻辑是：用索引代替遍历，用范围限定代替全量加载，用事务控制代替零散操作。

索引设计决定查询上限

对象仓库默认只支持主键查找。若常按非主键字段查询（如 email、status、create_time），必须显式创建索引，否则每次都要遍历全部记录。

• 单字段索引：适合精确匹配或简单范围查询，例如 store.createIndex('email', 'email', { unique: true })
• 复合索引：按字段顺序生效，适用于多条件组合查询，例如 store.createIndex('status_time', ['status', 'create_time'], { unique: false })，可高效支持“status = 'pending' AND create_time > 1710000000”
• 注意索引字段顺序：['a', 'b'] 索引能加速 a = ? 或 a = ? AND b = ?，但对 b = ? 无效

游标 + 范围查询替代全量读取

面对成百上千条数据，避免调用 objectStore.getAll() —— 它会一次性拉取全部数据到内存，既慢又耗资源。应使用游标配合 IDBKeyRange 实现按需加载。

• 获取某时间区间的数据：IDBKeyRange.bound(1710000000, 1720000000) 配合 index.openCursor(range)
• 分页场景：用 IDBKeyRange.lowerBound(lastId) 加 cursor.advance(n) 模拟“跳过前N条”
• 排序需求：在 openCursor 中传入 { direction: 'prev' } 可逆序遍历，无需额外排序

事务粒度与读写分离

事务不是越长越好，而是越精准越好。一个长时间运行的 readwrite 事务会阻塞其他操作，且失败时回滚代价高。

• 只读查询一律用 'readonly' 事务，开销极小，可并发执行
• 批量写入合并进单个 'readwrite' 事务，例如 2000 条插入不应开 2000 个事务，而应在一个事务内循环 put
• 避免跨事务依赖：不要在一个事务里读出数据后，在另一个事务里基于该结果写入——中间状态可能被其他操作修改

数据建模影响底层效率

IndexedDB 不是黑盒，它的查询效率直接受数据结构影响。扁平、高频字段前置、大字段分离，是提升响应速度的关键习惯。

• 把常用于过滤或排序的字段（如 category、is_pinned）放在对象顶层，避免嵌套路径访问
• 二进制内容（Blob、ArrayBuffer）或长文本建议单独存为独立对象仓库，主表仅存引用 ID，防止游标遍历时加载冗余数据
• 避免在索引字段中存动态生成值（如 JSON 字符串），会导致索引失效或无法比较