在上篇文章中，我们学习了如何进行 Firestore 的基本操作，今天就从聊一聊数据库的索引和 Firestore 的正则表达式支持。

查询同名歌曲

只需要重写查询的语句就可以。我们希望查询同名歌曲的想法，但如果 trackId 和当前相同就不用在下面继续写了。

const q2 = query(
                    notesRef,
                    where('trackName', '==', currentTrack.item.name),
                    where('trackId', '!=', currentTrack.item.id),
                    orderBy('createdAt', 'desc')
                );

不要忘记把之前写的 notesRef 移到外部，让常亮 q2 也可以获取到 notesRef。

正则表达式

Firestore 不支持正则表达式。这主要是出于性能和成本的考虑。正则表达式查询需要逐一扫描数据库中的每个文档，以匹配特定的模式，这种操作在大型数据库中会导致显著的性能下降，并增加查询成本。

每次正则查询都需要服务器扫描每个文档的字段，消耗的资源变高，成本也增加了。

传统的 SQL 由于数据库在服务器上部署，所以是否进行正则查询可以由开发者自己决定。

索引

当你真正部署了前端，一定会发现刚刚 console 中的信息，Firestore 会抛出错误，console 会提供创建索引的链接，点击链接后，Firebase 会自动创建所需索引。

这其实是一个用空间换时间的过程。

举个例子：

// 假设有一个订单集合
orders = {
  "order1": {
    userId: "u123",
    amount: 100,
    city: 'Beijing'
    status: "pending",
    createTime: "2024-03-10",
    // 文档大小约 100 字节
  },
  // ... 更多订单
}

Firestore 自动为每个字段创建索引，每条文档的每个索引占据的空间是字段的空间 + 文档引用占的空间。

如果用户进行了这样的搜索：

const q2 = query(
							ordersRef,
							where('status','==','pending'),
							where('City','==','Beijing')
                                    );

每条文档新增索引占据的空间是类似于字段 1_字段 2形成的新字段占用的空间 + 引用占的空间。

最后的索引类似于

"Beijing_pending": [
    -> ID2
    -> ID4
    -> ID7
    // ... 其他北京的未处理订单
  ],

通过成倍的空间降低了索引消耗的成本，加快了速度。