具有单个 varchar 列与多个 varchar 列的复合索引答案

【问题标题】：Composite index with single varchar column vs multiple varchar column具有单个 varchar 列与多个 varchar 列的复合索引
【发布时间】：2023-03-03 03:21:03
【问题描述】：

我有一个要创建复合索引的用例。创建复合索引有两种选择。

选项 1：STATUS_CODE (varchar(1)) & TICKET_ID (number)

选项 2：STAUS (varchar(50)) & TICKET_ID (number)

对于 STATUS 和 STATUS_CODE，我只有 5 个可能的值。

哪一个更适合我的复合索引？这两个索引之间会有性能差异吗？

【问题讨论】：

ticket_id 看起来像某种键 - 它已经有索引了吗？您可能会发现您的复合索引被忽略了，因为 STATUS 不是很有选择性（5 个值）
@NevilleKuyt - ticket_id 和 status_code 看起来都像某种键；该表可能是一个“事实”表，其中每张工单都显示有状态。（它也可能是一个历史表 - 显示“票证”和“状态”历史，还有一个截止日期列。可以使用复合索引，即使 STATUS 不是很有选择性；例如，如果一个查询对于所有处于“暂停”状态的工单 - 仅仅是因为所有数据都已经在复合索引中，所以不需要表扫描。
@mathguy 你是对的。 C 或 COMPLETED 中可以有 99% 的值。我将尝试仅检索处于 HOLD 或其他状态的值。

标签： database oracle indexing relational-database

【解决方案1】：

如果其他一切都相同，那么第一个选项更好。每行将由索引中的更少数据表示，这将允许索引占用更少的磁盘空间。这样，无论何时使用索引，都可以在单个物理读取操作中从磁盘检索更多数据（来自索引）。但是，这对性能的影响程度将取决于您首先拥有多少数据，以及 STATUS 值有多长。（如果它们都接近 50 个字符，那么会产生更大的差异；如果它们中的大多数都很短，则不会那么大。）

不过，您的表格设计似乎违反了第三范式。如果 STATUS_CODE 和 STATUS 相互确定，这意味着您应该有一个单独的表，仅用于“状态”（显示代码和描述）。您的大表应该只有 STATUS_CODE 列，而不是 STATUS 列。

【讨论】：

感谢您提供详细信息。基本上我将创建一个新表并添加索引。只是为了解释的目的，我有两个值 STATUS 和 STATUS_CODE。我将只有一列。