【问题标题】:Oracle indexes redundancyOracle 索引冗余
【发布时间】:2010-10-01 19:31:54
【问题描述】:

我和一位同事是 Oracle 的新手,正在分析表上的索引。这是一个遗留问题,表上当前存在索引

Mytable
* ID      (primary key)
* partId  (Id column in part)
* partNum (partNum column in part...partNum can have more than one partId)
* description (description of partNum...can be different for each partNum)
* dateReceived

IDX_PART_ID_PART_NUM(partId, PartNum)
IDX_PART_NUM(partNum)
IDX_DATE_RECEIVED(dateReceived)

我们的索引似乎有冗余。我们应该从 IDX_PART_ID_PART_NUM 中删除 partNum 吗?我们应该删除 IDX_PART_NUM 吗?如上所述,partNum 可以有多个 id,因为每个部分在对象中可以存在多次。

基本上,在 Oracle 中,索引是如何工作的?

【问题讨论】:

    标签: oracle indexing


    【解决方案1】:

    如果您有同时查找partIDpartNum 的查询,那么您希望维护索引。索引中包含两列意味着索引首先被partID 分解,然后对于每个partID 再次被partNum 分解。仅在 partNum 上设置其他索引对于仅在 partNum 上查询而不在 partID 上进行查询的查询很有用。

    这是一篇好文章的链接:http://it.toolbox.com/blogs/confessions/post-index-how-oracle-works-10605

    作为一般规则,我会避免接触遗留系统上的索引。如果它是一个已经投入生产一段时间的旧系统,那么这些索引可能由 DBA 创建,该 DBA 进行了一些分析和规划,以确保它们运行良好并适合数据的使用。

    【讨论】:

      【解决方案2】:

      另一种方法是对表运行一些示例查询,然后检查 EXPLAIN PLAN 结果。您应该会看到已定义索引的使用模式。

      就建议而言,您引用的两个索引似乎都可以独立使用。我会保留它们,除非您注意到在批量加载或其他情况下对插入的性能有所影响。

      【讨论】:

        【解决方案3】:

        索引的工作原理是允许数据库围绕一组列组织数据。我承认我不能 100% 确定它的技术实现,但它使用这些值创建了一个数据结构,并将它们映射到表中每一行的对象 ID。 (如果我错了,有人纠正我,虽然它不应该影响我整个答案的价值)

        您尝试为要经常搜索的任何内容创建索引,以加快搜索速度。通过在partNum 上建立索引,您可以很快找到partNum 的任何内容。不过,partId, partNum 上的索引将允许您在必须匹配两列的表上进行非常快速的搜索。

        考虑以下几点:

        SELECT *
        FROM MyTable
        WHERE partId = 2
          AND partNum = 7
        

        这将使用IDX_PART_ID_PART_NUM 进行搜索,使用这两个值来扫描索引,而不仅仅是IDX_PART_NUM。这仍然比在两列上分别建立索引要快。

        本质上,它允许将两列的值一起索引,因此对于一列的每个值,它将知道另一列的允许值,并且不必为每个查询进行 2 次查找,当它可以做一个。

        要回答这个问题,如果你经常查询这两个列,那么保留多部分索引。

        【讨论】:

          【解决方案4】:

          基本上,在 Oracle 中,索引是如何工作的?

          另一个综合回答:http://Use-The-Index-Luke.com

          【讨论】:

            【解决方案5】:

            所有索引都是正确的,但性能取决于记录数和每个索引列上的查询频率。

            如果您需要的行数少于 20%,则按索引进行查询会很快。 查询 40% 行,全扫描最快。 索引需要磁盘、内存、插入/更新时间。

            很多时候,索引比所有者表需要更多的磁盘和内存空间。

            【讨论】:

              猜你喜欢
              • 2018-01-01
              • 1970-01-01
              • 1970-01-01
              • 1970-01-01
              • 2023-03-27
              • 1970-01-01
              • 2014-11-26
              • 1970-01-01
              • 2011-06-28
              相关资源
              最近更新 更多