HTML5本身不提供数据库索引机制，所谓“HTML5索引”实为IndexedDB中object store的显式索引；它基于B+树结构，支持按非主键字段高效查询，显著提升万级以上数据检索性能。
HTML5 本身不提供数据库索引机制，也没有内置的“索引”功能用于提升客户端大规模数据检索性能。所谓“HTML5 中的索引”，通常是对 IndexedDB（一种 HTML5 标准的客户端 NoSQL 数据库）中 object store 的索引（Index） 的误称或简略表达。
IndexedDB 的索引本质是加速查询的辅助数据结构
在 IndexedDB 中，每个 object store（类似一张表）可创建一个或多个索引，用于按非主键字段快速查找记录。索引本质上是按指定键路径（keyPath）排序维护的额外 B+ 树结构，支持范围查询、排序遍历和唯一性约束。
- 主键（key）默认有隐式索引，但只能通过 key 精确或范围查找；
- 显式索引允许你按 name、timestamp、category 等字段高效查询，无需全表扫描；
- 索引会增加写入开销（插入/更新时需同步更新索引树），但显著降低读取延迟——尤其在万级以上数据量时效果明显。
典型性能对比测试场景
以 10 万条用户记录（含 id、name、age、city 字段）为例：
- 无索引查 city = "Beijing"：需 openCursor 遍历全部记录，平均耗时 ≈ 800–1200ms（取决于设备与数据分布）；
- 为 city 字段建立普通索引后：使用 index.openCursor(IDBKeyRange.only("Beijing"))，耗时降至 ≈ 15–40ms；
- 复合索引（如 [city, age]）可支持 city = "Beijing" AND age ≥ 25 的高效范围查询，避免内存过滤。
实际测试中需注意的关键点
索引效果受设计方式直接影响，不是“建了就快”：
立即学习“前端免费学习笔记（深入）”；
- 索引字段应选择高频查询、高区分度（cardinality）的属性，避免对布尔值或低基数字段建索引；
- 复合索引遵循“最左前缀原则”：[a,b,c] 索引可支持 a、a+b、a+b+c 查询，但无法加速 b 或 c 单独查询；
- 大量写入时（如批量导入），建议先删索引 → 写入 → 再重建索引，比逐条插入带索引快 3–10 倍；
- 使用 Chrome DevTools 的 Application → IndexedDB 面板可查看索引结构，并用 Performance 面板录制操作对比耗时。
替代方案与边界提醒
当数据规模持续增长（如 >50 万条），仅靠 IndexedDB 索引可能仍显吃力：
- 考虑前端分页 + 后端聚合（如 Service Worker 缓存预计算结果）；
- 对全文检索需求，可结合 FlexSearch 或 Lunr.js 构建轻量倒排索引；
- 不要把 IndexedDB 当作替代后端数据库的方案——它没有事务隔离、无服务端协调、容量受限（通常 50%–80% 磁盘配额）。
