主页 / dba / 问题 / 171390
Accepted
Horaciux
Asked: 2017-04-20 05:00:59 +0800 CST

如何确认或反驳性能下降是因为维护的索引过多

  • 772

我们知道索引改进select了语句，同时，索引对每个update/insert/delete语句都有维护成本。

我不知道如何衡量/评估这个成本。

一些上下文：有十几个关键表涉及多个插入/更新，行数在 20M 到 80M 之间。平均每秒 1400 个事务。

在过去的几个月里，添加了几个索引来优化系统不同部分的性能。这工作正常，但现在系统的另一部分出现了一些退化。

我有这个理论，但我不知道如何验证或反驳它。

编辑：我读过其他一些帖子，但大多数都是面向 SQL Server 的，我正在运行SYBASE ASE 15.7，如标记

sybase sybase-ase

2 个回答

  1. Best Answer

    在尝试确定要禁用（在 Sybase ASE 中不可行）或删除哪些索引之前，我想更好地理解“系统另一部分出现某些降级”的含义。我想要更多有关退化类型和程度的详细信息。

    为了便于讨论，我将假设“降级”指的是一些现在表现不佳的查询，在这种情况下，我想看看为（重新）调整所述查询所做的工作；查询计划是否显示使用了“错误”的索引？查询计划是否显示“错误的”连接顺序？

    是的，性能下降可能与索引数量的增加有关，但我在想的是，性能下降与更新索引的开销没有任何关系（同样，假设“降级”是相关的现在执行不佳的查询）而是生成“糟糕”的查询计划。

    在优化查询时，Sybase ASE 将尝试评估每个可能的连接顺序，利用每个可能的索引，利用所有可能的列和索引上的每个可能的统计信息。最终结果是优化器需要为引用大量表、索引和列统计信息的查询做大量工作。

    虽然从技术上讲，Sybase ASE 优化器可能会在尝试优化一些大问题、粗糙的查询时关闭一个小时……是的，优化器确实有一些“智能”，可以快速消除一些连接/索引组合 ... 实际上，优化器在搜索“最佳”查询计划的时间上有限制（通过配置参数），（不幸的）结果是对于非常大、复杂的查询，优化器可能会在之前超时它会找到“最佳”查询计划，从而为我们留下“目前为止最好”（即效率不高）的查询计划。

    假设你的降级问题与一些突然开始表现不佳的查询有关，我猜额外的索引可能会增加优化器的工作量，以至于它现在在找到“最好的”之前就已经超时了'查询计划。

    在这种情况下，有几个选项可用于（重新）调整查询...给优化器更多时间来找到“最佳”（或至少“更好”）查询计划...提供提示（例如，索引提示，抽象查询计划）来限制优化器必须考虑的组合......重写查询以简化优化器的工作量......

    虽然对于您所看到的退化可能还有一些其他解释，但第一步是获取有关退化类型和程度的更多详细信息……我们在此线程中未给出的内容……并且（不幸的是）一个过程可能太大/太复杂，无法在此媒体中详细介绍。

    • 2

  2. Sybase ASE 提供sp_sysmonwhich 可用于查看在特定样本期间执行了多少索引更新。您可以在受控环境中使用它来查看在有和没有索引的情况下运行一组特定代码的影响。

    例如：

    EXEC dbo.sp_sysmon 'begin_sample'; --start sampling
/*
   execute various pieces of code, client-side, to
   simulate the load you want to test
*/
EXEC dbo.sp_sysmon 'end_sample', indexmgmt;

    输出将类似于：

    ================================================ =============================
      Sybase Adaptive Server 企业系统性能报告
================================================ =============================

服务器版本：Adaptive Server Enterprise/15.7
运行日期：2017 年 4 月 19 日
统计数据清除时间：2017 年 4 月 19 日 09:16:02
统计采样时间：2017 年 4 月 19 日 09:16:32
采样间隔：00:00:30
示例模式：重置计数器
服务器名称：我的服务器
================================================ =============================
================================================ =============================

指数管理
------------------

  非集群维护每秒每 xact 计数占总数的百分比
  --------------------------------------------------- ---------- ----------
    Ins/Upd 需要维护 0.0 0.0 0 n/a
      # of NC Ndx Maint 0.0 0.0 0 n/a

    删除需要维护 0.0 0.0 0 n/a
      # of NC Ndx Maint 0.0 0.0 0 n/a

    RID 从 Clust Split 更新 0.0 0.0 0 n/a
      # of NC Ndx Maint 0.0 0.0 0 n/a

    更新/删除 DOL Req Maint 1.5 2.4 46 n/a
      # DOL Ndx Maint 1.9 3.1 58 n/a
      平均 DOL Ndx 维护/操作 n/an/a 1.26087 n/a

  页面拆分 0.0 0.0 0 不适用

  页面收缩 0.0 0.0 0 n/a

  每 xact 计数的每秒索引扫描数占总数的百分比
  --------------------------------------------------- ---------- ----------
    升序扫描 0.1 0.2 4 1.1 %
    DOL 升序扫描 11.6 18.3 347 96.7 %
    降序扫描 0.3 0.4 8 2.2 %
    DOL 降序扫描 0.0 0.0 0 0.0 %
                             ---------- -------------- ----------
    总扫描数 12.0 18.9 359

    这将允许您查看在您执行的工作期间发生了多少与索引相关的操作。必须在一个安静的系统上执行此操作，这样您才能获得可靠的结果。我会多次重复测试，启用索引和删除索引。仅供参考，我认为 Sybase ASE 15.7 不支持禁用和重新启用索引。

    希望这能为您提供一些可操作的详细信息。

    • 1

相关问题