IndexedDB大规模查询关键在索引精准、游标高效、事务稳健：必须在onupgradeneeded中按查询顺序建复合索引，用IDBKeyRange+游标实现范围/分页/倒序查询，优先调count()统计，读写分离并分批处理防卡顿。
IndexedDB 大规模数据的按需查询，核心不在“能不能查”，而在“查得准、查得快、不卡顿”。关键靠三点：索引对得准、游标用得巧、事务控得稳。没有索引的查询等于全表扫描，几万条数据就明显卡；而错误使用游标或大事务，会让页面假死或内存飙升。
按字段查：必须建索引，且只能通过 index 对象查
主键（keyPath）之外的字段要支持快速查询，必须提前建索引——而且只能在 onupgradeneeded 中创建，版本号必须递增。比如按 status 和 category 查商品：
- 建索引时写
store.createIndex('byStatusCat', ['status', 'category'])，不是['category', 'status']，顺序影响查询效率 - 查询时不能调
store.get('active')，而要调index.get(['active', 'electronics'])或用范围游标 - 如果字段值是
undefined或缺失，该记录不会被索引覆盖，查不到不报错，只“静默跳过”
查范围/分页：用 IDBKeyRange + 游标，别 getAll 后切片
查“2024年订单”或“第3页数据”，直接 getAll() 加数组切片会把全部数据加载进内存，10万条可能吃掉 50MB+。正确做法是让索引配合游标定位：
-
IDBKeyRange.bound(['2024-01-01', ''], ['2024-12-31', '\uffff'])可查复合索引中某时间区间的数据 - 分页查第 201–250 条：先用
cursor.advance(200)跳过前 200 条，再逐条读取 50 条，内存占用恒定 - 倒序查最新 50 条：
index.openCursor(null, 'prev')配合cursor.advance(49)，比正序再 reverse 快得多
查聚合/统计：优先用索引游标计数，避免反序列化
统计“未读消息数”或“某部门员工数”，别 getAll() 后 .filter(...).length。那样每条记录都要反序列化，开销巨大：
- 建复合索引
['dept', 'read']，然后用游标遍历匹配项并累加计数，不取 content 字段，内存几乎不涨 - 若只需总数，可用
index.count(IDBKeyRange.only(['RD', false]))，毫秒级返回，无需遍历 - 注意：count() 不支持模糊范围（如
upperBound），但闭区间bound是支持的
防卡顿：读写分离 + 小事务 + 进度反馈
用户等 3 秒没反应，大概率就关页面了。大规模查询必须兼顾体验和性能：
- 读操作一律用
'readonly'事务，它不加写锁，不影响其他写入 - 写入分批（500–800 条/批），每批完成后更新 UI 进度，比如“已加载 3200/12600”
- 复杂查询可结合
requestIdleCallback分片执行，避免阻塞主线程渲染
