关系型数据库中的索引是一种加速数据检索的机制，通过创建一个结构化的路径来高效地定位记录。 当你在数据库列上创建索引时，数据库会构建一个单独的数据结构——通常是一个 B 树（平衡树）——它存储索引列的排序值以及指向表中相应行的指针。 此结构允许数据库在查询数据时绕过扫描整个表。 例如，如果你在 users.email 列上创建了索引，则搜索特定电子邮件地址涉及遍历 B 树以找到匹配的条目，该条目直接指向表中的行。 这将搜索时间从线性 (O(n)) 降低到对数 (O(log n)) 复杂度。
索引有不同的类型，每种类型都适用于特定的场景。 最常见的是聚集索引和非聚集索引。 聚集索引决定了表中数据的物理顺序，这意味着行在磁盘上的存储顺序与索引相同。 一个表只能有一个聚集索引，通常用于主键。 另一方面，非聚集索引是单独的结构，用于存储排序后的值和指向实际数据行的指针。 例如，如果你在 orders.customer_id 列上创建非聚集索引，则按 customer_id 过滤的查询可以快速定位相关的订单，而无需扫描整个表。 复合索引包含多个列，对于在多个字段上过滤或排序的查询很有用，例如按 customer_id 和 order_date 搜索订单。
虽然索引可以提高读取性能，但它们也带来了权衡。 每次插入、更新或删除数据时，数据库都必须更新相关的索引，这会降低写入操作的速度。 例如，向具有五个索引的表中添加新行需要更新所有五个索引结构。 过度索引会导致存储使用量增加和维护开销。 开发人员必须通过分析查询模式来平衡查询速度的需求和这些成本。 一个好的做法是对 WHERE、JOIN 或 ORDER BY 子句中经常使用的列进行索引。 执行计划等工具可以帮助识别缺失或未充分利用的索引。 适当管理的索引可以显著提高性能，但它们需要仔细的规划和监控，以避免意外的瓶颈。