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 字符串），会导致索引失效或无法比较
