索引过多会显著增加 indexeddb 内存占用，导致页面变慢甚至崩溃；应识别并删除冗余索引，优先保留高频、高选择性字段索引，用复合索引替代单字段索引，升级时在 upgradeneeded 中主动删除废弃索引，写密集场景可延迟构建索引。
索引创建过多会显著推高 IndexedDB 的内存占用，尤其在浏览器辅助进程（如 Chrome 的 Renderer 或 Storage 进程）中，表现为内存持续攀升、页面响应变慢，甚至触发系统级内存回收导致标签页崩溃。问题核心在于：每个索引都需要维护独立的 B+ 树结构，写入时同步更新，读取时缓存元数据——索引越多，内存开销越非线性增长。
识别冗余索引，只保留高频查询字段
先确认哪些索引实际被使用。可通过 DevTools → Application → IndexedDB 查看各索引的 keyPath 和 size 估算；更可靠的是在代码中埋点统计 query 调用频次，例如记录 store.index('byStatus').openCursor(IDBKeyRange.only('active')) 的调用次数。重点保留满足以下条件的索引：
- 该字段出现在 where 条件中频率 ≥ 80% 的查询场景（如电商中 status、category、createdAt 常用于筛选）
- 字段值分布较广（高选择性），比如 user_id 比 gender 更适合作为索引主键
- 避免为仅用于排序（order by）但不参与过滤的字段单独建索引
用复合索引替代多个单字段索引
例如用户表需按 city + age + isActive 组合查询，不要分别建 index_city、index_age、index_active 三个索引，而应建一个复合索引：db.createObjectStore('users').createIndex('by_city_age_active', ['city', 'age', 'isActive'])。注意字段顺序：把选择性最高、最常用于等值匹配的字段放前面（如 city 通常比 age 取值更离散）。
复合索引可覆盖多种查询模式，比如 ['city', 'age'] 索引也能加速仅查 city 的请求，但反过来不行。
升级数据库时主动删除废弃索引
IndexedDB 不提供直接 drop index API，必须在 upgradeneeded 事务中操作。若某索引已确认不再使用，应在版本升级逻辑里显式删除：
- 先获取旧 store：const store = transaction.objectStore('logs')
- 检查索引是否存在：if (store.indexNames.contains('old_timestamp_index')) { store.deleteIndex('old_timestamp_index') }
- 确保新旧版本号递增，且只在 upgrade 回调中执行 —— 其他时机调用 deleteIndex 会报错
对写密集型场景启用索引延迟构建
如果应用以写为主（如日志采集、实时消息缓存），可考虑暂不建索引，待数据归档或夜间低峰期再批量构建。Dexie.js 提供 bulkAdd({autoUpgrade: false}) 配合后续 table.where(...).modify() 触发索引更新，能避开高峰期内存峰值。原生 IndexedDB 虽无此 API，但可通过分阶段事务模拟：先写入原始数据，再另起只读事务扫描并按需补建索引。
不复杂但容易忽略
