很抱歉这个简单的问题,但我问过几个人并得到了不同的答案。
我有一个由两列组成的连接表:(aID,bID)
aID 是表 A 的外键,bID 是表 B 的外键
aID 和 bID 一起是连接表的主键。
以下哪种方法在连接表上创建索引更有效?
- 在 (aID,bID) 上创建唯一索引。
- 在 (aID,bID) 上创建唯一索引并创建 2 个单独的索引 关于 aID 和 bID。
- 为 aID 和 bID 创建单独的索引。
- 以上都不是(建议你自己的)。
最佳答案
长话短说
- 您不需要
(aID, bID)
上的索引 - 因为它是主键,所以已经添加了唯一索引。 - 如果
bId
上的孤立查询在您的使用中很常见,则您可能需要在bID
上建立单独的索引,例如像WHERE bID = 123
这样的过滤器
- 仅在
aID
上考虑索引可能也有一点好处(特别是如果bID
不是窄类型)。
但与所有索引一样,您需要了解数据的写入和访问方式,以便为所有数据库使用者优化性能。
更多细节
Should I create a unique index on (aID,bID).
不,如果(aID, bID)
上已经有一个主键,Oracle 已经有一个unique index为此,这里的进一步索引将是多余的。
Should I Create separate indexes for aID and bID.
有一个general rule of thumb至 add an index然而,对于每个外键列(独立地),可能有(非常)少数情况下这将是多余的或无效的,例如你永远不会被外键过滤,或者如果外键没有选择性。
所以深入每个:
aID ?
可能不会。因为主键是 (aid, bid)
,所以已经有一个以 aID
为第一列的索引,尽管不如 的索引密集>仅帮助
。
bID ?
可能,是的。虽然 bID
是唯一索引的一部分,但它是第二列,因此如果您经常查询单独使用 bID
的地方(即在不存在 aID
的查询上也是如此)。但是,如果 bId
不是与 aID
分开使用,则不要索引它,并且根据所有索引,如果 bID
具有低选择性(例如,bID
只有 2 个不同的值,每个都有 50% 的分布)那么索引就毫无值(value)。
其他注意事项
索引需要深入了解您的数据库是如何使用的 - 需要仔细考虑新索引,并且需要分析现有索引的冗余(它们是否被使用?是否有类似的索引可以满足需求?)和有效性(如何我对索引的查询要快得多吗?)。
此外,是否添加更多或更少索引的决定还取决于读取与写入的偏差——更多索引会增加写入的 I/O 和磁盘开销,但这可能不是问题,例如在每天重建一次的报告服务器上。
关于sql - 在 Oracle 中的连接(连接)表上创建索引,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/30521506/