indexeddb索引需权衡读写性能，非主键精确查找、范围查询+排序、多条件组合筛选及高频统计类查询必须建索引；复合索引应将等值字段置前、范围字段置后，避免冗余；索引会增加10%~30%写入耗时、20%~50%存储开销，并影响内存与版本升级；须通过实际数据验证索引有效性。
IndexedDB 索引不是越多越好，也不是所有查询都必须加索引。关键在于判断哪些查询真正拖慢了体验，以及加索引后是否值得——既要解决读取瓶颈，又不能让新增、更新变慢得难以接受。
哪些查询场景必须建索引
以下几类操作一旦数据量超过几百条，就明显需要索引支撑，否则会触发全表扫描：
-
按非主键字段精确查找：比如通过
userId查用户消息（而主键是自增id） -
范围查询 + 排序：如“获取某用户最近 50 条未读消息”，需同时按
userId和timestamp过滤并倒序 - 多条件组合筛选：例如旅游 App 中“目的地=东京 & 价格≤5000 & 出发日期在下周”，三个字段共同参与过滤
- 高频统计类查询：如实时显示“当前未读消息数”，每次都要遍历全部记录计数
复合索引设计的优先级规则
当多个字段经常一起出现在查询条件中，复合索引比多个单字段索引更高效，但顺序很重要：
-
等值条件字段放前面：比如查询
where userId = 'u123' and timestamp > 1717000000，索引应定义为['userId', 'timestamp'] -
范围查询字段只能放最后：如果写成
['timestamp', 'userId']，userId就无法利用索引加速 -
避免冗余索引：已有
['userId', 'timestamp']，就不必再单独建userId索引（除非有仅查userId的独立场景）
索引带来的性能开销要量化看待
每增加一个索引，都会带来可测量的写入成本，尤其在移动端或低端设备上更敏感：
- 写入变慢约 10%~30%：每条新增/更新记录，都要同步写入主存储 + 所有相关索引结构
- 存储空间增加 20%~50%：索引本身也占磁盘空间，字段越长、记录越多，膨胀越明显
- 内存占用上升：浏览器在查询时会缓存部分索引页，频繁索引可能挤占渲染所需内存
- 版本升级更易失败：升级数据库结构时若重建索引，大量数据迁移可能超时或中断
验证索引是否有效的简单方法
别靠猜测，用实际数据验证效果：
- 用
openCursor()配合索引查询，对比不走索引的openCursor()全扫耗时 - 在 DevTools 的 Performance 面板录制一次典型操作，观察 IndexedDB 相关任务的执行时间占比
- 模拟真实数据量（如插入 1 万条测试记录），测量关键接口的响应变化
- 检查
IDBIndex.keyPath是否与查询字段完全匹配，大小写、嵌套路径（如user.profile.name）出错会导致索引失效
