【问题标题】:How to interpret my ShowPlan(Execution Plan)如何解释我的 ShowPlan(执行计划)
【发布时间】:2012-04-28 16:24:06
【问题描述】:

我有一个 Access 2003 DB,我想提高它的性能。昨天看了一篇关于执行计划(Show Plan)的文章,今天针对这个查询运行了我的show Plan:

SELECT tb_bauteile_Basis.*
FROM tb_bauteile_Basis
ORDER BY tb_bauteile_Basis.Name;

我在Name字段上放了一个索引,并显示它的查询计划:

 Inputs to Query -
Table 'tb_bauteile_Basis'
    Using index 'Name'
    Having Indexes:
    Name 1553 entries, 17 pages, 1543 values
      which has 1 column, fixed
    ID 1553 entries, 4 pages, 1553 values
      which has 1 column, fixed, clustered and/or counter
- End inputs to Query -
01) Scan table 'tb_bauteile_Basis'
    Using index 'Name'

接下来,我从Name中删除了索引,新的查询计划为:

- Inputs to Query -
Table 'tb_bauteile_Basis'
    Using index 'PrimaryKey'
    Having Indexes:
    PrimaryKey 1553 entries, 4 pages, 1553 values
      which has 1 column, fixed, unique, clustered and/or counter, primary-key, no-nulls
    Plauskomponente 1553 entries, 4 pages, 3 values
      which has 1 column, fixed
    Name 1553 entries, 17 pages, 1543 values
      which has 1 column, fixed
    ID 1553 entries, 4 pages, 1553 values
      which has 1 column, fixed, clustered and/or counter
- End inputs to Query -
01) Scan table 'tb_bauteile_Basis'
    Using index 'PrimaryKey'

我应该如何解读这两个查询计划?

在第二个 Showplan 中,我应该为Plauskomponente,Name,ID 创建一个索引,我应该为这三个字段创建一个复合索引吗?如何确定是否应该制作复合索引?

为什么Plauskommponente没有出现在第一个展示计划中?

【问题讨论】:

    标签: sql database ms-access sql-execution-plan


    【解决方案1】:

    在第二个 Showplan 中意味着:我应该为 Plauskomponente、Name、ID 放置索引?我应该从这三个领域建立一个综合指数吗?我怎样才能发现我应该做一个综合索引?

    这些名称出现在 ShowPlan 部分中,该部分显示 Jet 在设计查询计划时分析的信息。这 3 个字段上的索引,无论是单独的索引还是基于所有三个字段的单个复合索引,都不会帮助该特定查询。实际上添加索引会减慢其他操作......当您添加或删除行或编辑索引字段中的值时,数据库引擎必须将更改写入表和复合索引。

    优化索引可能很棘手。索引可以加快 SELECT,但会减慢 INSERT、DELETE 和 UPDATE 操作。您需要为您的应用找到合适的平衡点。如果您在 Access 中对此比较陌生,请尝试从菜单的数据库工具部分中的性能分析器向导。检查它提供的建议。很多时候,这些建议将涉及索引。您可以添加它建议的索引,然后在它们降低或没有提高您的整体性能时将其删除。

    为什么 Plauskommponente 没有出现在第一个展示计划中?

    打败我。我猜查询计划器已经找到了 Names 索引,因此认为寻找其他索引毫无意义。

    但是,这带来了另一个重要的观点。该表包含 1,553 行,但 Plauskomponente 仅包含 3 个不同的值。由于具有如此低的可变性,Plauskomponente 上的索引甚至可能不会用于具有基于 Plauskomponente 的 WHERE 子句的查询的计划中。 @Namphibian 在评论中谈到了原因。读取索引以找出哪些行与条件匹配,然后读取匹配的行可能被认为比忽略索引并从表中读取所有行的成本更高。

    最后请注意 ShowPlan 信息部分中提到的统计数据。这些统计信息会在您压缩数据库时更新。因此,压缩有助于为查询规划器提供最新信息,以便它决定如何优化查询计划。

    【讨论】:

    • 在这 3 个字段上的索引,无论是单独的索引还是基于这三个字段的单个复合索引,都无助于特定的查询。 但是为什么 JET 这样做(索引这些字段,我可以在解释计划中看到)。汉斯 我没明白,如果这没有帮助,为什么 JET 使用 Plauskomponnente?JET 会出错吗?
    • Jet 没有使用 Plauskomponnente。查询计划是编号的步骤。查询计划上方的文本是 Jet 检查的背景信息,但可能会或可能不会在查询计划中使用。
    【解决方案2】:

    查询正在读取整个表。您没有 where 子句。您不太可能对其进行优化。您可以做的只是选择您需要的列。这减少了传回的数据量。添加索引不会加快查询速度,因为您没有 where 子句。如果您添加了 where 子句并为 where 子句中使用的那些字段编制索引,您或许可以优化查询。

    【讨论】:

    • 我这里有 ORDER BY,我认为如果我们将索引放在它的字段上会很有帮助
    • 如果访问使用索引来读取字段可能会有所帮助。但是请记住,它可能会更慢。 Access 读取索引。该索引将包含 tb_bauteile_Basis.Name。但是,索引不包含表中的其他数据。它仅包含字段 tb_bauteile_Basis.Name 的值以及指向表中行的指针。所以它必须读取索引中的值,然后从表中读取行。因此,获取数据需要 2 次操作。如果它只是读取表格,那么它仍然需要对其进行排序。因此,根据数据量,它可能会更慢或更快。
    猜你喜欢
    • 1970-01-01
    • 2012-05-21
    • 2012-12-26
    • 2011-03-10
    • 2017-03-11
    • 1970-01-01
    • 1970-01-01
    • 2010-09-09
    • 2020-01-06
    相关资源
    最近更新 更多