IndexedDB性能优化需监控关键指标并规范使用：事务耗时、游标遍历速度、索引命中率、内存占用及错误频次；合理设计复合索引；批量写入合并事务；游标遍历避免同步DOM操作；读写分离；配合内存缓存与异步策略。
IndexedDB 的性能监控与优化，核心在于可观测、可量化、可干预。不是等卡顿了再查，而是把关键指标变成日常开发和上线后的“仪表盘”。下面从监控入手，再落到具体优化动作，都是实战中验证有效的路径。
关键性能指标必须监控
不看数据，调优就是盲人摸象。以下几项建议在应用启动、高频操作（如列表加载、搜索）前后主动采集：
- 事务耗时：记录每个 readwrite 事务的 start → complete 时间，超 100ms 需预警；只读事务也应监控，尤其在大数据量下
- 游标遍历速度：统计每千条记录遍历耗时，配合索引使用情况判断是否触发全表扫描
- 索引命中率：通过对比 indexedDB.open 时的 upgrade 逻辑与实际 query 使用的 indexName，确认高频查询是否真正走索引
- 内存占用趋势：结合 Performance.memory（若可用）或定期检查 IDBDatabase 对象引用状态，避免游标/事务未释放导致内存泄漏
- 错误类型与频次：特别关注 QuotaExceededError（存储配额满）、AbortError（事务被意外中断）、UnknownError（底层 I/O 异常）
索引设计直接影响查询效率
索引不是越多越好，而是要匹配真实查询模式。常见误区是只建单字段索引，却忽略组合条件。
- 对 WHERE name = ? AND status = ? 类查询，优先建复合索引：
createIndex('name_status', ['name', 'status'])，顺序按查询中等值条件优先、范围条件靠后 - 支持模糊前缀匹配（如 name.startsWith('张')），索引键路径必须是字符串，且不能用正则或 substring 操作绕过索引
- 多值字段（如 tags: ['vue', 'react']）需启用
multiEntry: true，才能用游标高效查出含某标签的所有记录 - 写入频繁的表，索引数建议控制在 3–5 个以内，每个新增索引都会拖慢 add/put 性能
事务与游标使用必须规范
很多性能问题其实源于 API 使用方式不当，而非数据量本身。
- 批量写入务必合并到同一事务中，避免多次 openTransaction 开销；单次事务内操作不宜超过 500 条，否则易触发浏览器强制中断
- 游标遍历禁止在
onsuccess中同步执行 DOM 更新或复杂计算，应先收集结果，再统一处理 - 所有游标必须显式调用
cursor.continue()或到达末尾后自动结束，不可依赖 GC 回收；事务应在完成即刻监听oncomplete并释放引用 - 读写分离可落地为：列表页用只读事务 + 索引游标；编辑页用 readwrite 事务 + 主键定位，避免读写竞争
缓存层与异步策略协同增效
IndexedDB 是持久层，不是缓存层。合理加一层轻量内存缓存，能显著降低数据库压力。
- 对高频读、低频改的数据（如用户配置、静态字典），用 Map 或 WeakMap 缓存查询结果，设置 TTL 或变更时主动失效
- 分页场景下，用游标 + limit 实现“懒加载”，每次只取当前页所需数据，而非全量拉取再前端切片
- 非关键写入（如浏览记录、埋点）可降级为“尽力而为”：用
transaction.oncomplete做日志，失败时不阻塞主流程 - 结合 async/await 封装 IDBRequest，避免回调地狱；但注意不要在 await 后直接操作已关闭的事务对象
