关系型数据库通过使用专门的数据结构来管理索引，以便快速定位和访问数据，而无需扫描整个表。索引就像书的索引一样，将列值映射到其物理存储位置。最常见的结构是 B 树（平衡树），它以分层方式组织数据，以实现高效的查找、插入和删除。例如，如果一个 users 表在 email 列上有一个索引，数据库会将排序后的电子邮件地址存储在 B 树中，从而可以在对数时间内找到特定用户的行。其他索引类型，如哈希索引（用于精确匹配）或位图索引（用于低基数列），用于特定场景，但 B 树是大多数通用查询的默认选择。
当执行查询时，数据库的查询优化器会根据过滤条件、表大小和数据分布等因素来决定是否使用索引。例如，一个 SELECT * FROM orders WHERE customer_id = 123 查询会利用 customer_id 上的索引来跳过扫描整个 orders 表。优化器会估算使用索引与全表扫描的成本，并选择更快的路径。复合索引（多个列上的索引）进一步优化了此过程。例如，一个 (department, salary) 上的索引可以有效地首先按 department 过滤行，然后按 salary 排序或过滤，从而避免了单独查找的需要。但是，复合索引中列的顺序很重要 - 仅按 salary 过滤的查询将无法从此索引中受益。
索引需要持续维护才能保持高效。当插入、更新或删除行时，数据库必须更新关联的索引，这会增加开销。例如，将新行插入到具有五个索引的表中需要五个额外的写入操作。随着时间的推移，频繁的更新可能会使索引碎片化，从而降低性能。许多数据库会在维护期间自动重建或重组索引。开发人员必须平衡索引的数量：太少会降低读取速度，而太多会降低写入速度。执行计划（例如，PostgreSQL 中的 EXPLAIN）等工具可以帮助识别缺失或未使用的索引。例如，扫描大型表而不使用索引的查询可能表明需要创建一个索引，而未使用的索引可以安全地删除以降低写入成本。适当的索引管理可确保高效的数据访问，而不会影响整体系统性能。